Preview vs contract verification

agentskeptic quick is a fast SQL-only preview: it infers checks from raw tool activity against a database you pass. It does not run full registry contract verification across HTTP, object, vector, or Mongo witnesses.

agentskeptic check is the decision-grade path: registry + events + readable targets, Outcome Certificate on stdout, and the truth_check_verdict: / release_critical_truth_check_verdict: lines on stderr. Use agentskeptic check for CI and release gates.

Optional coverage budgets

In CI you get

When you run the first-party GitHub Actions composite at .github/actions/agentskeptic-check (wrapping agentskeptic check), each run exposes three CI surfaces:

A certificate-derived job summary (failure spine + per-step table + witness kinds).
A downloadable artifact named agentskeptic-outcome-certificate (outcome-certificate.json).
Structured composite outputs (verdict, state-relation, trust-decision, release-critical-verdict, failing-tool-ids, primary-reason-codes, failing-witness-kinds, recommended-action, automation-safe, certificate-path, plus the existing stdout-path / stderr-path / exit-code).

Full CI contract: ambient-ci-distribution.md

First proof: contract truth check

Run agentskeptic check against your registry, events file, and readable verification targets (database for SQL; remote URL for HTTP / object / vector / Mongo witnesses per registry).

A successful run gives you:

stderr beginning with the two machine lines truth_check_verdict: and release_critical_truth_check_verdict:
stdout containing the Outcome Certificate JSON
a reusable path for local verification and CI

Full guide: docs/integrate.md

Hybrid contract demo (SQL + HTTP witness): examples/hybrid-contract-demo.mjs (requires npm run build and POSTGRES_VERIFICATION_URL).

npx agentskeptic check --workflow-id YOUR_WORKFLOW_ID \
  --project ./your-app \
  --db ./path/to/readable.sqlite

Try paste verification

Before you run it

You need:

Node.js 22 or newer
read-only access to verification targets you configure (database for SQL steps; witness URLs and credentials for HTTP, object, vector, or Mongo per registry)
structured tool activity exported as NDJSON

Learn guides include Next.js and Postgres paths alongside SQLite snapshots.

Reading the verdict

On verdict exits, stderr starts with two automation lines — truth_check_verdict: trusted|not_trusted|unknown and release_critical_truth_check_verdict: trusted|not_trusted|unknown (see docs/first-truth-check.md). When an opt-in coverage budget policy is active, two additional machine lines follow the truth lines — see docs/integrate.md (optional coverage budgets). The human-readable report below those lines may include engine phrases for each step; the first truth line is the primary gate for whether you can rely on the global workflow outcome.

`truth_check_verdict`	Next action
`trusted`	Proceed with reliance only when your policy allows (the certificate must still show expected state matched). Do not claim verified if anything else disagrees with this line.
`not_trusted`	Block handoff, ship, bill, or continuation on this run—fix the workflow, data, or registry expectation and re-run `check`.
`unknown`	Do not claim verified—add observations, witnesses, or narrow scope until the verdict can be determined.

If stored state is wrong, you get not_trusted with an actionable reason such as ROW_ABSENT in the report.

No more silent green traces hiding bad data.

Next steps

Try the interactive demo to see a missing-write failure.
Run the command above against your own readable data.
Follow the Learn guides to wire the same check into CI.