What We Hand an Examiner
Phil Hofsteder · · 10 min read

Examiners do not want a product tour. They want a matter, a time, and a reconstruction. We built the export around that conversation, because that is the conversation that decides whether the institution is allowed to keep the workflow.
This is the pack we produce. Customer identifiers in examples are fake. The fields are not.
The pack
- Matter join.
workflow_run_id, institution matter ID, project, desk, template version. - Actors. User IDs for runner and, if any, dual-control approver, with timestamps.
- Policy bundle hash. Routing, residency, retention, PII, dual-control flags as they stood at invocation, not as they stand today.
- Route. Models, hops, cache hit, pin mode, fallback events.
- Redaction proof. Entity types, counts, strategy, and a statement whether the provider saw raw or hashed spans.
- Eval gate. Scorecard ID and decision that allowed this template on this chain.
- Output. Payload if the retention class still holds it; otherwise output hash and clock.
- Cost. USD and tokens, itemized, because finance sits in some of these rooms too.
We can generate this for a single request_id in the product. We can also batch a date range into the SIEM-shaped export the institution already uses.
What we rehearse
Once a quarter we pick a random production run (with the tenant's permission) and time how long it takes their staff, not ours, to produce the pack from our UI plus their SIEM. If it takes a vendor engineer in the room, the deployment is not exam-ready. We stay until it does not.
Last quarter's median for a trained control officer was 14 minutes for a single legal run. The failures were all the same: matter ID not joined at intake. That is an operating-line problem. We will not paper it over with a prettier PDF.
What we will not put in the pack
We will not generate a narrative that says the model was "responsible." The human was responsible. The pack shows who.
We will not backfill a policy hash that was not recorded. If a tenant ran unsanctioned shadow IT against a raw provider key, Eridian cannot invent the trail. We can show that those calls never hit our gateway.
Why this is the product
The operating thesis is accountability. An examiner is the audience that thesis was written for, whether or not they are in the room on a given day. If we cannot hand them the pack, we do not deserve the production traffic.

Phil Hofsteder
CTO
Phil Hofsteder is Chief Technology Officer of Eridian. He holds the accountability architecture of the operating system: policy enforced at invocation, dual control on high-risk actions, and an audit trail that survives examination. His work is the control discipline that lets a financial institution put intelligence into production without surrendering the decision to an unreviewed model.


