assay · controls for AI-agent software delivery
The agent that writes the code never gets to say it works.
assay puts segregation of duties under AI-agent software work. Every change an agent makes is verified by an executable check, run by a party that did not implement it, and the record of that verification is append-only and tamper-visible. That one sentence holds up in a board meeting, a controls walkthrough, and a code review.
| Control objective | Mechanism | Status |
|---|---|---|
| Segregation of duties | The implementing agent never verifies its own work. A distinct verifier session executes the checks; the roles cannot be held by the same actor. | OPERATING |
| Executable verification | Every unit of work carries a Verify table — commands, not opinions. A PASS is a program’s exit code with a named runner and a date. | OPERATING |
| Evidence retention | Verification lands in append-only registers. Deleting or rewriting a record turns a required CI check red — see Exhibit C. | OPERATING |
Data residency
Runs where your code runs
The toolkit is files and CI jobs in your own repos; the on-prem console deploys in your cluster. Nothing about your codebase needs to leave your boundary.
Model risk
Vendor-neutral by protocol
assay speaks ACP and treats the model as a replaceable counterparty. Swap vendors without rewriting the control — your model-risk committee keeps its options open.
Change management
Additive, and reversible
It extends the SOX, change-control, and CI regime you already run — no migration, no new platform of record. Exit is deleting a CI job and keeping your evidence.
Exhibit B
A control an audit-trained reader can test
Your existing control environment assumes work that is human-paced and human-authored: a preparer you can name, a reviewer who is somebody else, evidence that accumulates and is retained. Agent fleets break every one of those assumptions at once — not because the work is bad, but because nothing in the regime was built to attest to it. assay restores the assumptions rather than asking you to waive them.
| Your vocabulary | What assay makes true of agent work |
|---|---|
| Preparer / reviewer | The implementing agent is the preparer. Verification runs in a separate verifier session that cannot be the author — the split is structural, not procedural. |
| Change control | Agent work travels as scoped briefs behind pull requests. Humans merge; nothing an agent produced lands without passing through your existing gate. |
| Independent testing | Each brief’s Verify table is executable. A PASS is a recorded program run — reproducible on demand — not a recollection or a checkbox. |
| Evidence retention | Every verification lands as a dated, runner-attributed row in an append-only register. The register file is the evidence bundle; removal is a detected event. |
“Every change the agents made was verified by a party that did not make it. The verification is a program, not an opinion, and it can be re-run. And if anyone had touched the record of it, this report would be red instead of green.”
The P&L translation
The operating thesis behind agent-heavy delivery is a function of ten to twenty engineers run as two or three directing verified agent capacity. assay’s contribution is not the headcount curve — it is making that operating model defensible enough that you are permitted to run it in a controlled environment. Treat 10–20 → 2–3 as a design target you test in a bounded pilot, with the evidence to show your auditors either way. It is not a promise, and this page will not pretend it is one.
If you are taking this story to market
A services business remade around AI delivery will be asked — by acquirers, by courts, by regulators — how it knows the machine-made work was controlled. An answer that names a control model, shows executed evidence, and depends on no single model vendor survives diligence. An answer that amounts to “we reviewed it carefully” does not. assay is built to be the first kind of answer.
Exhibit C
The control, exercised: a deleted record turns CI red
A control that has never fired is a diagram. This one has fired. Below: a single row — one verification record — is removed from an append-only register in an otherwise plausible commit. The register lint, running as a required check, compares the register against its baseline and fails the build. The deletion is not prevented; it is caught, attributed, and made loud — which is what a detective control is.
--- a/docs/streams/settlement/REGISTER.md +++ b/docs/streams/settlement/REGISTER.md @@ -47,7 +47,6 @@ | 2026-07-31 | R-039 | reconcile batch dry-run, parity vs. ledger | PASS | verifier-2 | -| 2026-08-02 | R-041 | export checksum matches signed manifest | PASS | verifier-1 | | 2026-08-04 | R-042 | settlement replay, zero unexplained deltas | PASS | verifier-3 |
$ assay lint --registers register docs/streams/settlement/REGISTER.md baseline 4f21c9a → head 88d0e3f R-039 2026-07-31 verifier-2 present R-041 2026-08-02 verifier-1 MISSING at head R-042 2026-08-04 verifier-3 present append-only violation: 1 verification record removed FAIL — required check "register-lint" exited 1; merge blocked
Read as an engineer
A real mechanism, inspectable
The register is a flat file in your repo. The lint diffs it against the merge-base, treats any removed or altered row as a violation, and runs as a required status check on a protected branch. No service, no sidecar database — you can read every line of what fired here.
Read as an auditor
Evidence retention with a detective control
This is the same artifact, filed: retained evidence, an attempted alteration, and a control that detected it on occurrence and blocked the change. Preparer and reviewer are named on every surviving row. This exhibit goes in the walkthrough as-is.
Stated plainly: this is tamper-visible, not tamper-proof. Detection lives in a required check on a protected branch; weaken those and you have weakened the control — exactly as an auditor would say of any register you keep today.
Exhibit D
What assay is, mechanically
Four parts, all plain text, all in your repository, all operating through the CI you already trust. There is deliberately nothing else.
D-1
Briefs
The unit of agent work: a scoped task with a definition of done and an executable Verify table, authored before the work starts. Agents implement against a contract, not a vibe.
D-2
Verifier sessions
A separate, non-implementing session executes the Verify table row by row and records PASS or FAIL with runner and date. The author is structurally excluded from this role.
D-3
Registers
Append-only files that accumulate every verification record. The register is the evidence bundle — human-readable, diffable, and handed to an examiner without transformation.
D-4
The gate
One CI job that lints briefs and registers: red on drift, deletion, or claims without an executed check behind them. Adding assay is adding this job; leaving is deleting it.
Exhibit E
What assay does not claim
Every reader this page is written for has been burned by a tool that claimed too much. The limits are part of the product.
- Not a claim that agents write correct code. Verification exists precisely because they sometimes don’t.
- Not a replacement for your SDLC, QA, security review, or your auditors. It is a control layer inside the regime you already run.
- Not a certification, a seal, or a regulatory safe harbor. It produces evidence; your assessors weigh it.
- Not tamper-proof. Tamper-visible, contingent on your branch protection and required checks staying enforced.
- Not a guarantee of 10–20 → 2–3. That is an operating target to test in a pilot, with evidence either way.
- Paid tiers are design-stage. The open core is what exists and ships today; the rest is stated intent, priced accordingly at zero.
Schedule F
Open core, and what sits above it
The free tier is not a teaser — it is the pilot. Run it on one repository for one sprint and you will hold a register an examiner can read.
Free · open source · shipping now
Core
The toolkit + Desk Solo
- Briefs, verifier sessions, registers, and the CI gate — the full control model of Exhibit A
- Desk Solo: one operator directing agent work under segregation of duties
- Output of the pilot is an evidence bundle, not a slide — hand it to your auditor
- Plain files in your repo; nothing leaves your boundary
Premium · design stage
Fleet
For the controller’s office and the platform team
- Multiple desks with review and verification separated at organizational scale
- Cross-repo register reporting: one attestation view over every fleet
- Control-status summaries written for audit committees, not dashboards
On-prem · design stage
Console
For regulated boundaries
- The console deployed in your cluster — data residency by construction
- SSO, retention-policy alignment, examiner-export of registers
- ACP model-neutrality throughout: no vendor becomes load-bearing
The close
Run the pilot. Hand the bundle to your auditor.
One repository, one sprint, the free tier. At the end you hold Exhibit C for your own codebase: named verification of agent work, retained in a register that would have told you if anyone touched it. That is the shortest path from “agents are moving faster than our controls” to a sentence you can say to a board, a CFO, or an examiner.