GoodHelp Constitution
Don’t trust the dashboard. Verify the receipt.
When a GoodHelp agent is blocked from a risky action, we can hand you a cryptographically signed denial receipt. This page checks one in your own browser — the ECDSA signature is verified client-side against our published public key, with no request to our servers. Proof you don’t have to take our word for.
Pre-filled with an illustrative signed receipt. Paste a real exported receipt to verify it instead.
The key you obtained from us out-of-band. The signature must verify against this key — not one carried by the receipt.
How the check works
Rebuild the signed bytes
Your browser recomputes the exact canonical payload the signer covered — the manifest (minus the signature) and the audit body, domain-separated.
Check the ECDSA signature
WebCrypto verifies the P-256 / SHA-256 signature against the published public key. The private key lives only in Google Cloud KMS and never leaves it.
Tamper breaks it
Change any signed field — the org, the decision, the chain position — and the signature no longer verifies. Try it with the button above.
The bundled example is illustrative (fictional “Northwind Trading Co.”, signed with a demo key) — it exposes no customer data. A real exported receipt from your org verifies here the same way. Signatures are tamper-evident and offline-verifiable; we don’t claim “immutable” or “blockchain.”
The whole picture
This receipt is one piece of four
GoodHelp Constitution is the rules your agents work by — and a tamper-evident record of what they did, why, and on whose authority. Verifying a receipt is the last of four parts that work together:
Rules you write and can see
Each agent runs under a declarative policy: allow-listed tools, a per-run cost cap, an external-comms allow-list, and data-scope predicates. Decisions are made before the tool runs — and you can tell at a glance whether enforcement is live for each agent.
How policies work →Risky actions pause for a person
Sensitive actions wait for a second person to approve. Separation-of-duties means whoever edited an agent in the last 24 hours can’t approve its next action — enforced fail-closed, so a missing audit context blocks the approval rather than waving it through.
Governance deep-dive →A tamper-evident record
Every action — allowed or denied — is appended to a per-org, hash-chained audit log rooted in a Google Cloud KMS key. Any retroactive edit breaks the chain and is detectable on replay. Tamper-evident and append-only — we don’t claim “immutable” or “blockchain.”
Inspect the Trust Center →Proof you can check yourself
Export a signed evidence pack for any date range and verify it offline against our published key — no trust in our dashboard required. That’s exactly what you did at the top of this page, entirely in your own browser.
↑ Verify a receiptSee the whole Constitution
Inspect every control in the Trust Center, read the governance deep-dive, or talk to us about running your own agents under a Constitution — a record of what they did, why, and on whose authority.