A fleet completion ledger treats done as an evidence-backed state transition, not a message from an agent, and keeps the assignment, output, checks, review, and merge target connected through one stable identifier.
Give each assignment one durable identity
Create an assignment ID before an agent begins. Attach the requested outcome, allowed files or systems, dependencies, acceptance checks, merge target, and person with review authority. Every later run, branch, worktree, artifact, test result, and review should carry that ID. Agent names and chat threads are weak identifiers because they can change while the underlying assignment stays the same.
Use explicit states such as queued, blocked, active, submitted, checks failed, under review, changes requested, accepted, merged, stopped, and superseded. A state transition needs a time, actor, reason, and evidence reference. Submitted means an output exists. Accepted means the designated reviewer approved the stated criteria. Merged means the target contains the accepted revision. Those events should never collapse into one done flag.
Connect claims to inspectable evidence
An agent may report that tests pass while the recorded command ran on an earlier revision, a different worktree, or only part of the suite. Store the exact revision, command, environment, exit result, artifact location, and timestamp. When the evidence cannot be joined to the submitted output, the ledger should mark the check unresolved rather than inherit the agent's confidence.
Dependencies need the same treatment. A task blocked on another assignment should name the required artifact and accepted revision. When upstream work changes, downstream entries can become stale even if their own branch did not move. The ledger should expose that stale dependency and return the task to review instead of presenting an old passing result as current completion evidence.
End with a permitted disposition
The ledger should produce a short disposition for every assignment: merge candidate, changes required, retry permitted, held for conflict, stopped by rule, or superseded. Each disposition names the evidence and unresolved risks. GitHub's required-check documentation shows why the latest commit matters to merge controls; an accepted test on an older SHA does not satisfy the current change.
Fleet Completion Control is operated by Reality Contact, LLC. The buyer defines completion, review, and merge authority and retains all repository credentials. The ledger records the accepted rules and supplied evidence for the named assignments. It does not decide whether disputed work is correct, merge changes, or represent an agent status as proof when the underlying artifact cannot be inspected.
Where the service stops
Reality Contact, LLC installs bounded completion and evaluation controls but does not manage the buyer's staff, declare disputed work correct, merge or deploy changes, delete worktrees, reassign tasks, or operate the fleet indefinitely. The buyer defines completion and review authority, approves rubrics and stopping rules, resolves disputed judgments, controls repositories and credentials, and authorizes every merge and deployment. This is technical implementation, not legal advice. Automated evaluation supports named criteria; final technical, security, legal, and production decisions remain with the buyer. We do not promise conflict-free parallel work, correct grader judgments, successful merges, or coverage beyond the accepted sources, criteria, and scenarios.
Sources: GitHub guidance for required status checks; Git documentation for multiple working trees.