Tanilo

Changelog

Dated releases, fixes and supporting evidence.

Tanilo was named AgentOracle until September 2026. Entries before that date refer to the same service under its previous name.

  1. /evaluate: act now requires a usable answer from every claim-producing checker; input limit enforced, URL input turned off, usage accounting required, scoring repairs

    2026-10-28: A result can be act only when every claim-producing checker returned a usable answer. The three checkers that can supply claims are sonar, sonar-pro and gemma-4. If any one of them is rejected — its request failed, its output could not be parsed or validated, it answered with no claims, it gave no valid confidence, or it is not configured — then the published mapping returns halt and the response recommends verify. This is the case even when the remaining checkers agree and the score is high. It also applies when the claims were refuted: the recommendation is then verify, not reject, and the per-claim verdicts are unchanged. A response recommendation of act or reject requires a usable answer from every claim-producing checker; this requirement does not establish that the assessment is correct.

    Full details

    A failed or rejected checker now leads to a non-act outcome. Before this release, a failed checker could be excluded from the agreement calculation. The remaining checkers could then produce an act result. Failure or unusable output did not establish that the excluded checker agreed. Receipts issued before this release could therefore reach act after a checker had failed. In those receipts a failed checker shows as rejected in the signed sources rows, but an empty answer was recorded as ok (see below). This release does not modify previously issued receipts, and their signatures still verify; signature verification does not establish that their recorded assessments or checker statuses were correct.

    Text longer than 4,000 UTF-16 code units is now refused with HTTP 413 input_too_long. Nothing is cut. Until this change, only the first 4,000 code units of the input were evaluated, and the receipt's claim hash covered exactly that part, as the 2026-10-16 entry said.

    URL input is turned off. A request that includes url now gets HTTP 422 url_input_disabled, and nothing is fetched. Until this change, /evaluate fetched the address and evaluated the first 4,000 code units of the response exactly as received. HTML responses were not converted to readable page text before evaluation; markup and page content were evaluated together within the limit. JSON responses were re-serialized first. The receipt's claim hash covered the evaluated portion, not necessarily the full response. Our description of the URL option ("fetch and verify content at this URL") did not explain this processing or coverage limit. When text and a URL were sent together, the text was evaluated and the URL was only echoed back and used to update a per-domain score; that has stopped too. To check text from a page, send the text as content.

    No evaluation runs without usage accounting. The shared daily limits are counted before any model or search provider is called. If that count cannot be updated, /evaluate now answers HTTP 503 accounting_unavailable with Retry-After, and calls no provider. Before, each server counted on its own until storage came back. The per-address-range rate limits (the key is a truncated client address: IPv4 /24, IPv6 /48) still fall back to each server's own count during a storage outage, which is weaker than the shared limit. After a storage timeout, a server refuses new evaluations for 30 seconds.

    Errors no longer expose internal details. On /evaluate, /verify-gate, /v1/verify-facts, /traffic and the bazaar bootstrap route, an internal error returns a generic message with a reference to quote; the detail is kept in the server log under that reference. A signing failure is reported as signing_error. The API description no longer says that paid tiers turn on after a benchmark: no paid plan is announced.

    A new, immutable policy version for /evaluate receipts. /evaluate receipts issued from this release name mapping tanilo-v0.3-evaluate-2026-10-27 (signed in v_gate.mapping_id and mapping_hash, sha256 56a84b2bb3551ed8800d2b5805d905898997d62a8f48926af82bec1636cd409f). The date in its name dates the rules version; it was published on 2026-10-28. Its gate rules are those of tanilo-v0.3-2026-10-13 plus one new rule, evaluated first: if any claim-producing checker is rejected, the result is incomplete_checks, which maps to halt. Anyone holding a receipt can check that rule themselves from the receipt's own signed sources rows; no new signed field was added. The document also states:

    • Checker status. ok means the checker's output was usable and was used; rejected means it was unusable, so nothing from it was used: its request failed, its output could not be parsed or validated, it contained no claims, a required confidence was missing or invalid, or the checker is not configured. rejected describes the checker's execution and output, never a claim verdict; it never means the checker contradicted the claim.
    • Claim source. The claims come from the first of sonar, sonar-pro and gemma-4 whose row is ok, in that order, whatever order the answers arrive in. If none is ok, no receipt is issued. The response names the source in evaluation.claim_source. A receipt shows what we recorded; its signature does not independently prove which model supplied the claims.
    • Confidence is required. sonar, sonar-pro and gemma-4 must state a confidence from 0 to 1 on every claim. 0 is valid. An answer with a missing, null, non-numeric, non-finite or out-of-range confidence is rejected as a whole. Before this release a missing confidence was replaced by 0.5.

    The adversarial checker is not a claim producer, so the new rule does not cover it. A result that was not adversarially probed already returned halt before this release, and still does.

    What earlier receipts do and do not say. Earlier /evaluate receipts that name tanilo-v0.3-2026-10-13 were issued under a document that defines none of the above and has no such rule. In them, a checker that answered with an empty claim list was recorded as ok, the same as a checker whose claims were used, so those receipts do not show whether that checker contributed. rejected in them meant only that the call failed or the output failed parsing or validation. This release does not modify previously issued receipts, and their signatures still verify; signature verification does not establish that their recorded assessments or checker statuses were correct.

    Scoring repairs. These change confidence values and, in some cases, the recommendation:

    • Each checker's answers are matched to the right claim, one to one. Before, two claims that began with the same words could receive the same answer.
    • A confidence of 0 is kept as 0 (it was replaced by 0.5, and by 0.7 in the overall score).
    • A calibration value outside 0 to 1 is ignored instead of pushing the score out of range.
    • If the first checker's answer is unusable, including an empty answer, the second checker's claims are used (see the claim-source order above). That result cannot be act, under the new rule.
    • A checker's agreement with its own verdict is counted the same way for refuted and unverifiable claims as for supported ones.

    Feedback, and the source reputation scores. POST /feedback now answers "Feedback received. It is not currently used for scoring, verdicts or receipts." It used to say feedback "improves scoring for all agents", which was not true: nothing has ever read feedback for scoring, verdicts or receipts. GET /health and GET /reputation carried the same overstatement and have been corrected. To be exact about what did update those scores: the per-domain score that GET /reputation serves was updated by /evaluate requests that carried a url, from the score of that evaluation — never by feedback. Because URL input is now refused, nothing updates those scores any more, and /reputation says so.

    New response fields. evaluation.claim_source names the checker whose claims were used, sources[].reason gives the reason a checker was rejected, and meta.storage reports storage health. None of these is part of the signed receipt. Receipts keep the same signed fields, and receipts issued before this change are unchanged. /v1/verify-facts receipts are not affected and keep mapping tanilo-v0.3-2026-10-13. We now keep a daily count of rejected checker answers by checker and reason (no text from requests or answers), to see how often answers are rejected.

  2. /evaluate response recommendations use the receipt's published gate calculation

    2026-10-19: Changed /evaluate response recommendations to use the same published gate calculation as newly issued receipts. A response can recommend act only when the mapping's gate is act and the score meets the effective caller min_confidence. The caller threshold may make the response more restrictive; it cannot override a gate halt.

    The response now recommends reject when the aggregated verdict is refuted. Low scores without refutation produce verify. Results involving incomplete adversarial checks or unverifiable claims may therefore return verify where earlier responses returned act.

    min_confidence defaults to 0.8 only when omitted. Explicit zero is preserved. Supplied values must be finite JSON numbers from 0 to 1 inclusive; invalid values, including numeric strings and null, return HTTP 400 with invalid_min_confidence before any provider call. The published gate threshold remains 0.7.

    Added evaluation.policy, identified as evaluate-body-policy/v0.1, and a separate signing status. Signing availability does not change the evaluation or response recommendation.

    The receipt's signed gate retains its existing mapping semantics. The caller threshold and surrounding response recommendation are not covered by that signature. Historical receipts are unchanged.

    This change repairs decision consistency; it does not establish evaluation accuracy. Retrieved sources still do not contribute to the model verdict, and neither an act result nor a valid signature establishes that acting is safe or authorized.

  3. /evaluate containment: wording, validation and cache

    2026-10-16: After an independent review of POST /evaluate, this release removes specific unsupported statements and tightens checker-output validation; known limitations remain. The "Safe to act" sentence is gone: an act result now reads "The aggregate model-check score met the threshold applied to this response. Retrieved sources did not contribute to the verdict. This is not a determination that acting is safe or authorized." Generated source-support sentences and generated corrections are removed. The evidence field contains a model-generated explanation, an application note describing reported adversarial disagreement, or an empty string. A checker whose output fails parsing or validation is reported as rejected with a reason instead of ok. Each roster row records the model that was requested and the model the provider reported. Public descriptions now state that the response recommendation and the signed gate decision use different rules and can disagree, and that only the first 4,000 UTF-16 code units of the input are evaluated. The AVeriTeC figure on the benchmarks page is labelled as measured on 28 May 2026 on an earlier pipeline. API commits e6ef1a69, a11876df, 306a1edf.

    The /evaluate result cache is disabled. Requests that proceed to evaluation run fresh checks rather than replaying a cached response. A signed receipt is returned when signing succeeds. Every /evaluate description now carries: "Experimental. Not suitable for automatically authorizing actions: the response recommendation and the signed gate decision currently use different rules and can disagree."

  4. Fixture-key disclosure and default refusal in tanilo-receipt-verify 0.2.4

    2026-10-16: The published key set at /.well-known/jwks.json listed the test fixture key ao-fixture-detached-rfc7797-2026-07-ed25519-0f8bf2a5, whose private half is published on purpose in the spec repo, with status fixture: in the agentoracle.co set from 29 July 2026 and in the tanilo.io and api.tanilo.io sets from 2 October 2026. A signature under a publicly available private key does not establish that Tanilo issued the receipt, because anyone can create such a signature. A verifier that did not read that status accepted a signature under it as valid against the production set; every release of tanilo-receipt-verify before 0.2.4 (and agentoracle-receipt-verify 0.1.0) did. We found this on 16 October 2026 while checking our own hosted MCP endpoint. The production signer code reviewed does not select this fixture key, and the fixture's private key has never appeared in the API repository's history. That finding does not establish that no receipt signed with the public fixture key was accepted by a relying party. At 2026-10-16 19:05:02 UTC, we confirmed that the fixture key was absent from the production key sets served at tanilo.io, api.tanilo.io and agentoracle.co. Previously downloaded copies may still contain it. The key is served separately at the test-key endpoints (/.well-known/jwks-test.json, also at api.tanilo.io) and remains in the spec repository's fixture file. tanilo-receipt-verify 0.2.4 refuses a key marked fixture or test, or that known kid, unless the caller passes allow_test_keys=True; its result names the refusal. What to do: upgrade to tanilo-receipt-verify 0.2.4, fetch the key set again, and treat any receipt that verified only through this kid as not verified. A key identifier alone does not establish that a receipt is genuine. Reverify the receipt using an authenticated production key set and the applicable verification policy. Historical receipts may use other documented production keys. If you retained only an overall verification status, reverify the original receipts rather than assuming they used a production key. Investigate any decisions that relied on receipts accepted solely through the fixture key. Removing the key does not retroactively change previously stored verification results. The key-continuity statement of 2 October 2026 lists the fixture key as the set stood that day; it is a signed record and is not re-issued. Details on the trust page.

  5. Spend cap check: Does this offer fit within the cap you supplied?

    2026-10-13: Before an agent commits to a purchase, spend_cap multiplies the offer's unit price by its quantity, exactly, and compares the total with the remaining cap you supply. It signs the result when signing succeeds. Three results: verified, contradicted, or indeterminate with a reason. You supply the cap and what has already been spent against it; this check does not retrieve or track budgets, and keeps no running total. A verified result says the offer's total is within the remaining cap. Whether to pay is your policy's decision. The spend_cap check type is part of catalog revision tanilo-deterministic-v0.3-2026-10-10; receipts carry the revision in force when signed.

  6. tanilo-receipt-verify 0.2.1: stricter Ed25519 input checks

    2026-10-13: tanilo-receipt-verify 0.2.1 is on PyPI. verify() now rejects small-order Ed25519 public keys and R values, non-canonical point encodings and out-of-range S values before the crypto library verifies the signature, and returns a failed verification with a reason. The identity-key behavior was reported by Noûs through @robertolocatelli81-dev in x402-foundation/tsc#4. @babyblueviper1 reproduced it and added small-order checks to preaction-governance-conformance at 90b5032. This release adds corresponding input restrictions to Tanilo's verifier. Full entry: CHANGELOG.

  7. New receipts bind to the mapping document tanilo-v0.3-2026-10-13

    2026-10-13: receipts from /evaluate and /v1/verify-facts now carry mapping_id tanilo-v0.3-2026-10-13 and mapping_hash sha256-52842536d5c8444b6add8e8cb7e8987aa3fcc0bf40cc7ac266ddc1744f0711ce: the same rules as agentoracle-v0.3-2026-05-30, with only the identifier, issuer name, resolution URL and publication date changed. Calls that declare no agent_id are recorded as urn:tanilo:verify-facts:anonymous instead of did:ao:verify-facts:anonymous. Receipts signed before the cutover on 13 October 2026 (UTC) are byte for byte unchanged and keep verifying; tell the two apart by mapping_id and mapping_hash rather than by the signing date. The earlier document stays published at its content address and its alias. Both documents: tanilo-v0.3-2026-10-13, agentoracle-v0.3-2026-05-30.

  8. tanilo-mcp 3.0.0: the contract price check as an MCP tool

    2026-10-08: tanilo-mcp 3.0.0 on npm and in the official MCP Registry exposes the contract price check as an MCP tool; the earlier agentoracle-mcp package is deprecated. Source: TKCollective/tanilo-mcp.

  9. AER-1 interop: a worked example linking two receipt formats

    2026-10-08: A worked example links an AER-1 execution record (draft-zambo-aer1) to a signed Tanilo receipt from the live API by canonical payload hash; we verified the link, the hash and our signature on our side (results). The AER-1 record is unsigned and the held call is the example's scenario; the linkage does not show execution or causal reliance. Tanilo half: examples/interop/aer1.

  10. tanilo-receipt-verify 0.2.0: the anchor check in the package

    2026-10-08: tanilo-receipt-verify 0.2.0 on PyPI adds verify_anchor, which checks an anchoring proof offline and, with a chain lookup against contracts you trust, reports when the receipt's payload was anchored. It doesn't show when the receipt was signed or that its claim is true. Details: Anchoring, check this one yourself; package: PyPI.

  11. Website redesign live

    2026-10-07: The site moved to one shared design, and the two docs pages are generated from reviewed text. Wording was audited page by page against what is live.

  12. Two delegation-chain-ref conformance vector sets contributed to argentum-core

    2026-10-07: two vector sets owed on x402-foundation/x402#2332, mid-hop-revocation (revocation metadata for an ancestor hop does not change the structural verdict; a broken-continuity control fails either way) and partial-chain-recovery (a missing hop restored byte for byte under the original reference, then replay detection), merged into giskard09/argentum-core as PR #123 and reproduced from a cold clone by another contributor, babyblueviper1, recorded in PR #126. They test structure and byte restoration only, not present authority, cascade revocation or future-use blocking.

  13. Eight proposed rev 10 evidence-pinning vectors contributed and merged

    2026-10-07: robertolocatelli81-dev contributed eight proposed vectors for evidence-pinning rev 10 under CC0, merged into tanilo-receipt-spec under fixtures/contrib/ (PR #11). Vector 1 encodes a clarification proposed for -04 that the filed -03 text leaves ambiguous; vectors 7 and 8 test the filed -03 form rules against a trailing newline. They are proposed, not part of a released corpus; rev 9 and its pin are unchanged. Verified here before merging: byte-for-byte regeneration, 8/8 with both pinned checkers, and the pre-fix control failing exactly the two new vectors.

  14. GOAT anchoring batch recorded

    2026-10-07: The batch index records batch batch-b817351797949062ffe371729b5a1575 at 2026-10-07T00:46:32Z, transaction 0x5552734891f4a7db0991a455e04567f41df5f4745e7bee7acd14380be00631e1, listed at /v1/anchor/batches. Anchoring is currently scheduled once a day; no interval or per-receipt proof is guaranteed.

  15. Anchoring: proof a receipt's payload existed by a given time

    2026-10-06: receipts are now anchored on GOAT Network. Queued receipt hashes are combined into Merkle roots published on-chain, currently run once a day. An anchor shows a receipt's canonical payload existed by the block's timestamp; it doesn't show when the receipt was signed, or that its claim is true, and not every receipt is guaranteed a proof. Details: Anchoring: proof a receipt's payload existed by a given time.

  16. Contract price check live

    2026-10-05: contract price check live. POST /v1/verify-facts has a seventh check type, contract_price_match: does an offer match the terms you supplied (caller-supplied, not verified as genuine)? Results are verified, contradicted or indeterminate. The rule and its tests are public.

  17. Paid research routes retired

    2026-10-04: the paid research routes were retired; /evaluate and /v1/verify-facts remain free in beta.

  18. Tanilo's own signing key is live; the previous key is retired

    New /evaluate and /v1/verify-facts receipts are signed under tanilo-2026-10-ed25519-7d885da9, a new key with no signing history before Tanilo, and name issuer tanilo.io. ao-composed-2026-06-ed25519-c3abfce3 stops signing new receipts today (its last signature is on the key-continuity statement) and stays published as retired so existing signatures under it can still be checked; rotation alone does not invalidate them, and receipt validity, freshness and relying-party acceptance remain separate checks. Nothing already issued is re-signed. The key set is now published at tanilo.io/.well-known/jwks.json, with the same set at api.tanilo.io and agentoracle.co, and each key carries its status. A key-continuity statement signed by both the retiring and the new key is at /.well-known/key-continuity.json. First step of the issuance-path assertion: the new key's JWKS entry declares role: evaluated and its receipts carry the same role in the protected header (design: Pote, AgentTrust); receipts under the retired key carry none, so under the issuance-path role rule, signatures under it resolve to role unknown. That is separate from signature validity, and a relying party that requires an established issuance path treats unknown as its own fail. The API also answers at api.tanilo.io; agentoracle.co continues to serve the same deployment. Details on the trust page.

  19. Gateway /v1/compose withdrawn; its signing key retired

    Our own audit found that the API gateway's /v1/compose signed verdicts supplied by the caller under ao-composed-2026-07-ed25519-3d44ba27 from 27 July to 24 September, without evaluating the claim. The route was withdrawn on 24 September 2026, when we deleted its private key and signing ended. It returns 410 since 28 September 2026, when we also removed its signing code. How many envelopes it signed cannot be established from the records. The key stays in the JWKS so existing signatures verify, but its signatures don't show we evaluated anything. This is a different route from the agentoracle.co /v1/compose stub closed on 28 August. The homepage and trust page now show a receipt issued by /evaluate instead of the one signed through this route. Full account: incident record, 2026-09-30 note.

  20. tanilo-receipt-verify 0.1.1 — malformed input no longer raises

    stillmarcus24 found that 0.1.0 raised an exception on 22 of 30 malformed envelopes, so the 0.1.0 entry's claim that malformed input returns a result was broader than true. 0.1.1 checks the envelope's structure before anything reads it and returns invalid for malformed input; anything unexpected is reported as indeterminate with an instrument_failure reason. An exception is not a verification state. PyPI ↗

  21. tanilo-receipt-verify 0.1.0 published

    Supersedes agentoracle-receipt-verify 0.1.0. A partial key set is now reported as not evaluated, so the envelope comes back indeterminate rather than invalid (case AC-11 in stillmarcus24's assurance-run suite) — unless the caller declares the supplied key set complete, in which case an unresolvable key is a policy refusal. ES256 is supported, and malformed input returns a result instead of raising. PyPI ↗ · Source ↗

  22. /trust rebuilt — honest content only, replacing the fabricated live-numbers page

    The prior /trust page presented invented per-source "Verified Claims" counts, live endpoints for an API that wasn't live, and prices that contradicted /pricing. Rebuilt from scratch: keys and rotation policy, a link to the incident record, the second-implementation standing claim with its conformance vectors, offline verify commands matching the homepage, an explicit list of what's still open, and the IETF draft link. No numbers, no live endpoints, no network-effect claims.

  23. Homepage example corrected — it no longer shows unchecked claims as checked

    The example box showed “act · confidence 0.89 · 2 sources checked” and a signature line for any claim typed into it — including false ones — though nothing was checked or signed. It now shows three fixed examples, each with its own verdict, and says plainly that the live checker isn't open yet. The animated receipt at the top of the page is now labelled as an example.

  24. Article 12 considerations tool corrected

    The tool applied Article 12(3) to every Annex III category. Article 12(3) applies only to remote biometric identification systems (Annex III point 1(a)); those rows now appear only when that category is selected. The 12(3)(d) row no longer suggests a receipt's signing key identifies a natural person — a key identifies a service, not a person. The auditor letter template was removed: it asserted that every event of a system produces a signed record, which receipts don't do. Retention now cites Articles 19(1) and 26(6). Article 12 checker ↗

  25. draft-krausz-verification-state-02 posted

    Four verification states — verified, contradicted, indeterminate, not_evaluated — with reason codes that separate a verifier's own instrument failure from a finding; evidence pinning; the subject clause generalized to any state with an open attribution question; and admissibility as a gate before any state is assigned. Open questions are listed in its Section 10. Datatracker ↗

  26. Settlements relabelled as test payments

    The “8 settlements verified” in the Bazaar entry and the first SKALE settlement were our own test payments, confirming the payment path end to end. Both entries now say so.

  27. Site audit corrections — quorum description, per-claim evidence disclosure, incident-record dating

    "Four independent sources" was replaced across the site with an accurate description: multiple quorum members plus an adversarial re-check pass, with sources retrieved per claim. Three of the four members share a backend; the prior phrasing implied independence that didn't exist.

    Correction 2026-10-02. The description this entry called accurate (quorum members plus an adversarial re-check, with sources retrieved per claim) still implied retrieval-grounded, independent checks. The checks are model judgment; sources are listed for reference and don't feed the verdict. See the 2026-10-02 copy update.

  28. Incident record (2026-08-25) corrected — dating and self-consistency

    The record claimed to be "not edited after publication" while carrying an undated 2026-09-22 addition; that addition is now dated and moved into the Corrections section. "Nothing below is edited for the rename" was replaced with an accurate statement: service names were updated to Tanilo, dates/hashes/key IDs/quoted findings were not. The lede's "five days undetected" was corrected to match the four-day window (21-25 August) stated elsewhere on the same page. Full record: /incidents/2026-08-25-canned-verdicts ↗.

  29. Benchmarks page — backend-replacement disclosure added to the AVeriTeC headline

    The 57.6% AVeriTeC figure is measured on the pipeline as it existed on 2026-05-28. The backend was replaced in September 2026; the page now discloses that the number has not been re-run since, rather than presenting it as current.

  30. Benchmarks page — /v1/sign, /v1/sign/batch, and /v1/compose latency withdrawn from live presentation

    All three were presented with runnable curl commands against a live host. /v1/sign and /v1/sign/batch are the forgery-oracle endpoints closed in a8ce2a18d (see the incident record) and now require auth; /v1/compose was already marked withdrawn. All three are now labeled historical, dated to their original 2026-06-25 measurement against agentoracle.co, since tanilo.io did not exist at that date and carries no live API today.

  31. Incident record published — canned verdicts, 21-25 August 2026

    Four-day window in which /evaluate signed and returned receipts for evaluations it never performed. The signed layer halted every affected request; the presentation body did not disclose that. Fixes shipped 4a8b37177, 98b3b7e78, c28c5dd6f, 49261a37b, a8ce2a18d. External review by @giskard09 found and closed a same-class defect in the conformance sample and an unauthenticated signing path; kid separation remains open with no date. Full record: /incidents/2026-08-25-canned-verdicts ↗.

  32. Verifier v0.1.0 published to PyPI — three-outcome status semantics live on the released artifact

    pip install agentoracle-receipt-verify==0.1.0 · MIT · offline verification against the published JWKS. Public API exposes STATUS_VALID, STATUS_INVALID, STATUS_INDETERMINATE. Post-publish gate ran against the installed package in a fresh venv — the no-key path returns indeterminate rather than valid. pypi ↗

  33. Experiment A pre-registered — design frozen, three model families, results Sep 2

    Two deep-research agents, one gated through /evaluate (fail-closed, replans on failing verdict), 200 questions across four domains. Measured quantity: which citations survive independent verification. Ground-truth stack deterministic. The pre-registration document was public before any data was collected; the harness and the frozen question set land before the first run, on the schedule published in the repository README. pre-registration ↗

    Corrected 2026-08-17. This entry originally read “Pre-registration document, harness, and questions all public before any data was collected.” That overstated what was public: at the time of writing the harness was a disclosed stub and the question set was an empty array, both scheduled in the repository README for 2026-08-17, ahead of the 2026-08-19 run start. The pre-registration document itself was complete and public as described. No data had been collected at any point, and none has been collected as of this correction.

    Update 2026-09-02. Headline withdrawn — the collection window overlapped the 21–25 Aug outage. See the append-only amendment 2351e29 and the incident record: /incidents/2026-08-25-canned-verdicts ↗.

  34. Virtuals showcase merged — a live production receipt now sits in Virtual-Protocol/acp-cli-demos

    10 files, +670/-0, merge commit c08af80e7a12. Receipt blob d13a275e1c4d is byte-identical to the production receipt. Anyone can clone the showcase folder, install the verifier, and run python3 verify.py receipt.json against the live JWKS. showcase ↗

  35. Deterministic mode — POST /v1/verify-facts: six check types, no LLM in the trust chain, check_mode recorded inside the signed payload

    /docs/deterministic-mode ↗

  36. v0.4 draft rev-2 — per-layer provenance design (layer_trace, mode ∈ {recomputable, signed}, three-state absence semantics) folded in from public design collaboration

    commit ↗

  37. Routine credential rotation completed — all previously issued receipts verify unchanged against the published JWKS

    jwks ↗

  38. /pricing page + MCP homepage block live

    /pricing ↗

  39. Self-serve open — card → API key → signed receipts, live

    current pricing and availability ↗

    Update 2026-09-24. Self-serve ran on agentoracle.co; Tanilo's self-serve is launching.

    Update 2026-11-06. The self-serve paid tier was withdrawn on 2026-09-24 and has not relaunched. Public API calls are free during the beta; see pricing.

  40. v0.4 conformance suite complete — 1 accept, 3 reject, 3 status vectors; two independent implementations; every envelope and wrapper hash recomputed byte-identical on both sides

    suite ↗

  41. First v0.4 conformance vector shipped — v04-accept-001, two-party signed (AgentOracle + AgentTrust legs), byte-identical across three independent canonicalizations

    vector ↗

    Note 2026-11-06. Both signatures in this vector use test-fixture keys (ao-fixture-v0.3-composed-2026-06 and at-fixture-v0.3-composed-2026-06), not production signing keys.

  42. Sequence-integrity example merged into the community pre-action governance conformance suite — N artifacts over time, Merkle inclusion + tamper demos

    merge ↗

  43. Canonical verdict→gate mapping published, content-addressed — sha256-addressed immutable doc

    mapping ↗

  44. Third cross-citing draft filed in the receipt family — draft-msebenzi-evidence-action-00 cites draft-krausz-verification-state

    datatracker ↗

  45. Composed multi-issuer envelope example merged into the community conformance suite — N signers, one artifact

    PR #4 ↗

  46. Independent byte-identical second implementation merged — AgentTrust rebuilt the format from spec text alone

    PR #33 ↗

  47. First candidate profile entry in the receipt-format registry — verification.v0.3 entered as a candidate profile in the ERC-8210 Receipt Profile Registry

    registry ↗

  48. Initial Internet-Draft filed — draft-krausz-verification-state-00

    datatracker ↗

    Corrected 2026-09-24. -00 was filed on 6 June; -01 followed on 12 June.

  49. Open-source receipt verifier published — offline JWS verification, MIT licensed

    github ↗

  50. Cross-operator benchmark live — open methodology, open submissions

    github ↗

  51. Receipt spec v0.3 — binary-halt gate + canonical/derived/version-bound mapping

    spec ↗

  52. AVeriTeC 2024 dev published — 57.6% overall, held-out 57.7%, MIT licensed

    repo ↗

  53. Pinned in x402trace v0.3.3 — first operator-contributed fixture in the harness

    release ↗

  54. Live on SKALE Base — first test settlement, gasless on SKALE

    explorer ↗

  55. Tutorial #4 — claim verification in AI content approval workflows

    Published under the pre-rename name; unlinked here. (dev.to/agentoracle/how-to-add-claim-verification-to-your-ai-content-approval-workflow-3797)

  56. Indexed in Coinbase Bazaar — 8 test settlements verified, our own payments, confirming the payment path end to end