← Back to the demo
UNA
Architecture notes · Prepared for Adam and Fausto

The shape of the system, drawn out.

Three diagrams behind the walkthrough you just went through — how UNA's pipeline is structured, where it could sit next to your certification workflow, and what a decision receipt actually looks like as a flow instead of a table.

Discussion draft, not a capability statement No source code or protected implementation detail shown
Architecture

Seven stages, one governing idea: output is a proposal.

Model output moves through explicit checkpoints before anything becomes consequential — each arrow below is a specific thing handed to the next stage, not just “then.”

Objective & Authority Outcome, allowed work, prohibitions, stop conditions Planning & Policy Decomposes work, checks constraints, flags required evidence Model & Tool Routing Selects bounded resources, keeps provider/tool provenance Bounded Execution Only authorized ops, inside defined data / network / side-effect scope Memory & Evidence Context, retained memory, and evidence kept as distinct states Verification & Review Approve · HOLD · repair · escalate · rollback Receipt & Reconstruction What happened, under whose authority, from which evidence objective plan bound resources result evidence state disposition
What this shows: the same seven checkpoints described in section 4 of the architecture brief, drawn as a pipeline instead of a numbered list. The highlighted stage — bounded execution — is the one with a hard scope: only authorized operations, inside a defined boundary, ever run.
Integration hypothesis

Not a platform swap — an envelope around one proposed change.

Your certification workflow keeps owning the process. The open question — the one the discovery session actually decides — is which of five shapes the governed layer should take, if any.

DBLU'S CERTIFICATION WORKFLOW — EXISTING, UNCHANGED Source retrieved Regulatory bulletin, dated Model proposes a change Reviewer decides Human approval today State updated Controlled record changes evaluated by Governed change-control envelope Evaluates one proposed state change — not yet built or scoped; hypothesis under discussion Proposed action Authority required Evidence status Disposition Which interface shape? Offline eval harness Receipt schema Policy adapter Narrow API contract No component — decided in the 45-minute discovery session, not before —
What this shows: the smallest plausible intersection from section 6 of the brief. The five candidate shapes are drawn with dashed borders on purpose — none is proposed as the answer; the diagram exists to make the open question concrete enough to argue about.
Why draw this one: this is the actual decision Fausto's discovery session is meant to reach — proceed to charter, revise, or hold. The diagram doesn't answer it; it gives you both something to point at while you do.
Decision receipt

One proposed change, four ways it can resolve.

The same shape as the audit trace in the live demo — evidence in, a bounded set of dispositions out, everything preserved in one receipt regardless of which path it took.

Evidence Source URL, retrieval time, content hash, version Evidence status? conflict / stale / missing HOLD Material conflict between source and controlled record corroborated Authority required Authorized human reviewer for controlled-rule changes Disposition? APPROVE REJECT ESCALATE ROLLBACK Receipt · PE-CA-CHANGE-0001 Reason and allowed next action recorded, every path
What this shows: the illustrative receipt from section 7 of the brief, drawn as the flow it actually is. Every outcome — including HOLD — reaches the same receipt. Nothing here is a claim that this exact schema is implemented; it's the shape a receipt would need to have.
Recorded session

The real console, not a mockup.

Everything below is unedited output from Tom's local governed console (una) and the same UNA MCP server this site's “Trusted live session” would eventually connect to — recorded on Aug 16, 2026. No responses were rewritten; one file path was shortened to ~/ for privacy.

What this shows: the first block is a deny-by-default authority check — asked to skip review, the console refuses by default and names exactly what it won't touch. The second drafts a local-only proposal and previews its boundary before anything is approved. The third is an exact-record fetch of the same authority policy this site describes, pulled from the running MCP server, not written for this page.