Trust gates

An agent saying "done" isn't done. Before any change your agents make is eligible to merge, it has to clear two independent gates. Anything that doesn't is quarantined for a human — not shipped.

The two layers

1. Your tests. The change runs your test suite. This catches what's specified.
2. An independent reviewer. A separate agent that didn't write the code reviews the change, prompted to find defects rather than rubber-stamp it. This catches what isn't specified — the plausible-but-wrong changes that read fine and still break.

A change is only cleared for merge if both pass.

Quarantine, by default

When a change fails either gate, the acceptance gate routes it to a human: it's held out of the merge path and surfaced on the run's page to approve or discard. The default is never to ship. Nothing is merged automatically on a failure, and nothing is silently dropped — the failure and its reason are recorded.

Because each change is gated independently, you can put a fleet of agents on the backlog and review the queue of results that already passed, instead of supervising every session live.

The run log

Every step of every run — build, tests, review, and the final decision — is written to a tamper-evident, hash-chained log. Each entry is chained to the one before it, so the record can't be quietly altered after the fact. You get an auditable reason behind every merge or quarantine, on the run's page at partyline.sh/runs.

Where this fits

Trust gates run inside every run, whether you started it with ptln work, ptln crank, or a dispatch from the board. What happens to a passing change — a branch, a PR, or an auto-merge — is set by the run's merge policy; the gates decide whether it gets that far at all.

Next: Runs & the board · The software factory · Security.