02 — Agentic workflow diagrams

The same control pattern, drawn three ways: components, data flows, and the paths taken when something goes wrong.

These diagrams describe how we would build, not what exists today. Each is interactive: select a component to see what it must guarantee and how it fails, hover an arrow to read the payload it carries, and walk the numbered sequence to see the contract at each step. Failure paths are drawn deliberately — in agentic systems the unhappy paths are the design, and a diagram that shows only the happy path hides the part that determines whether the system is trusted.
2.1How to read these diagramsImplementation
2.2

The three workflows

Switch between them; each has its own components, flows, failure paths and worked sequence.

A natural-language question answered from the certified semantic layer under the asker's own permissions, with every figure computed by a tool and every claim carrying provenance.

9 steps

Sequence

Inspector

Select any component to see what it is responsible for, what it must guarantee, and how it fails. Hover an arrow to read the payload it carries. Dashed red arrows are failure paths; dotted grey arrows are observability writes that are not on the request path.

SurfaceControlToolDataControl gateHumanObservability
2.3

What the three have in common

Executive

The shared spine is the reason these are variations of one architecture rather than three separate builds.

Invariants across every workflow

  • A model never produces a figure. Numbers come from query() or compute(); the model selects and narrates.
  • Identity travels with the request end to end; no step widens the caller's access.
  • Every boundary is a typed contract, validated before execution rather than after.
  • Every consequential output carries provenance: source, version and timestamp.
  • Every failure path terminates in a stated outcome, and every terminal outcome is logged and measurable.

Where the three deliberately differ

  • The conversational workflow refuses; the extraction workflow escalates to a person; the calculation workflow blocks a release. The right terminal action depends on who is waiting.
  • Verification is post-hoc numeric checking in A, schema and rule validation in B, and historical parity replay in C — all deterministic, none a model reviewing itself.
  • Human involvement is feedback in A, in-line confirmation in B, and adjudication authority in C.
  • Cost behaviour differs: A is per-question and adoption-driven, B is per-document and batch-shaped, C is near-zero at runtime because no model runs there.

Hypothesisthe sequencing implied by these diagrams

Our hypothesis is that A depends on foundations that B and C help create — certified measures, curated definitions, provenance habits — and that attempting A first produces a demonstration rather than a capability. We would test this against the actual state of the semantic layer in discovery.

Assumptionwhat these diagrams assume about the estate

They assume delegated identity can reach the reporting layer, that certified measures exist to query, and that historical runs of the legacy model are reproducible. Each is listed as an open question because none has been verified, and each would change a specific part of the drawing rather than the approach as a whole.