Validation and inspection-readiness
Your real fear: the agent takes the one irreversible action it never should have.
So here is the line it will never cross. It will gladly escalate something routine, the cheap mistake. It will refuse to take the irreversible action it should not, the expensive one. That line lives outside the model, in code: the agent that proposes an irreversible action is refused as its own approver, a hard 403. You set where the line sits, the code enforces it, and your own inspector gets a signed file they can re-verify offline, with no access to your systems.
Inspection-readiness
The evidence an inspector can pull, read, and re-verify themselves.
Inspection-readiness is not a binder you assemble the night before. It is an artifact the running system produces on every action, signed at the moment it happens, and re-checkable by an outside inspector who has no access to anything of ours.
Hash-chained audit
A tamper-evident record
Every agent action and every human decision commits as an append-only entry that carries the hash of the entry before it. Change one row and every downstream hash breaks, so an edit to the store is detectable by the same verifier an inspector runs. The state change and its audit event commit in one transaction, so an action cannot be left unlogged.
Ed25519 signature
Offline-verifiable, no account
The chain head is signed with an Ed25519 key, and the verifier needs no network, no login, and nothing of ours. An inspector takes the exported evidence file to an air-gapped machine and reverifies the whole run for themselves. Write access to the database is not enough to forge a record, because a re-signed forgery fails against the published public key.
Segregation of duties
Independence, enforced in code
The identity that did the work is barred in code from signing off the decision that matters: the agent that proposes an irreversible action is refused as its own approver. In the shipped pharmacovigilance flow the gate is identity-mode (forbid_requester), so the person who triggered the run gets a 403 deciding it. The audit records the separation, so the trail shows two distinct, named people, not one person wearing two hats.
Part 11 e-signature
The full signature manifestation
The signed export carries what 21 CFR Part 11.50 asks a signature to manifest: who signed, the date and time they signed, the meaning of the signature (the approval), and the verbatim reason they typed at the gate. We produce the evidence Part 11 asks for. The hash chain goes beyond what it requires, and we never claim Part 11 demands one.
The auto-close boundary
Exactly which actions the agent may complete on its own.
The deal-killer is not that an agent helps. It is the fear that one quietly takes an irreversible action it had no business taking. The honest answer is a narrow, deterministic line, rule-based on the action's structured inputs, configured by you, enforced in code outside the model, and built to fail toward the human. The pharmacovigilance flow below is one worked example.
- What may auto-closeOnly the deterministically routine. In the shipped pharmacovigilance flow, a case routes to periodic handling on its own only when it is non-serious AND expected, evaluated against its structured fields. The triage is a rule over the case data, not a learned model and not a guess: serious-and-unexpected is the candidate test, and anything else routes the routine way.
- What escalates to a humanAnything serious, anything unexpected, anything ambiguous, and anything the system cannot parse cleanly is held for a named human. The two acts that carry regulatory weight, the binding seriousness determination that starts the 15-day clock and the E2B(R3) submission, are high-risk skills the engine will not run until a different, authenticated reviewer signs at the gate.
- The line is yoursWhere the boundary sits is configured by you, not by us. You set which conditions may proceed unattended and which must hold for a person. The agent only PROPOSES which cases look expedited; proposing carries no regulatory weight, so the binding call is always a human at the gate. You move the line; the code enforces wherever you put it.
- Never on doubtA case is never auto-closed on doubt. The triage is advisory until a human confirms it, the engine structurally forces a separation-enforcing gate before any irreversible act, and an unparsable or borderline case fails toward the human, never away. The cheap mistake (escalating something routine) is the one the system is built to make; the expensive mistake (closing something it should not) it is built to refuse.
CSV and GAMP 5
Built to slot into your validation, not to replace it.
We never say validated, compliant, or certified for you. We say this: MakerChecker is designed for your computer-system validation process, and it gives your validation team the two things that make that work cheaper, a deterministic and version-pinned control set that does not drift between runs, and requirements-traceable evidence the running system produces.
You categorize honestly under GAMP 5. You validate your own system. The control set, the gate logic, and the triage rule are open source, so your quality unit reads exactly what they are pinning a test to. Your validation stays yours.
- GAMP 5 categoryWe do not tell you your category; that is your assessment. What we give your assessment is a deterministic, version-pinned control set: grants are deny-by-default, each agent role runs at one pinned skill version, and the gate logic is the same code every run. A control set that does not drift is a control set your validation can actually pin a test to.
- Requirements traceabilityThe controls map clause by clause to the rules your inspectors enforce (see the control-to-clause crosswalk on the security page). That gives your validation team a readable line from a requirement they have to satisfy to a control they can read in the open-source code and a piece of signed evidence the running system produces.
- Read the sourceIt is open source and self-hosted, so your CSV team reads the gate and the triage rule themselves before a single case moves, and reverifies the chain with us nowhere in the loop. The thing that decides what the agent may do unattended is the most readable thing you run, not a vendor black box you have to take on faith.
- Your validation stays yoursWe are designed for your computer-system-validation process and we produce evidence for it. We do not perform it, and we do not claim your system is validated, compliant, or certified because you run us. The validation, the assessment, and the sign-off remain your quality unit’s, on your infrastructure, under your procedures.
Fail closed
When something is down, the action does not run.
A CSV reviewer does not ask what happens on a good day. They ask what happens when the gate is unreachable or the database is down. The answer is the same in every case: deny by default. The irreversible act waits; it never proceeds on the absence of an answer.
- Gate unreachableIf the approval gate cannot be reached, the gated action does not run. There is no timeout that lapses into approval and no fallback path that proceeds without the signature. The run parks; the irreversible act waits for the human.
- Database outageBecause the state change and its audit event commit in one transaction, a store that cannot accept the audit write cannot accept the action either. If the trail cannot be written, the action does not happen. There is no unlogged path.
- Unauthenticated decisionA decision from an unauthenticated or unauthorized identity is refused, not queued and not assumed. Deny-by-default grants mean an agent role can only do what it was explicitly granted; absence of a grant is a denial, never a permission.
- Unparsable inputA case the system cannot read cleanly is not closed on a best guess. It fails toward the human review path, where a named person owns the call. Doubt routes up, never out.
Sign-off identity
The signature binds to the record, and to the person who gave it.
A signature an inspector cannot attribute is not a signature. When a named, authenticated reviewer signs at a gate, their identity is captured and bound into the signed audit event itself, alongside the date and time, the meaning of the approval, and the verbatim reason they typed.
- Bound in the eventThe reviewer’s identity is not a label stored beside the record; it is part of the signed, hash-chained event. You cannot change who signed without breaking the chain, so the attribution an inspector reads is attributable by construction.
- A different personThe identity is checked against segregation of duties at the moment of signing. The processor who triaged the case is refused if they try to sign it off, so the signed record shows two distinct, named people, which is the independence an outside inspector looks for.
- Authenticated, not assumedAn unauthenticated decision is refused outright. You bring your own authentication to the deployment; the engine captures the authenticated identity and binds it into the evidence. We do not ship SSO or SAML, and we do not claim to; how your people authenticate is your environment’s to decide.
Keep reading
See it for yourself
Bring it to your validation lead. Read every line.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.