Inspiration
Every engineering team has shipped on a green checkmark and a gut feeling — and every team has been burned by it. The claim that mattered ("we don't collect message content," "this endpoint is idempotent") quietly stopped being true somewhere between the planning doc and production, and nobody caught it until the incident. We wanted a tool that makes that gap physically impossible to ignore: no claim ships without current, linked evidence, and no reviewer signs off without proving they actually read that evidence.
What it does
Release Truth is a multi-user, PostgreSQL-backed evidence gate for release decisions. Teams record material claims about a release, attach evidence (manual or imported live from GitHub), and record reviewer decisions. The server — not a person, not the client — computes a deterministic GO / NO-GO / CONDITIONAL GO / NOT EVALUABLE verdict from the current evidence ledger every time it's asked, and it fails closed: missing or stale evidence means no GO, full stop.
A real GitHub App integration imports issues as claims and pull requests, commits, check runs, and commit statuses as evidence, verifying installation access on every call and normalizing/hashing every imported record so retries are idempotent.
Selecting any claim or evidence exposes "Assess with GPT-5.6": it reads the claim and the entire current evidence set (not just one item), and returns a grounded relation (supports / contradicts / unproven), a finding, an impact statement, and cited excerpts. Every citation is checked server-side to be an exact, contiguous substring of the source it claims to quote — a hallucinated citation is rejected before it ever reaches the client. The model has zero authority over the verdict; a bad or unavailable model call degrades explanation quality, never release safety.
Every decision, claim, and evidence record is append-only. Finalized releases export as Ed25519-signed, tamper-evident JSON — change one byte and /api/exports/verify catches it.
How we built it
The entire evidence-gate architecture — the append-only Postgres schema, workspace RBAC, the deterministic verdict engine, the GitHub App integration, Ed25519-signed exports, and the production deployment pipeline (Docker + Contabo) — was built end-to-end by Codex in one focused session. The GPT-5.6 evidence-assessment endpoint (structured Responses API call + server-side grounding check) was also written by Codex in that same session, though it wasn't wired into the UI yet.
Everything after that was iterative hardening on top of that foundation: connecting the already-built GPT-5.6 endpoint to the live UI, building the claim/code/tests/decisions release timeline, an accessibility and RBAC pass driven by two independent UX audits, and closing a real gap where "the reviewer confirmed they read the evidence" was only enforced in the browser, not on the server (now a hard 400 evidence_not_reviewed if the acknowledgment flag is missing from the API call itself, not just the UI checkbox).
Challenges we ran into
The most interesting bug wasn't in the evidence logic — it was in the GitHub OAuth callback. The session cookie was set with SameSite=Strict, which silently discards the cookie on the exact cross-site top-level redirect GitHub sends back after authorization — meaning every GitHub App connection attempt, for every user, was failing with a 401, invisibly. It only surfaced by actually driving a real GitHub App install against the live production app rather than trusting the code. Fixed to SameSite=Lax (still blocks the actual CSRF vector — cross-site POST/fetch — while allowing the legitimate top-level OAuth redirect).
We also ran real end-to-end Playwright tests directly against the production deployment (not a mocked environment) — real GitHub App install, real commit imported as evidence, real claim, real decision with the server-enforced acknowledgment, real deterministic GO verdict, real signed-and-verified export. That run surfaced a second real finding: our own production anti-abuse rate limiter (5 registrations per IP per 30 minutes) correctly blocked several test runs — which we take as confirmation it works, not a bug to route around.
What's next
Deeper CI-signal evidence kinds (SAST/dependency-audit results as first-class evidence, not just generic "test"), org-level policy templates for required evidence kinds per claim category, and a webhook-driven live re-verdict when linked GitHub evidence changes after a decision was recorded.
Built With
- codex
- docker
- drizzle-orm
- ed25519
- github-app-api
- gpt-5.6
- next.js
- node.js
- playwright
- postgresql
- react
Log in or sign up for Devpost to join the conversation.