A change you can explain.
An evidence trail you can inspect.
Assay runs agent-operated delivery with human governance. Follow one change to see who checked it, what they recorded and where a person decided it could proceed.
Open the evidence cabinet Read the article
- Requirement Define the boundary
- Brief Make it testable
- Review Separate identities
- Human merge Keep authority
- Verify on main Keep the result
- Release pack Inspect the chain
Compliance & assurance
An evidence cabinet is a linked collection of records about a change: what was requested, who reviewed it, what was checked, who allowed it to proceed and which release includes it. Think of these drawers as questions you can answer by opening the underlying records in your repository and code host.
Follow one illustrative admin-only export change below. The drawers are a teaching view of the records Assay can help connect, not a captured production run or a literal file list for the exported pack.
Intent requirement → brief
Only workspace admins may export customer data. Acceptance checks include an allowed admin and a denied non-admin. The owner decides the risk gate before implementation.
Review author ≠ reviewer
A distinct review identity judges the change. The adopter must configure permissions so the author cannot post as that reviewer. A different identity alone does not prove a thorough review.
Verification revision · command · output
The verification runner records the tree revision, executed command and output hash. A party that did not implement the work checks the acceptance criteria. Unavailable checks remain could-not-check.
Authority human decision
A human design choice is recorded in the repository’s decision register, with reasons and a source ruling link. Merge approval is a separate code-host record. Requirements have their own register. Later briefs can cite these records; recording and linking them are deliberate team actions.
Release scope tag → declared scope
The release note declares the briefs and requirements in scope. The exporter follows those links. A release note without machine-readable scope is an empty declared scope, not a full audit trail.
Completeness report · manifest · omissions
Inspect the requirement verdicts and the manifest’s omissions. The exporter checks its backing-link counts against a separate requirements rollup and refuses to write if those counts disagree.
Inspect the mechanisms: evidence exports · lifecycle and verification
Ask for the chain behind a release
The release-keyed audit pack follows declared requirements into the briefs, Evidence and recorded review verdicts behind them. A separate rollup comparison checks backing-link completeness.
Unresolved links stay visible as partial or could-not-check. A pack collects records; it does not independently prove their truth or the adequacy of the tests.
statusgen --root . --export-audit-pack \
--release <tag> -o audit-pack.tgz
Use a statusgen release that includes this flag. Declare release scope in docs/release-notes/<tag>.md; inspect audit-pack-report.json, manifest.json and the exit status.
Inspect an actual export
This is real exporter output against Assay’s public fixture, separate from the illustrative admin-only change above. The fixture deliberately has unfinished work and a missing link. It records no executed acceptance test, approval or real release.
| Requirement | Verdict | What to inspect |
|---|---|---|
REQ-apfixture-ok | partial | Backing brief exists; its status is todo. |
REQ-apfixture-unresolved | could-not-check | Declared backing brief does not exist. |
Export completed with exit 0. Neither requirement is satisfied. Read the verdicts and omissions as well as the exit status.
What is in the archive?
audit-pack-report.json
manifest.json
docs/release-notes/v0.0.0-fixture.md
docs/streams/audit-pack-example/README.md
docs/streams/audit-pack-example/brief-01-fixture-example.md
docs/streams/requirements/apfixture-ok.md
docs/streams/requirements/apfixture-unresolved.mdReproduce this export. All inputs come from the existing public fixture. No private logs are included.
Hashes let you compare files against a trusted reference. They are not signatures or proof that a control operated effectively.
The same records can answer a security question
A delivery delay can prompt an investigation. The underlying records can help explain it. Keep the metric, the event and the decision connected to the same change.
Delivery history
Performance use: stage dwell, backlog and rework.
Assurance use: reconstruct observed work-state transitions and identify waits worth investigating.
A transition timestamp is when the recorder observed a state; it is not an exact action time or evidence of approval. Read the history contract and the dated performance snapshot.
Guarded action records
Operations use: diagnose refusals, retries and tool outcomes.
Assurance use: inspect the recorded tool, action, repository, PR/head reference where present, time and result; corroborate authority with the forge’s actual actor and review records.
The local audit schema covers instrumented desk-tool paths. It cannot show every bypass or establish actor identity independently.
Verification witnesses
Delivery use: explain a failed check and decide what to rerun.
Assurance use: inspect the command, revision, exit result and output hash for the admin allow/non-admin deny acceptance checks.
A hash is useful only with retained output or a trusted comparison. Witnesses are reviewer evidence, not unforgeable attestations. Read the witness limits.
Agent session receipts
Performance use: input/cache consumption and session-span analysis, as in the existing harness-performance methods.
Assurance use: a permissioned reviewer can inspect retained source traces for the context and tool results a session saw, where those fields are present.
The published analysis is aggregate-only. Join an investigation to a versioned artifact and attempt; reused work keys are insufficient. Raw prompts and tool output can contain sensitive data. Harness-reported model labels do not independently establish the upstream provider.
Application security events
Operational use: investigate customer-export activity.
Assurance use: correlate allowed/denied requests with the deployed revision, actor and request identifier where your application records them.
These are your application’s logs. Assay’s delivery exporter does not collect them, and a delivery test does not prove production access was denied.
What makes a retained log useful as evidence?
Define the question and time window, retain the source records and outputs with controlled access, preserve timestamps and clock uncertainty, and record collector/version, coverage gaps and redactions. Link the change, PR/head and release to the records using stable identifiers where available. Keep originals in permissioned storage; publish a scrubbed teaching copy.
Retention, central collection and access/integrity controls are responsibilities to configure. Append-only local writing and file hashes alone are not immutable custody. An aggregate can flag an unusual pattern; the underlying events and a recorded human evaluation establish what was actually examined. NIST’s log-management guide covers the collection and management practices behind useful logs.
Available now: delivery history, guarded desk-tool audit records and verification witnesses can be inspected alongside a change. The sample pack above contains authored delivery artifacts.
Proposed extension: link permissioned log excerpts and a coverage/retention record into the cabinet, keyed to the change and release. Automatic joins, security-event ingestion and a signed log annex are not shipped by the current release exporter.
Remember the rule on the next change
An export feature changes a month later. Its original implementation may be done; the owner’s admin-only constraint still needs to be preserved.
Available records: the decision register holds dated design choices, reasons and human ruling links; the requirement register holds the requested behaviour and acceptance criteria. A later brief can reference them with design: and satisfies:, then verify the new code. A previous result remains historical evidence.
Current responsibility: the team finds and links applicable records. Requirement references are optional; Assay does not automatically identify every obligation for a changed component or capture every human conversation as a ruling. A release pack is not a complete decision log.
Proposed feature: decision recall and inherited obligations. Let humans and agents ask what applies to exports, inspect the sources and conflicts, and carry the current constraints into later work. Replaced decisions retain their history; missing coverage stays unknown.
What exists. What is planned.
Source snapshot: 6 October 2026. Availability below refers to the public toolchain; it is not an assessment of an adopting organisation.
Available in the public toolchain
- Separate implementation, review and verification roles, with human merge and risk decisions.
- Recorded verification runs with command, revision and output hash.
- Date-range evidence export and release-keyed requirement → brief → evidence/review export.
- Tool-validation release assets, release-authorizer traceability and documented records/retention responsibilities.
These are mechanisms and records. Effective use depends on your configuration and what your checks actually cover.
Planned, not yet delivered
- Corrective-action closure backed by evidence that the control works.
- Versioned source obligations and project applicability decisions.
- Project assurance review packets and reassessment after source changes.
- Independent qualification of that preparation workflow.
- Scoped control profiles and population-aware evidence exports.
No delivery dates are promised here. These items remain work in the public plan.
Plans and evidence: ISO-related artifacts · control profiles
As of the 6 October 2026 source snapshot, the ISO-related stream was parked. Reactivation at P2 was requested in a draft change; these remaining items are still planned.
Where your organisation takes over
Assay supplies delivery controls and evidence. Your organisation defines scope, policy, ownership, risk acceptance, access administration, retention and operational controls; assessors judge whether those controls are sufficient and effective.
Assay does not confer SOC 2 assurance or ISO certification. The published SOC 2 and ISO 9001 mappings are analysis aids, with unverified normative paraphrases. Confirm requirements against the applicable authoritative sources before relying on them.
Assay’s board is derived from authored records with consistency checks. Register tampering is visible only while branch protection and required checks remain enforced. The operating pipeline ends at verification on main; deployment, production operation and rollback remain yours.
Read the ISO mapping and its limits and SOC 2 mapping and export limits.
Useful before the first audit
When a change behaves unexpectedly, the same trail helps you reconstruct what was intended, which revision was checked and what a person approved. Begin with one consequential change and a check worth rerunning.
Follow one change in the article Watch the visual explainer Adopt Assay on one repo