Architecture brief · Fiduciary · private preview
An AI coworker that cannot sign on its own.
Fiduciary is BMI2's air-gapped AI worker for regulated back-office workflows — capital-investment underwriting, deal governance and the analyst work that lives next to them (A&R, the music-industry Artists & Repertoire product, is a separate vertical on the same governance spine). It has an OIDC identity, a scoped role, a permanent record and a supervisor. It reads only what the requesting person is already allowed to see, cites the source of every claim, proposes bounded actions, and cannot execute a consequential one without a human signature bound to that exact proposal.
Fiduciary Agentic AI: Loan Origination & Servicing
What Fiduciary is
An internal worker with an identity, a scope, and a paper trail — not a chatbot.
A chatbot is a stateless assistant that answers whatever it is asked, with whatever credentials the person deploying it happens to have loaded. That is the wrong shape for regulated work. In a fund operations team or a contract-renewals group, the sensitive step is not the answer — it is the write: a wire released, a covenant amended, an account permission granted. Every regulator that touches those steps requires the same four things: named identity, scope of authority, evidence supporting the action, and an auditable trail of who approved it.
Fiduciary is built around those four requirements rather than added to a chatbot afterwards. The identity is issued by your Keycloak, not by the LLM. The scope is a per-workflow role that Postgres enforces with row-level security. The evidence is a retrieval chain that refuses to answer past its own citations. The trail is a tamper-evident, append-only journal that survives the LLM changing its mind.
The rule: no verdict without evidence, no action without a countersignature, no record without an entry. If any of the three fails, the workflow stops and says so — it does not soft-fail into producing a result.
Ask AI: three identities, three different answers
Engineering by Tarik Riley
SME-trained, not prompt-engineered
Each persona is signed off on real Fiduciary artifacts before it works on one.
Fiduciary personas — Underwriting Analyst, Due Diligence Analyst, Portfolio Manager, Data Ops Analyst — are not system prompts handed to a model. Each is trained through the Curriculum Trainer against real Fiduciary artifacts on a graded L1 → L7 ladder (detection, abstention, discrimination, authorization-bounded, adversarial, cross-lens, operational degradation). No persona is allowed to reason over an artifact class in a live workflow until an SME signs off on it at that level — and the sign-off itself is a signed record in the same audit journal that the finished workflow lands in.
Underwriting Analyst
Credit memos, loan tapes, term sheets. Correct spread and covenant reasoning; abstention when data is stale or incomplete.
Due Diligence Analyst
Contracts, side-letters, closing binders. Conflict detection across amendments; nothing signed off without the source paragraph cited.
Portfolio Manager
Portfolio reports, covenants, waterfall calcs. Deviation surfacing before the review meeting; escalation, not silent tolerance.
Data Ops Analyst
Connector feeds, evidence ingest, lineage. Provenance intact end-to-end; a broken chain is a fault, not a warning.
Live from the lab right now: 3 of 3 obstacle courses active · 0 findings across 5 events · 84 minutes of Agentic Curriculum run time. If a scenario the persona should have caught — a missed covenant deviation, a side-letter conflict, an unverified closing condition — goes wrong on a real deal, the corresponding lesson is added and the persona's next promotion has to clear it before it works again.
The four boundaries
Four checkpoints between a request and a signed action.
Every Fiduciary run passes through four boundaries. Each one has an owner other than the LLM. If Fiduciary cannot answer honestly at any of them, the workflow raises an exception the human queue can act on — it never produces a confident guess.
01 · IDENTITY
Keycloak OIDC — per-workflow role, not a service account.
Every Fiduciary session runs as the requesting person, through a workflow-specific role issued at run time. The bearer token names the workflow, the tenant, the target dataset, and the time window. Postgres roles enforce it at the row level: rag_service for retrieval, enterprise_api for orchestration, and per-workflow read roles that inherit only what the person themselves can see.
The LLM never sees a broad credential. It sees a bounded read-through, and if it asks for anything outside the bound, Postgres returns zero rows and the retrieval stops.
02 · EVIDENCE
Retrieval → PII gate → quality gate → cited answer.
Documents live in a pgvector store, embedded with BGE and partitioned by tenant + workflow. Every retrieval passes through a Presidio PII gate that redacts unauthorised entities before the text reaches the model, and through a Retrieval Quality Gate that scores the answer against a real RAGAS suite plus a local Qwen judge — a low score fails the run rather than downgrading it silently.
The model's output is required to cite specific evidence spans by document hash + offset. An uncited claim is a validation error. That is why Fiduciary refuses to answer some questions: not because the model would not have something to say, but because nothing in the retrieved evidence supports it.
03 · ACTION
Temporal workflow → approval envelope → human countersignature.
Fiduciary does not act. It proposes. A proposal is packaged into an approval envelope — a Temporal workflow object with the proposed action, the evidence hashes it depends on, the operator, the tier that produced it, the spend it would incur, and the time bounds it is valid within. The envelope is stored, presented to the responsible human, and signed against a specific reviewer identity.
Only a countersigned envelope can move to execution. The signature is bound to the exact envelope contents — a re-planned proposal invalidates the old signature. This is what stops the two failure modes that trip up governed AI most often: acting on a stale proposal, and executing after a plan changed mid-review.
04 · AUDIT
Tamper-evident append-only journal — evidence, not narrative.
Every retrieval, every proposal, every countersignature, every execution and every failure lands in an append-only audit journal keyed by workflow id. Entries are hash-chained so a mid-stream edit invalidates the tail. The journal is queryable but not editable — even Fiduciary's operator role has no write path to prior entries.
The audit is what an examiner reads, not what Fiduciary says. The two are separable on purpose: the model can be replaced without touching the record, and the record can be verified without needing the model to be running.
Deterministic runtime
Seven watchers do the work the LLM should not be doing.
A production regulated system cannot have an LLM in every loop. Most of the decisions inside a Fiduciary deployment are made deterministically by a set of process watchers that carry no model at all — they read state, apply a rule, and either move the workflow forward or park it for review. The LLM is invoked only for the narrow slice where language actually matters.
tier-isolation-watcherKeeps tiers separated.Enforces that Tier 1 evidence never crosses into Tier 3 reasoning without an explicit uplift envelope. Runs in single-tenant lab mode by default.
execution-workerRuns countersigned envelopes.Consumes approval envelopes with a valid signature and executes their bounded action against the correct target. Refuses stale envelopes.
opa-pep-watcherOpen Policy Agent enforcement.Every proposal is checked against a Rego policy set at proposal time and again at execution time. A policy change between the two invalidates the envelope.
spend-alert-watcherBudget gates every model call.Per-provider budget with per-tier price mapping. Breaches at 25 / 50 / 75 / 100% land in Mattermost with the run id and the responsible operator. Blocks Tier 3 calls above ceiling.
sla-watcherEnforces stated review windows.Envelopes that sit past their SLA are escalated or expired according to the workflow policy — never quietly held.
portfolio-watcherCross-workflow deconfliction.Prevents two active proposals from acting on the same underlying record without a human reconciling.
connector-watcherExternal read-only integrations.Graph mailbox, Google Drive folder — pulled on a fixed interval, cached inside the appliance, never written to.
health-watcherFiduciary's own vital signs.Pod readiness, queue depth, envelope inventory, journal integrity. Reports out through the standard health surface, not through the LLM.
The watchers ship as the same container image as the API. They talk to Postgres, MinIO, Keycloak and Temporal — nothing else. There is no watcher that reaches out to the Internet at runtime.
Model tiers
Three tiers, priced separately, hard-capped.
Fiduciary uses one provider family at a time so the audit journal stays reproducible. AWS Bedrock is the default for Tiers 1 and 2 (evidence classification and structured extraction); Claude Haiku is the default for Tier 3 (narrative synthesis). Every call is priced against a published rate card and counted against a budget the operator sets before the workflow starts.
Tier 1 — signal
Deterministic classification of retrieved evidence: document type, party, date range, obligation category. No free text. Used to route the workflow.
bedrock
Tier 2 — extraction
Structured extraction of named entities, monetary amounts, effective dates and covenant terms into a typed schema. Output is validated before it moves on.
bedrock
Tier 3 — narrative
Human-readable summary of the proposal with citations. This is what the reviewer reads to countersign. Priced at Haiku input/output; a spend gate blocks the call over budget.
claude-haiku-4-5
Why the tiers are hard-separated.
Regulators care about which model authored which sentence. The tier boundary is the audit shape that answers that. A single-model chain that produced everything is impossible to attribute after the fact. Fiduciary records the tier, the model id, the prompt hash and the citation set for every step, and refuses to let a Tier 3 answer be signed against Tier 1 evidence.
Deployment posture
Air-gapped by design — the appliance does not talk to us.
Fiduciary is delivered as a Kubernetes appliance you stand up on your infrastructure. The container images and adapter weights are signed offline with Ed25519, shipped with an SBOM, and verified by the appliance at load time. There is no license check that phones home, no telemetry endpoint, and no update channel that requires outbound HTTPS.
The only external calls at runtime are the ones the operator explicitly enables: your Bedrock endpoint for Tiers 1 and 2, your Anthropic key for Tier 3, and your organisation's Graph or Google Drive if the connector-watcher is turned on. All three are configured per-tenant and can be swapped or disabled without redeploying.
Signed artifacts
Ed25519 signature on every image and adapter manifest, verified at pod start. Refuses to run an unsigned or mis-signed artifact.
SBOM per release
CycloneDX SBOM shipped alongside every image; verifiable against the running container digest.
No outbound calls at runtime
A NetworkPolicy in the appliance blocks pod egress except to the model endpoints and connectors you configured. Failing the policy is a visible fault, not a silent drop.
Secrets stay in the appliance
Model provider credentials sit in a Kubernetes secret readable only by the tier that needs it. Never printed, never in an image, never in the audit journal.
Backup + restore drills
A supported pg_dump / MinIO / audit-journal restore rehearsal ships with the appliance; the restored copy is required to reproduce a run byte-for-byte before it is treated as valid.
Upgrade + rollback rehearsal
Every release ships with a rehearsed rollback path from the previous appliance version, exercised in a synthetic lab before it is offered to a pilot.
The absent things
What Fiduciary is not, said out loud.
Every product decision has an inverse. These are the ones Fiduciary made on purpose, and the ones a buyer needs to know before an evaluation, not after.
Not a chatbot
Fiduciary does not have a persistent chat surface. Interactions are workflow-scoped — a proposal, a review, a countersignature. That is a deliberate refusal of the conversational metaphor, which is a poor fit for the record an examiner wants to read.
Not autonomous
There is no configuration that removes the countersignature gate. A workflow can be pre-authorised by policy, but the policy itself is a signed artifact that expires, and the audit journal shows which policy authorised which action at which time. Fiduciary cannot be trained by a user to bypass its own approval loop.
Not model-agnostic
The default tiering pairs Bedrock and Claude Haiku for a reason: both providers publish audit-relevant metadata (model id, prompt hash, safety filters) that Fiduciary records into the journal. Swapping in a model that does not is possible but is a supported-configurations decision, not a runtime toggle.
Not production-ready today
Fiduciary is in private preview. The architecture is real, the contracts are frozen, the audit journal is verifiable end to end and the appliance runs on the same synthetic lab TestPulse's Virtual Lab uses. It has not yet run against a real customer dataset, and it will not until the pilot decision is recorded by name in the relevant ADR. If you are looking for a system to sign your Q4 renewals, Fiduciary is not that system yet. If you want to shape what such a system should look like, the preview program is where that happens.
Preview access is invite-only and covers a real workflow end to end.
The preview program pairs a design partner with an engineer for a single workflow — proposal, review, countersignature, execution, journal, restore — and runs it against synthetic data that mirrors the partner's own document shapes. If Fiduciary belongs in your operations stack we would like to hear that from you rather than tell you first.