Validating a release decision, not just the release.
CI tells you the build is green. Your approval rules tell you who may merge. Neither answers whether the decision to ship this change, now, was justified by what the team actually knew.
Where the gate would sit
An autonomous or semi-autonomous release flow reaches a point where a change moves from "proposed" to "deployed." That transition is the exit boundary. Before it, a validation call receives the release as a bounded package and returns a native outcome plus objections.
ALLOW, BLOCK or UNCERTAIN, plus structured objections naming what is missing or inconsistent.What this adds
A check that does not share the room's assumptions.
Release decisions are often made inside a single conversation — a channel, a standup, a chain of agents coordinating a rollout. Everyone in that context shares the same framing and the same time pressure. A separately scoped check evaluates the bounded package on its own terms, and does not treat the group's agreement as evidence.
A check on whether required evidence is actually present.
Approval rules verify that a named person clicked approve. They generally do not verify that the thing the mandate required — a passing migration dry-run, an explicit owner sign-off, a rollback plan — was present and attached when that approval happened. Validation can flag a package that is missing what its own mandate demands.
A record tied to the decision, not the ticket.
Where a signed artifact is produced, it references the specific package evaluated and what the verifier returned. That is a different record from a CI log or an audit trail of who clicked what.
Proof gaps — what has not been shown
- No production release deployment. No customer currently runs a ThoughtProof gate in a production release pipeline. Everything on this page is workflow design plus internal testing, not an operating reference.
- No false-block rate for release decisions. We have not measured how often a release gate would stop a change that should have shipped. For a deploy pipeline that number matters more than the block count, and we do not have it.
- Sign-off statements are consumed as supplied evidence. If a mandate requires an owner sign-off and one is attached, the verifier treats it as present. It does not independently verify the sender's key, map an identity to a person, or bind the statement to a specific commit or release hash. Do not read this as a cryptographically verified approval.
- No latency budget validated against CI. Validation is a deliberate step measured in seconds, not milliseconds. Whether that fits inside a given deploy pipeline without becoming the bottleneck has not been tested at customer scale.
- Mandate authoring is unsolved for releases. Writing a machine-checkable statement of "what justified means" for a deploy is harder than for a trade, where risk limits are already numeric. We do not yet have a template that survives contact with a real release process.
- No integration is claimed with any specific CI, chat, or agent platform. Where internal testing has involved third-party tooling, that was a test we ran — not a partnership, an integration, or an endorsement, and not a statement that those tools need this control.
If this is your boundary
The honest starting point for a release workflow is observe-only: run the gate alongside your existing pipeline, block nothing, and compare what it would have flagged against what actually shipped. That produces the false-block data neither of us has yet.