REFERENCE

Changelog

This page tracks notable, user-visible changes to the Decision Receipt API. It is a human summary, not the source of truth — for the exact current state, read the version headers on any response and the live OpenAPI spec.

August 30, 2026 — strict JSON verifier releases

JavaScript CLI 0.1.4 (sha256:d6763fdcaa8e57a5872d0da231e4301c548014c2fe72379a067744a8b4734c31), Action 0.2.3 (sha256:39b50ef67ad5eee8ad915571f1d0c8c8c37955d33583c3f755a924a3c02c2ed4), and Python verifier 1.3.0 (sha256:6b48d7a7ee04df576ef2eaf2b90a2808b164f1ecbdcf345690c9c524b3497a47) are current. The JavaScript releases refuse duplicate object keys and integers outside the exactly representable range in receipt, pinned-keyring, and JSON-typed SCITT payloads. They also reject malformed UTF-8 and unsupported compressed JSON Content-Formats in SCITT payloads. CLI 0.1.3 and Action 0.2.2 are superseded because their SCITT verification path could discard a strict-JSON failure; earlier JavaScript releases and Python 1.1.0 are retired or superseded. Consult the security notice before relying on any verifier.

August 28, 2026 — offline verifier security notice

JavaScript CLI 0.1.0/0.1.1 and GitHub Action 0.1.0/0.2.0 are withdrawn and removed from the download surface. They accept malformed Ed25519 trust keys, report structurally matching unsigned chain coordinates as PASS, and do not reject ambiguous JSON object keys or unsafe integers.

• JavaScript CLI 0.1.0: sha256:c51b4844b778998ffe6ae954f3a826d4fc4d39b64394c83b2e9fe6139b040ce8
• JavaScript CLI 0.1.1: sha256:94e0591408db6a9f04ee8673142a7c2a9484b9fbb8c66b81047f95ddfe6f018c
• GitHub Action 0.1.0: sha256:c9fb20e09fa4a602db505c800cd93b8bd927717205f41c8b47eaab7fbe2c1abc
• GitHub Action 0.2.0: sha256:b912de607895cab7eb55d527afdb07b638151c3ff1497c87c9c4180b1c5ae185

JavaScript CLI 0.1.2 (sha256:f002af6a3e1500d2b264d634df4ba633bbaec053aebb121b57c6bff602363296) and Action 0.2.1 (sha256:7794fee665e17ee3047e2a8ea68df920a1901d3e12e9f781bc31b588f8a83724) replace them. They reject the malformed-key class and return UNVERIFIED for legacy cross-receipt linkage unless every involved chain coordinate has verified direct-JCS coverage. Duplicate-key and unsafe-integer JSON ambiguity remains, so use controlled input and do not use a PASS as sole evidence for hostile JSON.

Python verifier 1.0.0 (sha256:068309dbccae68a48b1213817940beb51b76af2862f1ee42e89bbce5f358c1c4) is withdrawn. Python 1.1.0 (sha256:cc439b5b9aad11b0e999174052e47add1c3e735ddff2860e53bb9f2cfa3b451f) supersedes it by rejecting malformed Ed25519 keys and reporting unsigned chain coordinates as UNVERIFIED. Duplicate-key and unsafe-integer JSON ambiguity remains under remediation, so 1.1.0 is limited to controlled input and must not be sole evidence for hostile JSON.

Discard Python 1.0.0 and the affected JavaScript artifacts, replace vendored JavaScript copies with the checksum-pinned releases above, reverify important prior results, do not cite unsigned legacy chain coordinates as authenticated, and reconfirm the pinned trust-key fingerprint through a separate channel. We found no evidence that a production receipt was forged or that these defects were exploited. See the full notice and current disposition.

v0.1.0 — spec 1.0 current

The capabilities available in the current published version. These are described in full in the API reference; this is the at-a-glance surface.

• Keys & tiers. Self-serve signup (POST /v1/signup), account info (GET /v1/account), and three tiers — free (100 req/hr), pilot (10,000 req/hr), enterprise (unlimited) — with a 1-hour sliding rate-limit window surfaced in X-RateLimit-* headers.
• Evaluation. POST /v1/evaluate — the core flow: a claim with typed, provenanced evidence is judged against a policy, checked for replay determinism, and returned as a signed Decision Receipt with verdict ALLOWED ESCALATED BLOCKED.
• Verification. POST /v1/verify performs schema, hash-integrity, and Ed25519 signature checks. For an offline check with Summit out of the request path, obtain and pin the public key through a separate trust channel.
• Simulation. POST /v1/simulate — dry-run a policy without persisting a receipt.
• Ledger & insight. /v1/ledger, /v1/ledger/stats, /v1/receipts/search, /v1/receipts/timeline, /v1/receipts/compare, /v1/receipts/diff, plus /v1/repos, /v1/agents, /v1/overview, and Prometheus /v1/metrics.
• Policies. GET /v1/policies and POST /v1/policies for built-in and custom policy configurations; GET /v1/templates for common claim shapes.
• Webhooks. Inbound POST /v1/webhook/github (auto-evaluates PRs, signature-authenticated) and outbound POST /v1/webhooks/outbound for receipt.created events.
• Spec. GET /v1/openapi.json and the interactive Swagger UI at /docs.

Versioning & compatibility

All endpoints are prefixed /v1. The implementation version is returned in X-DecRec-Version on every response; the spec version in X-DecRec-Spec. The API allows cross-origin requests (default origin *; methods GET, POST, OPTIONS; preflight 204). New capabilities are introduced under /v1 additively where possible; any breaking change would move the version.

Watching for changes

Because this summary trails the implementation, the reliable way to track changes is mechanical: diff the OpenAPI spec and watch X-DecRec-Version. New endpoints and field changes will always appear there and in these docs first. (Note: the receipt.created outbound webhook delivers receipts, not release notes — it is a data feed, not a changelog feed.)