A merged pull request tells you that a candidate entered the shared branch. Independent verification asks a further question: does that integrated result meet the work request?
In Assay, a worker implements a brief, a reviewer examines the candidate, and a human ordinarily merges it. A non-implementer then runs the brief’s acceptance checks on merged main and records the results. Those observations also determine whether later work can use the result.
Carry the requirement into a check
A brief is a bounded work request within a stream of related work. Its deliverables state the required result; its Verify rows supply checks, inputs and expected outcomes.
Desk tools brief 24 changes audit-history reads and daily rotation. One consumer is deskpost, which posts reviews after checking authority and safeguards. Its history must continue to enforce write limits and remember previous posts.
Take the breaker rule: five consecutive in-scope refusals pause retries until 15 minutes after the latest refusal. In this example, the newest is one minute old and four older refusals span several days. The pause is active; after it expires, the breaker permits a fresh attempt. Progress resets the run. A reader that stops at the one-hour budget boundary can miss older refusals and return the wrong permission decision.
One Verify row runs this check:
cd tools/desk
go test ./internal/deskkit/ -run '^TestBoundedPointsForMatchesFullParseVerdicts$' -count=1
The fixture supplies the old-refusal run, reset events and ignored results. It asks the full and bounded readers whether the same write is permitted. The full reader is the existing behavior reference; the comparison checks that the optimization preserves it across policy tiers. The policy supplies the expected answer: the five-refusal run requires refusal, and qualifying progress resets that run. Review must challenge those reference decisions too. Shortening the read to the time window must break that comparison.
The independent verifier executes that contract against the merged revision. It records the check, revision, runner, result and output reference. It is re-establishing behavior after integration, rather than accepting the worker’s earlier account.
Separate implementation, verification and closure
The lifecycle gives the claims separate states:
Verification checks the integrated result against the brief.
This brief uses a model acceptance gate: independent model review supplies the acceptance judgment because all four risk answers are no. Its decision-equivalence, fallback and rotation checks bound the identified hazards. A human still owned merge. For a human-gated brief, the verifier can record passing checks while the required acceptance decision remains with its human owner.
The distinction also separates delivery from release. This brief’s verified code provides an input to packaging and adoption; the work request determines which of those later acts, if any, belong to its own completion.
Apply the rule for unavailable checks
The 17 September verification record contains thirteen executable passes, including decision equivalence, rotation, recovery and ten caught fault mutations. Muhar is the tool that plants those specified faults and checks whether the tests detect them.
The fourteenth row examined a different obligation: did the implementation diff touch the files declared as changed and leave the declared exclusions alone? This scope check needs a branch comparison; on fully merged main that input may be absent. The brief therefore made that mode conditional, with a predeclared could-not-check outcome. The separately required ledger-behavior checks still had to pass.
That expected condition occurred. The verifier then supplied a comparison revision and found a parser defect in the checking tool: backticks around declared paths made real files appear absent. Direct inspection of the diff corroborated the declared changes, and the verifier filed the checker defect.
The overall recorded pass followed the brief’s stated rule for that row. It did not turn the unavailable tool result into a passing execution. The executable checks passed, and the conditional routing row retained the outcome the brief had allowed, alongside the additional inspection.
Change the situation: if the required rotation check cannot establish that prior posts survive, its obligation remains unanswered. The verifier records the unavailable result and routes the missing fixture or access to its owner. If the check runs and loses a prior post, the implementation needs repair. A broken checker and a demonstrated product defect require different responses.
Keep evidence tied to the requirement
An execution receipt can identify the revision, verification row, runner and output. The assertion determines what that execution checked.
For the ledger comparison, the useful observation is that both readers permit or refuse the same write. An otherwise accurate receipt of a row-count comparison would not establish that behavior. Trace both links: execution to observation, and observation to requirement.
The verifier is a non-implementer so it supplies a fresh execution of the delivered result. It still needs a meaningful contract and adequate tests. If it finds a weak assertion, it records that gap and sends the check back to its owner.
Use evidence to decide readiness
Now consider a follow-up brief adding a report command that uses the ledger’s daily segments. Its ordinary build dependency on the ledger change says what the worker needs: the segment-reading behavior established by the upstream checks.
While the ledger change is merged but unverified, that prerequisite is still waiting. Once it reaches verified or done, the ordinary dependency is satisfied and implementation of the report can begin. The verification record has changed an actionable scheduling decision.
A release can impose a stricter acceptance gate. If publishing the package requires an owner’s sign-off, implementation readiness does not supply that sign-off. The relationship must name which evidence it consumes.
The eligibility rules also allow ordinary implementation to use a human-gated prerequisite with a recorded passing verification run while final sign-off is pending. A stricter gate retains its own condition. This lets work on a checked interface proceed while preserving the owner’s separate decision.
The engineering practice is portable: specify acceptance before implementation, assign its post-integration execution to another party, and make each downstream dependency consume the evidence it actually needs. Completion then changes what the delivery system can do next.