assay · methodology · the map as it stands today
What Assay covers, and what you bring
Assay does not certify that agent output is correct. It certifies who verified it, how, and when, and makes it visible if anyone quietly edits that record. This page is the other half of that statement: which parts of getting software built Assay actually covers, and which parts you are still bringing yourself.
The map
Eleven phases. Three shaded covered, seven partial, one yours. A phase is covered when Assay supplies the mechanism and this page names it; partial when Assay supplies part and you supply the rest, and the paragraph says which is which; yours when Assay supplies nothing and you bring it whole. A phase is not shaded covered while the work that would cover it is still queued.
| # | Phase | Shading |
|---|---|---|
| 1 | Requirements and intake | partial |
| 2 | Planning | partial |
| 3 | Design and architecture | partial |
| 4 | Build | covered |
| 5 | Test | partial |
| 6 | Review and security | covered |
| 7 | Verification | covered |
| 8 | Release | partial |
| 9 | Deploy and operate | yours |
| 10 | Incident and feedback | partial |
| 11 | Compliance evidence | partial |
Phase by phase
-
Requirements and intake partial
Assay gives you a front door with five recorded dispositions, so a request that arrives becomes a work order (we call them briefs), a bug, a finding, a decision for a person, or a recorded refusal, and never becomes nothing. What it does not yet give you is a requirement as an object of its own: there is no artifact you can point a check at to ask "what was this work supposed to satisfy", and no line running from an acceptance criterion through to the check that proves it. You bring your own requirements tracking, and the trace between the two is manual.
-
Planning partial
Assay plans in dependency waves: work orders carry what they depend on and what they unblock, a critical path falls out of that, and the risk questions and the human gate are answered when the work is written rather than argued about later. What it does not have is a roadmap or a capacity surface. It will tell you what is next and why; it will not tell you when, or whether the people and agents exist to do it. You bring the roadmap.
-
Design and architecture partial
Decisions that need a person are recorded where the work is: a gate that blocks, a written record of what was asked, and a ruling that is attributable and dated. What is missing is the artifact between the decision and the code. There is no design record with its own state, no threat-modelling step that triggers on a risky change, and no validation activity distinct from verification. Today a design decision looks like a well-argued issue thread, which is better than nothing and less than a control.
-
Build covered
This is the phase Assay was built for. Work is dispatched one item at a time into an isolated workspace, under a distinct machine identity, behind a draft pull request, with a claim that stops two agents colliding on the same item. The author identity and the reviewing identity are different accounts, and that separation is enforced by the code host rather than by convention. You still bring two things: the agent harness the work runs under, and your own continuous-integration system. Assay sits under whatever harness and whichever CI you already have; it does not replace either, and it is proven against a named subset of harnesses rather than all of them.
-
Test partial
Every work order carries a table of checks with a command and an expected exit code, so "done" has to survive something a machine can run, and a check that pins a guard has to be shown failing before it is trusted. What does not exist yet is a policy above any one work order: no coverage floor, no tier structure, no defined class for a flaky test, no standing suite that is always true. You bring your test strategy. Assay makes sure each piece of work states its own, and that the statement is executable.
-
Review and security covered
Review is a gate, not a courtesy: a distinct identity posts the verdict, the author cannot post it, and a change on a risky path pulls in a security review by rule rather than by memory. Registers are append-only and a deleted row turns the build red, which is what makes tampering visible instead of quiet. What you bring here is your scanning stack. Static analysis and dependency scanning are yours, and Assay has no opinion about which you use.
-
Verification covered
Merging is not completing. Someone who did not implement the work runs its checks again on the merged result, fills in the evidence, and only then does the item advance. The evidence rows carry who ran them and when. Where a check could not be run, it is recorded as not run, never rounded up to a pass; a result nobody obtained is a third state, and Assay keeps it as one. What is still yours: a second runner for the checks a first runner could not perform, which today is arranged by a person rather than by the system.
-
Release partial
Releases are pinned and checkable: an artifact is identified by its hash, the record of what changed is a gate rather than a habit, and a set of preconditions has to hold before a release is cut. What is not a product surface yet is the policy around it: no release-train cadence you can adopt, and no rehearsed way back from a bad release. You bring your release policy and your rollback.
-
Deploy and operate yours
Assay does not deploy anything and has no view of a running system. There is no environment model, no gate at the deployment boundary, no runbook format, and nothing that watches production and turns what it sees into work. Everything from the release artifact onward is yours. This is the largest single thing this page is telling you.
-
Incident and feedback partial
When something goes wrong, Assay has somewhere to put it: a findings register that is append-only, the rule that a red build is a discovery rather than an interruption, and retrospective entries that outlive the session that wrote them. What it lacks is the loop's closing half: an incident as a typed object, a post-mortem that has to be closed by a person before the item can be, and an automatic path from what was learned back into the front door. Today that path is walked by hand, which means sometimes it is not walked.
-
Compliance evidence partial
The raw material an auditor asks for is already produced as a by-product: separated identities, dated and attributed approvals, append-only records, and gates a person must pass. What does not exist yet is the pack: one export, keyed to a release, rooted at what the work was supposed to satisfy, that hands over the chain in a form somebody outside the system can read. Today an auditor gets a repository and a guide to reading it, which is more than most and less than an export.
The map is dated
Three phases covered out of eleven is the map as it stands today, and the map is dated. A phase moves out of partial when the work that covers it has shipped and has evidence behind it, and not before, including on this page.