When the revision changes, the approval expires
An approval is evidence about a particular proposal. When that proposal changes, the approval needs another review.
An automated workflow may separate approval from execution. In that interval, the revision, captured state, or action itself can change. A record saying "approved" is incomplete unless it names the proposal it approved.
Bind approval to the proposal
I added a small helper to Stopline that compares three opaque identifiers:
type RevisionProposal = {
actionId: string;
revision: string;
stateHash: string;
};
type RevisionApproval = RevisionProposal & {
approvedBy: string;
};
The helper accepts an approval only when the action identifier, proposed revision, and captured state identifier match. If commit-a becomes commit-b, it returns a rejection that names the mismatch.
The useful behaviour is the refusal. The helper does not carry an earlier approval into a changed proposal.
What the tests establish
The release has four tests for the helper: a matching approval is accepted; a changed revision is rejected; a changed captured state is rejected; and a different action is rejected. The full Stopline test suite passes 11 tests.
That is a bounded implementation result. It shows an executable boundary and visible failure cases. It does not prove that a repository's merge controls are safe. The helper does not calculate a commit hash, authenticate an approver, decide who may approve, or block every possible bypass path.
Why state is part of the decision
A revision can remain unchanged while the state it relied on becomes stale. A browser page, an inventory record, or a delivery workflow can move while an action waits for review.
The example carries stateHash with the revision for that reason. The system still has to define the state representation, identity, permissions, expiry, audit record, and rejection path. A small check cannot supply those controls. It can require the workflow to stop when the recorded evidence no longer applies.
The Stopline v0.1.1 release includes the helper, tests, browser-agent policy, and documented limits. The next design question is whether the workflow can prove that an approval still applies when an action reaches execution.