How Coriqo is actually built — and where it honestly isn't finished yet.
This page exists because "trust us, it's tamper-evident" isn't a claim a bank examiner or a hospital AI committee should accept from any vendor — including us. Below: the mechanism behind the append-only record, the reasoning behind Coriqo's product bets, and an honest account of what's shipped versus what's still on the roadmap.
Every mechanism described below is implemented in the codebase today, not a diagram of an intention. Where something is partial or roadmap, it's labeled as such.
Append-only log, Merkle attestation, independent verification.
Three design decisions, stacked, produce a record an examiner can check without trusting Coriqo as an institution. Each one closes a specific way a governance record can quietly go wrong.
Why append-only, not "editable with a history tab"
Most tools that claim an "audit trail" are really a mutable table with a change log bolted on — someone with admin rights can still edit the underlying row, and the log entry recording that edit is itself just another mutable row. Coriqo's governance events are hash-chained: compute_governance_event_hash() hashes each event's sequence number, actor, action, from/to status, notes, and the previous event's hash together with SHA-256. Change anything in an already-written event — the notes, the actor, the outcome — and its hash no longer matches what the next event in the chain committed to. The break is detectable by recomputing the chain, which is exactly what GET /governance/.../verify does on demand.
Timestamps are deliberately excluded from the hash formula, because clock skew between servers shouldn't be able to break a chain that's otherwise intact — a small, specific engineering decision that matters more than it looks like it should once you've operated distributed systems at a bank.
Where:api/utils/audit.py:308-345 (hash formula), api/domains/governance/router.py:398-415 (verify endpoint), api/domains/governance/router.py:41-89 (event append)
Why a Merkle tree, not just a longer hash chain
A hash chain alone proves the whole history is intact, but proving that requires walking the entire chain from the start — expensive, and it means an examiner verifying one event has to receive (and trust the completeness of) every event before it. Coriqo periodically seals the event log into a Merkle tree and signs the root with Ed25519 (checkpoints/service.py:237-320). That gives an inclusion proof: a small, downloadable bundle of sibling hashes that proves one specific event was included in a specific, signed root — in O(log n) hashes rather than O(n). For a chain of 10,000 events, that's roughly 14 hash comparisons to prove any single one, not 10,000.
This is the same structural idea behind Certificate Transparency, the append-only log system every browser already relies on to catch mis-issued TLS certificates — Coriqo applies the same well-understood technique to model governance records instead of certificates.
Where:api/domains/checkpoints/service.py:237-320 — Merkle root computation, Ed25519 signing, downloadable inclusion proofs
Why verification has to work without a Coriqo account
If the only way to check a checkpoint's signature is to log into Coriqo and ask Coriqo whether Coriqo's own records are valid, the examiner is still trusting the institution, not the math — which defeats the point. So the verification tool is a standalone CLI, tools/verify_proof.py, that takes a downloaded proof bundle and Coriqo's public key and runs entirely offline: no network call, no API key, no Coriqo server in the loop. It recomputes the Merkle path from the event up to the signed root and checks the Ed25519 signature against the public key. The math either checks out or it doesn't — there's no server response to spoof because there's no server involved in the check at all.
This is the same flow shown live on the homepage's examiner-package demo: generate a package, and the bundled attestation includes a checkpoint ID, Merkle root, tree size, and signer key ID that the CLI verifies independently.
Rekor anchoring extends this one step further: checkpoint roots can also be posted to Sigstore's public Rekor transparency log — real network code (api/domains/attestation/anchor.py:114-156), not a stub — putting a copy of "this root existed at this time" outside Coriqo's own infrastructure entirely. If Rekor is unreachable, the checkpoint still seals locally and anchoring is retried later; it never silently claims to be anchored when it isn't.
api/domains/attestation/anchor.py:114-156
content_hash_verifiable=False rather than silently counted as verified. Coriqo's chain verification reports that count rather than overstating what it can prove for pre-existing history.
A second industry is a rulepack, not a second product.
Coriqo separates the part that is universal from the part that is jurisdictional. The chain, the seal, the state machine, and the external verification portal know nothing about banking or healthcare. What a given framework requires lives in a checked-in YAML rulepack that the loader picks up, and which pack a workspace runs is a per-tenant setting.
Everything that makes the record trustworthy
Append-only events, SHA-256 chaining, Merkle checkpoints, Ed25519 signatures, segregation of duties, and the time-boxed read-only portal an outside reviewer uses. None of it is industry-specific, and none of it is rewritten per vertical — a hospital AI committee and a bank examiner check the identical code path.
One YAML file per framework
A rulepack is a list of requirements with anchors, a severity, and citations. sr11_7.yaml is the banking pack; ruaih.yaml carries the Joint Commission's RUAIH domains cross-referenced to ONC HTI-1 source attributes, and nist_ai_rmf.yaml holds NIST AI RMF 1.0 as the framework substrate. Adding a jurisdiction means appending records, not changing a code path.
Rulepack, vocabulary, decision classes
A vertical descriptor names which packs a workspace may run, which vocabulary its screens use, and which decision classes it governs — for healthcare, diagnostic recommendation, treatment plan, and risk stratification. Two tenants on the same deployment can run different frameworks without either one seeing the other's language.
Model risk discipline doesn't require a 40-person department.
SR 26-2 tailors what it expects to the size and complexity of the bank, and generally excludes banks under $30 billion altogether. What it does not do is excuse them from governing models: §II says those banks are subject to internal risk management and governance practices suited to their own risk profile. Independent review, documented effective challenge, and a record of every model decision are still the substance — the difference is that a smaller bank now defines the standard rather than inheriting it. What differs is the tooling available to meet it. Enterprise MRM platforms are built and priced for the forty-person team. Coriqo is built for the other case, which is most banks.
FIS, Fiserv, Jack Henry, FICO — not built in-house
A community or mid-size bank's model inventory is dominated by core-processor and scoring models it didn't build and can't retrain. Governing "someone else's model" is a different problem than governing your own — vendor documentation, your own gap analysis against it, and a due-diligence cadence become the primary artifacts, not model code review. Coriqo treats vendor validation reports and model cards as first-class, hash-bound to the version they cover, and tracks the bank's own user-gap findings and vendor review dates against them directly.
Segregation of duties as a server-side rule
"The reviewer must be independent of the producer" and "an approver can't be the same person who submitted or reviewed" are the substance of SR 26-2 §III's effective challenge, and are trivially easy to violate by accident in a two-person team under deadline pressure. Coriqo enforces both as hard, role-checked blocks in the governance state machine itself — not a policy written in a document that depends on someone remembering it during a busy quarter.
Trust the math, not the vendor's uptime
A lean team's biggest exam-prep risk isn't bad governance decisions — it's not being able to reconstruct and evidence the decisions it already made, three years later, when the examiner asks. An append-only, independently verifiable record is a direct answer to that specific failure mode, and it matters more for a small team with no dedicated documentation staff than for a large one.
"System of record, not the decider" — the same framing Coriqo's own committee-governance code comments use internally, and the honest description of the product's role everywhere in it: quorum tallies are computed and cross-checked, but a chair's judgment call on "approve with conditions" is never overridden by a vote count.
What's shipping today, what's still on the roadmap — stated plainly.
Sophisticated buyers — and examiners in particular — are trained to distrust a vendor who claims everything is finished. So here's the honest split, reusing the same shipping/roadmap distinction shown on the homepage's architecture section, plus a few specifics worth knowing before a demo.
Validation & audit
Inventory, lineage, sign-off, examiner packages — the core governance state machine and hash chain
Documents & evidence
Central library, cited cross-document search, and evidence correlated to models and NIST controls under human review
Ongoing monitoring
Threshold breaches auto-logged as governance events; email alert to model owner ships today, broader alerting does not yet
Board reporting
Quarterly MRM report for the board and audit committee — generated from the record
Coriqo is currently a design-partner-stage product, not a company with a long public track record — we'd rather say that outright than let a polished page imply otherwise. What is real: the governance state machine, the hash chain, the Merkle attestation, and the verify_proof.py CLI referenced above are all working code in this repository today, not mockups built for this page.
We're looking for a small number of design partners — bank risk officers, MRM leads, clinical AI vendors, and the validation consultants who serve this segment — to tell us what we've got wrong before we build more. If that's you, the direct line is below.