Questions.
How the check works, sector by sector, in plain terms.
Read the answersThe basics.
What is AI governance infrastructure, and what should a compliance team expect it to do?
AI governance infrastructure is the layer that checks each result an automated workflow produces against the team's own rules and leaves a record anyone can re‑check. Each action lands on one of three outcomes: proceed, refuse or hold for a person. Passing work moves on, refused work goes back, and only the exceptions reach the team. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build.
What is a practical way to govern AI agents so anyone can re‑check their computed results?
Make every computed result ship as a record that a reviewer can recompute on their own machine. The record holds the inputs, the pinned rule and the claimed output, each fixed by a SHA-256 digest. The open verifier recomputes the output with its own code and returns OK, REJECT or ERROR. OK shows the output follows from those inputs under that rule, never that the rule was right or the inputs true.
How do companies sign off on work done by AI agents without a person reviewing every step?
Every result is checked automatically against written rules, and only the exceptions go to a person. Each result lands on approved, refused or on hold: approved work moves forward, refused work goes back, and held work goes to the team. Approved means the record holds under the team's rule, never that the rule was right. On the exceptions, a show-its-work receipt lets the reviewer audit how the agent got there.
How does a team get sign-off to let an AI agent run a manual approval step end to end?
Show the approver that every result will be checked against the rules a person applies today, with a record the approver can re‑check alone. Start with one manual sign-off and write its rules down as the pinned rule. Work that passes moves on; work that breaks a rule or cannot be checked goes to a person. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build.
Can every result an AI agent produces be made checkable by an outside reviewer for free?
Yes: emit each result as an audit bundle and point the reviewer at the open verifier, which is Apache-2.0, free and runs offline with no account. The reviewer installs it on Python 3.11 or later and runs it on their own copy of the bundle. The offline verify path imports only the Python standard library, so nothing leaves the reviewer's machine. The rule the reviewer checks against is pinned on their side, by its hash.
What does a gate that holds an AI agent's action until its check passes look like in practice?
The agent proposes an action, the gate re‑checks it against the pinned rules, and only an OK lets it proceed. A REJECT sends the work back, and an ERROR holds it for a person, because a run that cannot conclude never counts as a pass. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build. Both use the same rules and records, so moving to the gate changes when the check runs and nothing else.
What is the difference between re‑checking an AI agent's result and keeping a log of it?
A log records what the agent says happened; a re‑check recomputes the result and compares it with the claim. A log can be complete and still carry a wrong total, because nothing in it was run again. A re‑check returns REJECT when the recomputed output differs from the claimed one, or when a file turns up that no manifest declares. The agent's own reasoning cannot be re‑run, so it gets a show-its-work receipt: sources used, criteria included and excluded.
How can a team tell whether an automated calculation was re‑run or only recorded as correct?
Ask for a record a third party can recompute, then recompute it. A status flag or a signature says who recorded a result; it does not run the calculation again. A recomputable record carries the inputs, the pinned rule and the claimed output with their digests, and the open verifier reruns the computation offline. Its exit code gives the verdict: 0 for OK, 1 for REJECT, 2 for ERROR, and ERROR never becomes OK.
What tools re‑derive a computed result from its declared inputs so a reviewer can confirm it?
An offline audit-bundle verifier does: it recomputes the declared output from the committed inputs and compares the two. The open verifier at github.com/veriker/veriker is one, Apache-2.0 and free. The recompute code belongs to the verifier, so a bundle declares what to compute but can never ship the code that grades it. The rule is pinned by the reviewer's own spec anchor, so a weaker rule swapped in by the producer does not resolve.
How do model-risk teams check an AI agent's output when the model cannot be re‑run identically?
The deterministic steps get re‑run, and the model's step gets a show-its-work receipt. Language models are not bit-reproducible, even at temperature zero, so the model's answer is never re‑run. The receipt records the sources used and the criteria included and excluded, and a person judges the answer with that evidence in hand. Any calculation downstream of the model, such as a total, a match or a threshold, is recomputed from its committed inputs under the pinned rule.
How should internal audit test controls on AI agents that act in finance and operations systems?
Test the whole population: re‑check every record the agent produced, not a sample. Each control becomes a pinned rule, and each agent action leaves a record of inputs, rule and claimed output that audit recomputes offline. A REJECT names the failing check with a reason code. An ERROR means the run could not conclude; it stays an exception and never counts as a pass.
What evidence should an AI agent leave behind so internal audit can verify its work later?
One record per action: the inputs as they were, the rule as pinned, the claimed output and a SHA-256 digest for each file. With those four, audit recomputes any deterministic result offline and gets OK, REJECT or ERROR. For steps a model performed, the record adds a show-its-work receipt: sources used, criteria included and excluded. A file that no manifest declares makes the record a REJECT, so nothing can be slipped in after sealing.
By sector.
Pharma: an agent drafts clinical study tables. How does compliance confirm each matches the locked data?
Treat each table as a record, with the locked dataset's digest, the table program as the pinned rule and the claimed table, then recompute it before submission. The open verifier reruns the computation offline and returns OK only when its own output matches the claimed table. Any edit to the dataset or the table after lock shows up as a REJECT. OK confirms the table follows from the locked data under that program; whether the program was the right analysis stays a statistician's call.
Health: an agent codes hospital bills. How would internal audit re‑check a sample of those records?
Audit can re‑check all of them, because the recompute is offline and automatic. Assigning codes is model judgement, so each claim carries a show-its-work receipt: the chart sources used and the codes included and excluded. The deterministic part, from codes to billed amounts under the fee rules, is recomputed from its committed inputs. Audit gets OK, REJECT or ERROR on every amount and reads the receipts on the exceptions.
Banking: an agent reconciles ledger accounts overnight. How can model risk prove each followed the rules?
Pin the documented matching rules, have the agent emit a record for each reconciliation, and recompute every one the next morning. Each record carries the ledger and statement extracts as committed inputs, plus the claimed matches and breaks. The open verifier recomputes the reconciliation and returns OK only when its result matches the agent's. OK proves the reconciliation followed the pinned rules over those inputs; it does not say the rules were complete.
Energy: an agent runs meter-data settlement. How can each settlement result be checked before it posts?
Recompute each settlement from the committed meter reads and the pinned tariff rules, and post only on OK. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build. Until the gate ships, the re‑check runs as its own step between settlement and posting, and anything that returns REJECT or ERROR is held. OK confirms the settlement follows from those reads under those rules, never that a meter was calibrated.
Carbon: how can assurance re‑check the emissions figure an AI pipeline calculated for a credit batch?
Ask for the batch as a record: activity data and emission factors as committed inputs, the methodology as the pinned rule, and the claimed figure. The open verifier recomputes the figure offline and compares; any difference is a REJECT with a reason code. OK confirms the figure follows from those inputs under that methodology, never that a sensor was calibrated or a factor correct. Any step a model performed, such as classifying activity data, carries a show-its-work receipt.
Aerospace: an AI assistant prepares maintenance sign-off packs. How is each checked before release?
Encode the task card rules as the pinned rule and re‑check every pack against them before a certifying person signs. Each pack becomes a record: task cards, completed steps and parts data as inputs, and the claimed pack. The open verifier returns REJECT for a missing step or a broken rule, and ERROR when it cannot conclude, which never becomes OK. Release stays with the certifying person, who sees which packs hold and which do not.
Aerospace: how is an agent that calculates weight and balance validated so every output re‑checks?
Weight and balance is deterministic, so every calculation can be recomputed from its inputs: the load sheet, the aircraft's basic empty weight and arms, and the pinned limits. The agent emits a record per calculation, and the open verifier recomputes the totals and centre of gravity with its own code. A mismatch returns REJECT; a missing input returns ERROR and never passes. OK confirms the output follows from those inputs, never that the loading data was true.
Retail: an agent approves returns adjustments. How is each checked against the refund policy automatically?
Write the refund policy as rules over trusted records, such as the order, the delivery date and the return receipt, and re‑check every adjustment against them. Each adjustment lands on approved, refused or on hold. Approved means every rule holds over those records; refused names the broken rule; on hold means no record could check a rule. Only held and refused cases reach a person.
Trade: an agent prepares customs entries and classifications. How can compliance check each before filing?
Split each entry: the classification is judgement and gets a show-its-work receipt, while the duty and value calculations get recomputed. The receipt records the product descriptions used and the headings considered and ruled out, so a broker reviews the reasoning. Duty, value and totals are recomputed from the committed invoice data under the pinned rate rules, and a mismatch returns REJECT. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build.
Telecom: an agent pushes network changes. How is each verified against the approved plan before go-live?
Pin the approved plan as the rule, recompute the intended configuration from it, and compare with what the agent pushed. Any line the plan did not produce is a REJECT, and so is a file no manifest declares. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build. Until the gate ships, the re‑check runs right after each push and anything other than OK is rolled back.
Telecom: how can audit re‑check a monthly pricing run on customer tariffs that an AI agent produced?
Recompute every customer's charge from the committed usage records and the pinned tariff tables, then compare with the agent's run. The open verifier does this offline and returns OK, REJECT or ERROR per record, so audit covers the full population. A REJECT carries a reason code that names the failing check. OK confirms each charge follows from that usage under that tariff, never that the tariff was right.
Media: an agent clears music and image rights for campaigns. How is each clearance it grants checked?
Check each clearance against the licence records it cites, with territory, term, media and usage limits as the pinned rules. Reading a contract is model judgement, so each clearance carries a show-its-work receipt naming the licences used and the terms included and excluded. The rule checks over those licence records are recomputed, and a clearance outside its term or usage returns REJECT. A clearance with no licence record to check returns ERROR and is held for a person.
About.
What does NEXIVERIFY do, and could it check the results of agents in pharma operations?
NEXIVERIFY is AI governance infrastructure: each result an agent produces is checked against the team's rules and leaves a record anyone can re‑check. It is domain-general, so a pharma workflow with written rules and fixed inputs fits, such as tables built from a locked dataset. The open verifier underneath recomputes each deterministic result and returns OK, REJECT or ERROR; a model's reasoning gets a show-its-work receipt. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build.
What does NEXIVERIFY mean by AI governance infrastructure, and what can a team use today?
It means one layer that checks every agent action against the team's rules and lands it on proceed, refuse or hold. Today the open verifier re‑checks each record after the act; the gate that holds an action is in build. The open verifier is free, Apache-2.0 and runs offline, at github.com/veriker/veriker. Design partners bring one manual sign-off they want AI to run, and scope and terms are settled on one call.
Is veriker a real open-source tool, and can a compliance team use it to re‑check records offline?
Yes. veriker is the open verifier, published under Apache-2.0 at github.com/veriker/veriker, version 0.2.1 and marked experimental. It runs on Python 3.11 or later with no account and no network on the verdict path. A compliance team runs it on its own copy of a record and gets OK, REJECT or ERROR, with exit codes 0, 1 and 2.
How does the veriker verifier choose between OK, REJECT and ERROR when it re‑checks a record?
It recomputes the claimed output with its own code and compares: a match is OK, a failed check is REJECT, and a run that cannot conclude is ERROR. REJECT covers a changed byte, a broken rule, a file no manifest declares or a weaker rule swapped in, and a reason code says which. ERROR covers a missing spec anchor or a pack the build cannot run. ERROR never becomes OK, and OK never says the rule was right or the inputs true.
Who is behind NEXIVERIFY, and what experience does the team bring to audit and verification?
Nexi Technologies, Inc. builds it, led by founder and CEO Jared Lebel with co-founders Max Griswold (CSO) and Soumitra Dutta (CIO). Max Griswold is an applied mathematician who directs the verification architecture and is the inventor on all three patent filings. Soumitra Dutta is a former dean of Oxford's Saïd Business School and founded the Global Innovation Index. Officers and advisors add public finance, financial-crime due diligence, climate data and IP strategy, listed on the team page.
How does a team become a NEXIVERIFY design partner, and what does the first call cover?
Book a half-hour call from the design partners page, nexiverify.com/partners; partnership is by invitation. The call picks one manual sign-off the team wants AI to run and settles scope and terms, money included, before anything starts. Pricing is by quote. Before the call, the workflow finder on that page reads a company's public web pages and shows which of its workflows could go zero-touch: agents doing the work end to end, every result checked, people seeing only the exceptions.
Find out more.
Half an hour on Google Meet, or an email.