1. Run a bounded check
Use the CLI against the artifact you explicitly choose. Save the receipt alongside your job output.
npx --yes genxis-gavel check .\change.patch --stage manual --receipt-out .\gavel-receipt.json --json
Gavel documentation
One bounded check.
One signed receipt.
Use Gavel from your IDE, CI pipeline, or a server-side cloud function. Submit the artifact you intend to check, retain the receipt, and verify the recorded decision.
Start here
The shortest useful path
First name the artifact and declared check. Next run Gavel. Finally retain and verify the signed receipt. The decision covers the evidence and check named in that receipt, nothing broader.
IDE / CI
Keep the check beside the change.
2. Verify the receipt
Verify the signed result as a separate pipeline step before the next policy-controlled action.
npx --yes genxis-gavel verify .\gavel-receipt.json --json
Key handling: set GAVEL_API_KEY only in an interactive local terminal or your CI platform's secret mechanism. Do not paste it into chat, source control, browser code, or client-side configuration.
Cloud builder / Edge Function
Use the HTTPS API behind your server boundary.
Replit, Bolt, Lovable, Base44, and similar platforms can call Gavel from an Edge Function, server action, or backend route. Import the OpenAPI document where supported, then keep the bearer token in that platform's server-side secret store.
Configure the integration
Use the OpenAPI 3.1 document as the transport contract. It describes health, checks, receipt verification, deployment attestation, bearer auth, and idempotency behavior.
Keep credentials server-side
Send the bearer token only from an Edge Function, server route, or backend integration. A browser client must not call authenticated Gavel endpoints directly.
The API supports idempotency so a safely retried submission can return its original outcome instead of creating a different one.
API contract
Stable HTTPS paths, explicit boundaries.
Use the OpenAPI document as the authoritative request and response reference. Gavel's deployed public surface includes:
/v1/healthz - public availability check/v1/checks - authenticated bounded check/v1/receipts/{receipt_root} - authenticated receipt retrieval/v1/receipts/verify - authenticated receipt verification/v1/deployments/attest - authenticated deployment attestationPrivacy boundary: submit only the artifact required for your declared check. Do not treat a receipt as proof beyond its named artifact, declared evidence, and recorded decision.
FAQ
Answers before you integrate
What is verified?
Only the declared check against the named submitted evidence. A result is bounded by the receipt; it is not a claim about the rest of a repository or system.
What is a receipt?
A signed record of the decision and its binding. You retain it and can verify the signature and recorded binding independently.
Where does the key go?
In a local terminal session, CI secret manager, or server-side secret store. It never belongs in browser code, a public client bundle, chat, or source control.
Can a browser call it?
Do not make authenticated calls from a browser. Put the call behind an Edge Function, server action, or backend route that holds the secret.
Does Gavel store my source?
Gavel evaluates the artifact you explicitly submit for a declared check. It does not crawl your project. Submit only what your check requires.
How does idempotency work?
Provide an idempotency key for a check submission. A retry of the same request can return the original result; a conflicting reuse is denied rather than silently changing the outcome.
What can Base44 or other builders import?
Use the public OpenAPI 3.1 document for the HTTPS contract. Where a builder supports server-side functions, place the bearer token there and expose only your own safe application action to the browser.