AI in the Engine Room — Achieve Australia

A redesigned feedback-loop architecture where AI is the connective tissue itself — not a tool handed to a portfolio owner. Written because "assign someone to own the gap" quietly reproduces the exact failure this engagement diagnosed.

The trap: an owner is not a fix

Why "assign someone" reproduces the problem

Funding Optimisation had a named Sponsor and a named Lead — and its own December 2025 review still concluded, in capitals, "Project NOT aligned to Connect." A person in the seat didn't stop portfolio-optimising behaviour; the incentive structure did that regardless of who sat there. Naming an owner for Reconcile Payments' "Role TBC" would hand Finance another local metric to manage — the same shape that has already left that step unowned for 19 months, surviving a full system migration.

What already works here, and why

The Continuous Improvement register is the one loop in this engagement that closes reliably. Not because the right individual owns it — because it has a structural cross-check: a risk-rated SLA, two distinct owners (an operational owner and a named accountable executive), and an approval gate that has demonstrably rejected an item, not just rubber-stamped it. No single portfolio can unilaterally close an entry. That shape — not a person — is the thing worth generalising.

feedback-loops/achieve-ci-register-loop.md

The redesigned architecture

flowchart TB
    subgraph P["Existing portfolios — each optimises its own metric"]
      direction LR
      FIN["Finance
funding / billing / reconciliation"]
      OPS["Operations
client lifecycle, incidents"]
      QUA["Quality / Practice
CI register"]
      IT["IT
Connect / systems"]
    end

    FIN -.->|"exhaust data only —
no new workflow required"| ENGINE
    OPS -.->|"exhaust data only"| ENGINE
    QUA -.->|"exhaust data only"| ENGINE
    IT -.->|"exhaust data only"| ENGINE

    ENGINE{{"AI connective layer
— has no portfolio of its own —"}}

    ENGINE --> GATE{"Two-sided gate:
do both sides confirm closure?"}
    GATE -->|"No — one side silent"| OPEN["Stays visibly open
— no function can quietly deprioritise it"]
    GATE -->|"Yes — both confirm"| CLOSE["Loop genuinely closes"]

    ENGINE --> SCAN["Continuous cross-loop
pattern scan"]
    SCAN --> BOARD[["ELT / Board dashboard
— the one body that spans every portfolio"]]
    OPEN --> BOARD

    style ENGINE fill:#ece3d3,stroke:#7a6e5e
    style OPEN fill:#f4dad7,stroke:#b3352f
    style CLOSE fill:#dcebde,stroke:#2f7a3f
    style BOARD fill:#f6e9cd,stroke:#c8841a

Six design moves, each tied to a named gap

Ingest off exhaust, not new workflow

Reads the CI register, incident data, reconciliation exceptions and board papers that already exist. If closing a gap requires a function to adopt a new tool, it re-creates the "their backlog, their discretion" problem.

Run the synthesis continuously, not once

This engagement's own exec-summary/gaps-register process — read four loops, find the repeating shape, write it up — becomes a standing, always-on process instead of a one-off deliverable.

Route findings straight to the Board

The load-bearing choice. A gap surfaced through a system Finance controls can sit for 19 months. Routed to the one body that spans every portfolio, no single function gets to decide it's inconvenient this quarter.

Replicate the two-sided gate everywhere

Encode the CI register's own working shape as a rule: reconciliation, incident closure, and departure records all need matching sign-off on both sides before they're marked closed — enforced by the system, not remembered by a person.

Fix the SOS-as-PDF root cause at creation

Found independently three times, and survived a platform migration because the fix was one person manually re-keying it. Structured extraction belongs at the point the Statement of Service is generated, removing the single-person dependency entirely.

Watch the documents for drift, continuously

Stale "Role TBC" maps and three ungoverned generations of client-lifecycle procedure don't get fixed once. A continuous diff against what Connect actually does flags contradictions before anyone builds on a superseded map.

Reference technical architecture

Five layers, mapped to systems Achieve already runs — no new platform category, because introducing one would just create a sixth portfolio to defend.

flowchart TB
    subgraph SRC["Source systems — read-only, no new workflow imposed on anyone"]
      direction LR
      S1["CI Register
(Excel / SharePoint)"]
      S2["Connect / VisiCase
(incidents, case records)"]
      S3["Business Central
(finance ledger)"]
      S4["Board papers, CEO reports
(SharePoint / PDF)"]
      S5["HubSpot / MS Dynamics
(client intake)"]
    end

    subgraph ING["Layer 1 — Ingestion & extraction"]
      direction LR
      E1["Structured connectors
for systems that already have an export/API"]
      E2["LLM document extraction
PDF/Excel → structured fields
— this is where the SOS-PDF problem gets fixed"]
    end

    subgraph CAN["Layer 2 — Canonical store, owned by no single portfolio"]
      direction LR
      C1["Normalised entities:
Incident · CI Item · Reconciliation Exception ·
Lifecycle Event · Document Version"]
      C2["Entity resolution across
HubSpot / Dynamics / VisiCase
— one client, one record"]
    end

    subgraph REASON["Layer 3 — Reasoning"]
      direction LR
      R1["Scheduled cross-loop pattern scan
— the exec-summary/gaps-register method, automated"]
      R2["Document drift detection
flags 'Role TBC', stale maps, superseded generations"]
    end

    subgraph GATE["Layer 4 — Structural gate engine"]
      G1["Two-sided close check per loop
— the CI register's proven shape, generalised"]
    end

    subgraph OUT["Layer 5 — Reporting"]
      O1["Standing dashboard routed straight to ELT/Board
— never gated by the function it implicates"]
    end

    SRC --> ING --> CAN --> REASON --> GATE --> OUT

    style CAN fill:#ece3d3,stroke:#7a6e5e
    style GATE fill:#f6e9cd,stroke:#c8841a
    style OUT fill:#dcebde,stroke:#2f7a3f

Why no new platform category

Achieve is already a Microsoft-centric shop — Dynamics, Business Central, SharePoint — plus Connect/VisiCase and Power BI for incident/rostering reporting. Building Layer 1's connectors and Layer 5's dashboard on Azure-native tooling (Power Automate, Power BI, or simply extending this repo's own static HTML visuals system) stays inside Achieve's existing IT governance and procurement perimeter. A net-new vendor stack would need its own security review before it could touch any of this data — friction the design doesn't need.

Prove the mechanism before automating it

The cheapest possible Layer 3 is not software — it's a person running this engagement's own method (read the sources, cross-reference, write the gaps register) on a monthly cadence, routed straight to the Board per Layer 5's rule. That de-risks the design — confirms routing findings around portfolio discretion actually changes Board behaviour — before any ingestion or gate automation gets built.

What's needed to build it

Phase	Build	Precondition	Effort
0 — Foundation	Define the canonical schema for the five entity types; get read access to the CI register export, incident data, and reconciliation exception report	Board/ELT agrees findings route to them directly, unfiltered — without this decision, nothing downstream changes anything	Low — workshops + access requests, no code
1 — MVP pattern scan	Ingest CI register + incident data; automate the exec-summary/gaps-register method as a scheduled job; extend this repo's own `visuals/` system as the output surface	Phase 0 schema agreed	Low–medium — reuses a pipeline this repo already runs by hand
2 — SOS extraction pilot	LLM extraction pipeline on the Statement of Service, at the point it's generated	Access to wherever the SOS is created, pre-Connect/VisiCase entry	Medium
3 — Structural gate: Reconcile Payments	Two-sided close check between Business Central and Connect/VisiCase	Named data contacts in Finance + Case Management — not fix-owners, just access	Medium–high — first real system integration
4 — Document drift detection	Continuous diff of the process-document library against Connect's live behaviour	SharePoint/document repository access	Medium
5 — Expand the gate model	Roll the two-sided close pattern out to "lessons shared" in incident management and departure-reason logging	Phases 1–3 proven in practice	Medium

Old pattern vs. redesigned pattern

Gap	Old pattern (fails)	Redesigned pattern
Reconcile Payments — "Role TBC"	Name one person from Finance to own it	Two-sided gate: Finance + Case Management both confirm before it's closed
No aggregation of closed CI/incident items	Give Quality/PMO a new "theme review" job	Continuous cross-loop scan, reported straight to ELT/Board, owned by no single function
Statement of Service trapped in non-searchable PDF	One person manually re-keys it; breaks when she's away	Structured capture at point of creation — no single-person dependency
Stale / conflicting process documents	One-off cleanup that starts rotting again immediately	Continuous drift detection against the live system

What this doesn't fix

Visibility is not the same as consequence

M.E. Services and this engagement already gave Achieve visibility into the same root cause from two independent angles, and that alone hasn't moved anything yet. An AI connective layer makes visibility non-discretionary — no function can quietly let a cross-cutting finding lapse the way Reconcile Payments has for 19 months. But the Board still has to act on what surfaces. No engine-room redesign solves an organisational-will problem by itself.