For the people whose job is to doubt the record: how Coriqo is built, and what isn't finished yet.
Written for security teams, validators, bank examiners and hospital AI committees. Their question: can I confirm who approved this AI system, and when, and that nobody changed the record afterwards, without taking the vendor's word for it? "Trust us, it's tamper-evident" is not a claim anyone should accept from a vendor, including us. Below is how you can check for yourself, why we made the choices we did, and a plain account of what has shipped and what is still on the roadmap.
Everything described below is working code today. Where something is partial or still on the roadmap, we say so.
A log that only grows, signed checkpoints, and checking that doesn't need us.
An examiner looking at one approval needs to know three things. Nobody edited it later. It belongs to a signed, fixed version of the record. And they can confirm both without Coriqo's help. Each design decision below answers one of those, and each closes a specific way an evidence record can quietly go wrong.
Why the log only grows, instead of being "editable with a history tab"
Most tools that claim an "audit trail" are really an ordinary 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 just another row that can be edited. 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, such as the notes, the actor or 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.
We left timestamps out of the hash on purpose. Two servers' clocks can disagree slightly, and that shouldn't break a chain that is otherwise intact. It is a small decision, and it matters more than it looks once you have run systems at a bank.
Where:compute_governance_event_hash() builds the preimage, and the governance endpoints append and verify on demand
Why signed checkpoints (a Merkle tree), not just a longer hash chain
A hash chain alone can prove the whole history is intact, but only by walking the entire chain from the start. That is slow, and an examiner checking one event would have to receive every event before it and trust that none were left out. Coriqo periodically seals the event log into a Merkle tree and signs the root with Ed25519 (the checkpoint service). That gives an inclusion proof: a small, downloadable bundle that proves one specific event was included in a specific, signed root. It needs only a handful of comparisons. For a chain of 10,000 events, that's roughly 14 comparisons to prove any single one, where walking the chain would take 10,000.
This is the same idea behind Certificate Transparency, the public log every browser already relies on to catch wrongly issued website security certificates. Coriqo applies the same well-understood technique to AI evidence records instead of certificates.
Where: the checkpoint endpoints (Merkle root computation, Ed25519 signing, downloadable inclusion proofs)Why checking 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 its own records are valid, the examiner is still trusting the vendor, and that defeats the point. So the checking tool is a standalone command-line program, tools/verify_proof.py, that takes a downloaded proof bundle and Coriqo's public key and runs entirely offline. It makes no network call, needs no API key and talks to no Coriqo server. It recomputes the 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 is no server response to fake, because no server is involved in the check.
The homepage's examiner-package demo shows the same flow. Generate a package, and the attached proof includes a checkpoint ID, Merkle root, tree size and signer key ID that the program verifies independently.
Public anchoring goes one step further. Checkpoint roots can also be posted to Sigstore's public Rekor transparency log (real network code against Rekor’s API, not a stub). That puts a copy of "this root existed at this time" outside Coriqo's own systems entirely. If Rekor is unreachable, the checkpoint is still signed locally and anchoring is retried later. It never claims to be anchored when it isn't.
Where: the CLI referenced above ships alongside the checkpoint attestation shown in the homepage examiner-package democontent_hash_verifiable=False rather than silently counted as verified. Coriqo's chain check reports that count, so it doesn't overstate what it can prove about older history.
A second industry is a new set of rules, not a second product.
A bank examiner and a hospital AI committee ask different questions, but both need the same proof that a person decided and the record wasn't changed. So Coriqo separates what is universal from what depends on the regulator. The chained record, the signed checkpoints, the approval workflow and the outside verification portal know nothing about banking or healthcare. What a given framework requires lives in a rulepack, a plain YAML file of requirements that the software loads. Which rulepack a workspace runs is a setting for that customer.
Everything that makes the record trustworthy
Append-only events, SHA-256 chaining, Merkle checkpoints, Ed25519 signatures, separation of duties, and the time-limited read-only portal an outside reviewer uses. None of it is specific to one industry, and none of it is rewritten for each one. A hospital AI committee, a bank examiner and a privacy auditor all check the same code.
One rulepack 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; eu_ai_act.yaml carries the EU AI Act's Title III requirements and is also the auto-run baseline privacy workspaces run on; nist_ai_rmf.yaml holds NIST AI RMF 1.0 as the framework substrate. Adding a jurisdiction means adding records to a file. The software stays the same.
Rulepack, wording, decision types
For each industry, a short description names which rulepacks a workspace may run, what wording its screens use, and which kinds of decision it governs. For healthcare those are diagnostic recommendation, treatment plan and risk stratification. For privacy they are employment identity, financial services identity, housing and education. Two customers on the same deployment can run different frameworks, and neither sees the other's wording.
Good model risk practice doesn't need a 40-person department.
A risk officer at a smaller bank still has to show who reviewed each model and who challenged it, usually with a much smaller team. 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. A smaller bank now defines the standard rather than inheriting it. What differs is the tooling. Enterprise governance platforms for models and agents 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 from governing your own. The vendor's documentation, your own gap analysis against it, and a schedule of due-diligence reviews become the main evidence in place of a review of model code. Coriqo treats vendor validation reports and model cards as core records, each tied by hash to the version it covers. It tracks the bank's own gap findings and vendor review dates against them.
Separation of duties built into the software
"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. They are easy to break by accident in a two-person team under deadline pressure. Coriqo enforces both as hard blocks, checked by role, inside the approval workflow itself. It is not a policy in a document that depends on someone remembering it during a busy quarter.
The math works without the vendor's servers
A lean team's biggest exam-prep risk is usually being unable to show, three years later, the decisions it already made. A record that only grows and that anyone can verify answers that problem directly. It matters more to a small team with no dedicated documentation staff than to a large one.
"System of record, not the decider." That is how Coriqo's own committee code describes itself, and it is the honest description of the product's role everywhere. The software works out the vote tally and checks it against what was recorded, but a chair's judgment call on "approve with conditions" is never overridden by a vote count.
What's shipping today and what's still on the roadmap, stated plainly.
Examiners and careful buyers are trained to distrust a vendor who says everything is finished. So here is the plain split, using the same shipping and roadmap labels as the homepage's architecture section, plus a few specifics worth knowing before a demo.
Validation & audit
Inventory, version history, sign-off and examiner packages. This is the core approval workflow 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, an alert queue with acknowledgement, and a drafted incident memo that can be put straight on a committee agenda
Board reporting
A quarterly readout for the board and audit committee: red/amber/green status, change since last quarter and everything overdue, drawn from the chained record
Alerting & escalation
Alerts rated by an impact level your bank sets, sent as a page now, the same day or in the weekly digest, escalated when nobody acknowledges a page, and opened, acknowledged and closed in your PagerDuty or Opsgenie. SMS and on-call rotations are not built
Continuity certificate
A dashboard tile that says whether the record has been unbroken, and since when, plus a signed certificate for each year that the board can check offline
Supplier list
Suppliers kept as sealed records with review dates from your policy, and AI vendors' due-diligence answers signed with the vendor's own key. How it works
Deploy check for agents
A release pipeline asks Coriqo whether an agent may go live, and the deploy stops when the mandate is missing or nobody approved it. See the command
Warnings before the breach
Forecasts that a model is heading for a threshold, each scored against what happened, with the forecasting model documented in your inventory
Scheduled warehouse feeds
Read-only AWS and Azure discovery and Microsoft 365 mail/calendar capture are live; a scheduled warehouse feed, such as a Snowflake pull, is not built
Coriqo is a design-partner-stage product, not a company with a long public track record. We would rather say that outright than let a polished page suggest otherwise. What is real: the approval workflow, the hash chain, the signed checkpoints and the verify_proof.py program described above are all working code today.
We're looking for a small number of design partners to tell us what we've got wrong before we build more. That means bank risk officers, leads who govern models and agents, clinical AI vendors, and the validation consultants who serve them. If that's you, the direct line is below.