Every module, sorted by the question it answers.
Boards, examiners, hospital committees and your own staff ask the same few things about any AI system. Did a person decide? Did the right person know in time? When it went wrong, who owned it and was it fixed? Can we check that ourselves? The modules below are grouped by which of those questions they answer, so a problem is caught early and you can prove later that it was.
- Live
- In the product today and in use by our design partners
- New
- Shipped most recently
- Alpha / In development
- Labelled where they apply
These are not separate tools. They all write to one record.
You find the AI you run. A named person decides, and the evidence behind the decision is attached. The right person hears about problems in time, and someone owns the fix. Every step goes into the same record, so your examiner can check it and your committee works from it. Each module you add makes the others more useful, because they share that one record instead of each keeping its own.
Know what's running before you're asked to prove it.
When the board asks how many AI systems you run, someone has to give a number they can stand behind. The register lists every model and agent, including the ones nobody submitted for governance, so the answer comes from what is actually running and not from last quarter's spreadsheet.
Model inventory
Every model your governance program covers, with status, owner, and validation stage in one register.
Agent inventory
AI agents are tracked the way models are, with the same lifecycle and the same evidence standard. No separate spreadsheet.
Shadow-AI discovery
A read-only scan of AWS SageMaker, Bedrock and S3. It compares what is running with what you govern and flags the gap.
Model & agent detail
One page per model or agent: what it is, where it is in its life, findings, evidence, version history and sign-off status.
Sign-off status on the page
The latest committee decision and how much of the sign-off is complete, shown on the model's own page. No separate screen.
Evidence-request time saved
The typical (median) time to answer an evidence request, and the hours saved compared with pulling it by hand, shown on the model's own page.
Knowledge graph
Models, agents, datasets and owners linked together, so you can see what connects to what instead of hunting through separate records.
Version lineage
Every version of a model traced from first submission through retraining to retirement.
A named person decides. The record keeps who, when and why.
Each model, agent and document goes to a named reviewer, gets challenged, and is signed off by a person. Their name and the date go into the record and can't be changed later. Nothing reaches sign-off without the evidence behind it. Coriqo flags gaps and records decisions; it never makes them.
Evidence the reviewer looked
“A human approved it” is a weak defence. Where a sign-off is made in Coriqo, it records whether the reviewer opened the cited evidence and how long they spent with it, then seals that with the approval. You choose what is measured, and it is off until you turn it on. It reports what happened; it never calls a person careless.
Review queue
What needs a human decision, in a queue. The person who prepares something can't also review it.
Document approval
Each document is challenged against the rules your workspace runs before it counts as evidence. That is SR 26-2 for banking, and Joint Commission RUAIH cross-referenced to ONC HTI-1 for clinical AI.
Scope determination · SR 26-2 §II
Whether something counts as a model under §II gets a recorded answer. Three questions, and the record keeps the answers, the outcome, and the rule that produced it. Every out-of-scope result names what governs the asset instead: spreadsheet controls, change management, or your AI rule sets. The determination, and every earlier one, sits on the model's own page.
Validation schedule for each model
How often a model is revalidated is set model by model, with a written reason and the name of the person who set it. §V prescribes no frequency, so the overdue list shows whether someone chose the interval or it came from the platform's old 365-day default. You set it from the model's page, and a blank reason is not accepted.
Submission checks tied to your rules
A check blocks a submission only when one of your installed rule sets requires it, and the message names that rule set. A high-risk model with no fairness metrics is blocked in a workspace running the NIST AI RMF or EU AI Act rules. In a workspace running only the banking rules, the same gap appears as an advisory readiness item and nothing is blocked.
Control coverage
Which required controls are covered, by which evidence, for every model in scope.
Oversight gaps
Shows where governance coverage is thin, before an examiner finds it first.
Attention dashboard
What needs a decision today, ranked, instead of a wall of everything that has ever been open.
Findings tracker
Every finding from every review, its severity, and its remediation status in one governed record.
Ongoing monitoring
Continuous checks between full revalidations, instead of a single review at one point in time.
Operations view
How the program itself is running: how much gets done, what is waiting, and how long it has waited.
Program dashboard
Model risk at a glance: inventory, open findings, the validation queue, and what is waiting on you.
Overdue & alerts
Overdue reviews and attestations surfaced before they become an exam finding.
When someone asks "where did that come from?", the answer is a page.
A validator, auditor or examiner who questions a finding can click through to the quoted sentence on the cited page. Documents, evidence requests and the discussion behind a decision are kept as governed evidence, searchable and tied to their source.
Documents & evidence library
Every document behind a model or agent, searchable across all of them. Ask one question across every document instead of opening them one at a time.
Document viewer
Every finding is pinned to an exact quote on a cited page. Click a finding, see the source.
Evidence requests
Requests to model owners tracked to close, with turnaround time recorded automatically.
Evidence correlations
Related evidence across documents is found automatically, then confirmed by a person before it counts.
CSV / Excel import
Bring existing model inventories and evidence in from the spreadsheets you already maintain.
Live system connectors
Read-only connections to the systems where evidence already lives. No re-keying, and your live systems don't depend on Coriqo.
Communications
Teams and email threads linked into the record, so the discussion behind a decision is evidence too.
A record your reviewer can check without trusting you.
An examiner, auditor or board member can confirm for themselves that nobody changed the record after the fact, without a Coriqo account and without taking your word or ours. Underneath, every governance event goes into a chained log that shows any later change, and anyone with the public key can check it.
Append-only event log
Every governance action (a decision, a sign-off, a finding) is written once and never altered.
Merkle checkpoints
Every so often the log is boiled down to a single fingerprint (a Merkle root), so any change made afterwards can be detected.
Ed25519 signing
Each checkpoint is cryptographically signed. Anyone with the public key can verify it, and no account is needed.
Passkey countersignatures
When your people sign in with a passkey, their device also signs the newest checkpoint with a key Coriqo never holds. Nothing to set up.
Key transparency
The signing key's history is itself logged and open to audit, so swapping keys can't be used to rewrite history quietly.
Checkpoint verifier
A standalone tool that anyone, including your examiner, can use to check a checkpoint without relying on Coriqo.
Public anchoring
Every checkpoint is published to a public log and time-stamped by an outside time authority, so its date doesn't rest on Coriqo's servers.
AI output verifier
Check any AI-drafted finding against the source it cites. This is a separate step from verifying the checkpoint chain.
Send your partner bank a link, not a folder.
A Trust Room is a page you send to a partner bank, a customer or an examiner. They open it without a Coriqo login. You choose which agents it covers and how many days the link stays open, and you can revoke it sooner, which cuts access on the next request. A room shows what your record holds. It is not a certification and makes no claim about compliance.
Only what you picked
The agents you chose and their current mandates, findings opened and closed, retest results and your latest signed checkpoint. Totals only, unless an admin allows item-level detail. Finding text is never shown.
Every view is logged
Each view of the room and each download of its verification file goes into your audit log and is sealed on the record. The room's view log lists them with the time.
A file they check themselves
The room hands out verification.json: the page, its sha256, a hash of the settings the room was made under, and a signature over them. The reader checks it with the open-source verifier on their own machine.
The meeting becomes part of the record.
When a committee approves a model with conditions, the decision and its conditions are recorded as they are made. Board reports are drawn from that same record, so nobody has to rebuild the story at the end of each quarter.
Committee decisions
Every model risk committee decision (approve, approve with conditions, return to developer) goes into the record.
Minutes into the record
Invite Coriqo to the meeting and the minutes go into the record as a tamper-evident entry instead of a loose document.
Board reporting
The quarterly board report is generated from the record, so nobody rebuilds it by hand each quarter.
Vendor-model review cadence
Due dates for third-party model reviews tracked and surfaced before they're overdue. SR 26-2 §VII covers vendor and other third-party products; the cadence itself is yours to set.
Yearly regulatory attestations
Start this year's certification or board report from last year's signed answers. Anything that changed since then is flagged for review, and the signers see the evidence before they sign.
Built for the day the examiner, or the review committee, shows up.
The person across the table gets a scoped, read-only portal and a package assembled from the record. Your team answers their requests from one place instead of rebuilding the history by email the week before.
These screens are named for whoever is reviewing you. A banking workspace sees examinations, examiner packages, and an examiner portal. A healthcare workspace sees the same screens labelled surveys, committee review packages, and a reviewing committee portal. The vocabulary is a setting on each workspace, and both run the same build.
Examinations
Active and past exams, their scope, and every request tied to each one. Run the exam from one place.
One-click examiner package
An exam-ready export assembled from the record, so the week before the exam is not a scramble.
Examiner portal
A read-only view, limited to what the examiner needs. No email attachments and no risk of re-sharing.
Exam case IDs & incoming email
Examiner requests tracked by case ID, with an email address that files incoming requests straight into the record.
Regulatory packages
Regulatory submissions beyond the exam package, built and versioned the same way.
The alert that matters reaches a person. The rest can wait for the weekly digest.
When every technical problem is treated the same, the one that matters gets buried between two that don't. Coriqo rates each alert by what it could mean for your bank, sends it the way you decided, and records who knew and when. Publishing a log is not the same as someone knowing.
Impact levels your bank sets
Each alert gets an impact from 1 to 10, worked out from records you already keep: the model's materiality and what the agent is allowed to do. You decide what a 10 is, and every change to that scale is recorded.
Routed by impact and track record
Page someone now, send it the same day, put it in the weekly digest, or record it without interrupting anyone. The route depends on the alert's impact and on how often that kind of alert has turned out to be real.
Your pager, opened to closed
An alert opens an incident in your PagerDuty or Opsgenie, acknowledges it there when someone acknowledges in Coriqo, and closes it when the alert is resolved. Alerts can also go to Slack, email, Teams or a webhook (an automatic message to another system), each with a runbook link.
A burst becomes one alert
Repeated alerts from the same model or agent fold into one, with a count and a last-seen time, so a flood of small events doesn't hide the one that needs a person.
Every alert rule has a track record
Resolving an alert records whether it was real. Each rule shows how often it was confirmed, and a rule that is mostly false alarms is flagged for review. It is never silenced on its own.
When did a human know?
Raised, delivered, acknowledged, escalated and resolved: each step goes into the tamper-evident record with who and when. The evidence export ties every step to an entry an examiner can check.
Warnings before the breach
Flag a model heading for a threshold before it crosses, and warn early when an alert is likely to go unanswered. Every forecast is scored against what happened, and the forecasting model is documented in your own inventory like any other model you govern.
Coriqo does not send SMS or run on-call rotations. Alerts reach your paging tool through its own events API, so your rotation stays where it is.
Clears IT vendor review before it clears procurement.
Your security and IT teams review Coriqo against the sign-on, roles and deployment rules they already enforce. It doesn't add a new security boundary for them to explain.
Microsoft 365 / OIDC SSO
Single sign-on against the identity provider you already run.
Email from your own Gmail or Outlook
Connect your mailbox once, and the emails to your committee and your examiners come from your address, not ours. Coriqo can send from it but cannot read anything in it. When someone replies, you see it in your inbox and it lands in the record too. Committee invitations arrive with Yes, No and Maybe buttons. On Pro and above.
Role-based access control
Preparer, reviewer, committee and examiner roles, enforced by the platform itself.
Connector management
Manage every read-only connection to your source systems from one screen: what is connected and what is in scope.
Separate data for each workspace
Each workspace's data is kept apart in its own database schema, not marked by a flag on rows in a shared table.
Private cloud / on-prem
Deployment options where policy requires data to stay off shared infrastructure.
Choose the rules per workspace
Each workspace chooses the framework it governs against in its settings, with no rebuild. Banking runs SR 26-2; clinical AI runs RUAIH and HTI-1 over NIST AI RMF 1.0. Generative and agentic systems sit outside SR 26-2 under footnote 3, so they are governed against the NIST AI RMF and EU AI Act rule sets a workspace installs. Healthcare details.
Zero-retention AI
AI used for drafting and search doesn't train on your data and doesn't retain it beyond the request.
Citation-grounded AI drafting
AI drafts findings and summaries with every claim tied to a source citation. No answer without a page to point at.
Named-person approval gate
No AI output becomes part of the record until a named person accepts or overrides it.
Every capability, and which plan carries it.
This list is read live from the product. Plans are on the pricing page.
The live list isn't loading right now. Every plan's contents are on the pricing page.
Want to see any of this on your own models?
The demo runs on illustrative sample data. Walk a model from submission through committee to an examiner package.