Imagine asking a coding agent to restrict customer exports to workspace admins. It returns a patch and says the job is done. The export button has disappeared for everyone else. But can a non-admin still send a request directly to the server and download the data?
Now move forward a month. Another agent adds a new export format through a different endpoint. The first change passed its checks. Who tells the new agent that the admin-only rule still applies?
These questions connect security, engineering quality and compliance. A team needs evidence of what it delivered, and a way to bring the decisions behind that delivery into later work. Giving an agent last month’s successful test result answers only part of the problem.
Human decisions should become inputs to the next change. Build a delivery record that can preserve intent as well as explain the past.
a release is finished; a constraint can continue
The export restriction expresses a continuing choice about access to customer data. A brief to implement it can be completed. That does not end the restriction. A new format, background job or API route must still respect the owner’s rule unless someone with the authority changes it.
That distinction is easy to lose when the project’s memory is a completed ticket or a long conversation. “Done” describes a unit of work. The team also needs to know which decisions remain relevant, why they were made and what would justify revisiting them.
This matters even without a SOC 2 programme. A future maintainer needs the same context to avoid a regression, explain an incident or challenge an old assumption. An auditor is one possible reader of these records; the next engineer is another.
make the human choice inspectable
Start by separating a human choice from the implementation that follows it. Record who decided that exports must be admin-only, the reason, the alternatives considered and the consequences accepted. Link to the original ruling. Then give the requirement a testable form: an admin can export; a non-admin is denied, including through a direct request.
The reviewer can now challenge a concrete boundary. After the change lands, someone other than its implementer checks the allowed and denied cases on that revision. Keep the command and output, including any check that could not run. A fingerprint identifies retained output; it cannot recover output that was discarded.
NIST’s Secure Software Development Framework places secure practices within the development lifecycle. The practical opportunity is to keep the decision, challenge and check connected while the work is happening.
Separate identities make responsibility visible. They still need appropriate permissions and thoughtful review. Two agents can share a blind spot; another approving sentence cannot substitute for testing the unprotected endpoint.
organise the records so someone can use them
Think of the linked collection as an evidence cabinet: a filing cabinet whose drawers answer useful questions about a change. It can be ordinary files, issues and reviews in a repository and code host. The useful property is that a reader can follow a claim to its source.
Intentwhat must remain true?
The owner’s admin-only rule and its allowed/denied cases. State whether the requirement is a continuing constraint or a one-off delivery request.
Decisionwho chose it, and why?
The dated human ruling, authority, alternatives and accepted consequences. A later replacement preserves the original choice and explains why it changed.
Challengewhat could defeat the rule?
A separate review tests the reasoning: hiding a button still leaves a direct server request to investigate. A recorded identity establishes attribution, not review quality.
Checkwhich code and result?
The tested revision, command and retained output. Missing checks remain visible. An earlier result keeps its historical scope.
Releasewhat does this snapshot cover?
The declared delivery scope and the records collected for it. A manifest helps inspect the contents; it does not establish that every relevant decision was recorded.
Later workwhat must it carry forward?
The applicable decision and requirement, linked into the new work order with fresh checks. Conflicts and missing sources need a disposition before someone treats the answer as authoritative.
This cabinet has two uses: reconstructing a past delivery and preparing the next one. Collecting a release snapshot helps with the first. The second also needs retrieval, a judgment about applicability and a check that the new work actually preserves the constraint.
bring the rule into the next change
For the new export format, preparation should begin with the standing admin-only decision. Include it in the new work order, require the direct non-admin request to be denied, and review the new route. Verify the new revision; last month’s passing result remains evidence about last month’s code.
Human choice: why admin-only?
Requirement: allow admin; deny non-admin.
Source: the owner’s recorded ruling.
New export format → new work order.
Carry the applicable constraint.
Review and check the new code.
A useful question for either a human or an agent is: “What decisions and requirements apply to exports?” A useful answer cites the sources, distinguishes current and replaced choices, and exposes conflicts or missing information. A search that finds one relevant document should also disclose what it searched; it cannot establish that nothing else applies.
Retrieval alone is insufficient. Someone must put the relevant constraints into the work, preserve them during implementation and test them afterwards. When a ruling changes mid-task, the affected assumptions need reconsideration. When the owner authorises an exception, keep its scope and reasons alongside the original decision.
delivery logs can help, with their limits intact
The records used to understand delivery performance can also help reconstruct a security-sensitive change. State transitions locate when work moved. Action records identify an attempted or refused operation. Verification output shows what a check observed. Keep their source, revision and coverage visible.
An aggregate chart can direct attention; an investigation needs retained events and reliable links to the affected change. Application access events answer who exported data in production. Development logs and test results have their own coverage. Correlating them requires access controls, retention decisions and care about what each source can establish.
a worked example in assay
Assay provides one repository-based implementation of these ideas. Its decision register records human design choices and source rulings. Its requirement register holds behaviour and acceptance criteria. A later brief can cite them through design: and satisfies:, alongside review and fresh verification. Recording and linking remain deliberate team actions.
Its current limits illustrate the wider problem. Requirement references are optional and missing-citation warnings in opted-in streams are advisory. The tool does not automatically discover every obligation for an export edit or capture every human conversation. We have requested source-based decision recall and inherited obligations to help humans and agents prepare later work. That automation is proposed.
Assay’s release exporter collects declared requirements, work orders and linked evidence. The actual public fixture below shows unfinished work and a missing link. It is separate from the illustrative export change and includes no fabricated passing test or approval.
| 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?
The archive contains report and manifest JSON, the fixture release note, a stream index and brief, and two requirement records. Read exact paths in the manifest.
Reproduce this export. All inputs come from the existing public fixture. No private logs are included.
Its log guide distinguishes existing delivery history, guarded-tool actions, verification output and retained harness traces from production access events. Automatic log joins are proposed. Source-applicability and corrective-action records are planned; the capability breakdown keeps these separate from available tooling.
start with a consequential rule
The idea does not depend on adopting Assay. Protected branches, code owners and CI may provide enough separation for a small team. Pick a change involving permissions, data loss or recovery. Record the owner’s choice, the allowed and denied cases, a separate challenge and the result. Before the next related change, retrieve that choice and make its continuing constraints explicit.
Delivery artifacts do not confer ISO certification or a SOC 2 report. An organisation still owns its policies, access administration and oversight; SOC examinations assess organisational controls. The everyday engineering benefit is more immediate: the team can inspect why a boundary exists and preserve it deliberately as the software changes.