Case studyData & Knowledge

The connections no one was looking at.

The risk in an organisation rarely sits in a single record. It sits in the relationships across thousands: who approves whose invoices, where the spend funnels, how the process really flows. This turns procurement into a graph, then surfaces the patterns a person could never hold in their head. Every one is cited to the records, and every one is treated as a lead to investigate rather than a verdict.

01 / The pain

The pattern is invisible one row at a time.

Any single purchase order looks fine. The problem only appears when you connect them: the person who raised a PO also approved its invoice; nearly half a vendor's spend flows through one approver; one manager is a bottleneck on dozens of approvals. To find these by hand, an auditor would have to hold thousands of relationships in their head at once. So they don't, and the patterns persist until something goes wrong.

02 / Why the naive approach fails

Neither a row-by-row review nor a flat query can see the shape.

Row-by-row reviewEach record passes on its own. Self-approval, concentration and bottlenecks are properties of the links between records, not any single one. Reviewing rows can't surface them at all.
A single flat queryCatches one pattern, misses the rest. You can SQL for "same approver on PO and invoice", but concentration needs aggregation across a vendor's invoices and a bottleneck needs counting across the whole estate. Each pattern is a different traversal.
Process maps from interviewsStale the day they're drawn. Asking people how the process works gets you the official version, not the real one with its rework and exceptions. The real process is in the event log.

So the design resolves the records into a typed entity graph, runs an explicit traversal query for each risk pattern, and mines the actual process from the events. Every finding is cited back to the records that produced it.

fig.1 · rows and flat queries vs a graph with a traversal per pattern

03 / How it works

Resolve to a graph, traverse for each pattern, cite every hit.

Records are resolved into a typed graph of employees, vendors, POs, invoices, and the raised / supplied / approved / paid edges between them. Each risk pattern is an explicit, deterministic traversal; the process map is mined from the PO→GR→Invoice events. The model only narrates an insight after the traversal has found and cited it.

fig.2 · the trust boundary: traversals find and cite; the model only narrates

fig.3 · the hard part is a distinct traversal for each risk pattern

04 / One worked example

A concentration surfaced, and a vendor correctly left alone.

Pattern	What surfaced	Evidence	Result
Vendor concentration	46% of Volt & Co spend (S$82,662) approved by one person, Kavya Lim	V004 · E0042	lead to investigate
Segregation of duties	raised the PO and approved the invoice on INV-00117	INV-00117 · PO-00117 · E0101	control breach
Vendor concentration	spend spread evenly across 9 approvers, 22% max	V006	below 45%, not flagged

The threshold is what tells the two vendors apart. A vendor whose spend spreads across many approvers is left alone; the one where 46% funnels through a single person is flagged, with the vendor and approver IDs attached. Crucially, that concentration is surfaced as a lead to investigate and not as an accusation. It is a shape worth a human's attention, traced back to the exact records.

05 / Numbers & honest trade-offs

What it found, and what a finding actually means.

465 / 503

nodes / edges

People · vendors · POs · invoices.

hidden insights

SoD · concentration · bottleneck.

59%

process conformant

41% deviate from PO→GR→Invoice.

cited

every insight

Traced to record IDs.

What a finding means, and what it does not. These are deterministic graph traversals rather than machine learning, so they are explainable and reproducible. A concentration or a bottleneck is a lead rather than a verdict. 46% through one approver may be entirely legitimate, say a specialist category, so the output is a cited shape for a human to investigate and never an automated sanction. The thresholds are the dial. 45% concentration and ≥5 approvals are set to surface the few worth a look without burying the team. On synthetic data they isolate the seeded patterns cleanly; on a real estate you'd tune them to the org's size and tolerance for review volume.

06 / Governance, shown

An insight you can't act on is worth nothing.

Every surfaced pattern carries the records that produced it, so a control owner can verify it in seconds rather than take it on trust. The output shape:

Surfaced insightcited

pattern   : vendor-approver concentration   severity: medium
headline  : 46% of Volt & Co spend (S$82,662) approved by one person
detail    : Kavya Lim (E0042) approves the bulk of V004's invoices
evidence  : [V004, E0042]            control : POL-FIN-02
status    : lead , route to a human to investigate

No pattern is asserted without its evidence; concentration and bottleneck are flagged as leads, segregation-of-duties as a control breach.

What this says about how I work.

I turn scattered records into a structure that surfaces the relationship rather than just the row, the connections and bottlenecks a person can't hold in their head, and I make every finding traceable back to the data so someone can act on it. Just as important, I frame a surfaced pattern as a lead to investigate rather than a verdict. The value is in the edges. I insist the AI cite its evidence, and I am careful not to turn a correlation into an accusation. That is how I'd bring this kind of discovery into a business without it becoming an unexplainable black box.

See it run.

The insights and process breakdown above are real output from the engine over Origin's procurement records. The full console runs as a working application, with the graph stats, the cited insight cards, and the mined process.

See the live governance demo →The full console runs on my machine. Ask me for a 90-second walkthrough.