continuity-receipt 0.2.0__tar.gz

continuity_receipt-0.2.0/ANCHORING.md

@@ -0,0 +1,117 @@
+# Anchoring — policy and decision record
+
+**Status:** decided 2026-09-18 (v0 policy). Applies to `continuity-receipt/0.1`–`0.2`.
+**Scope:** the `anchors[]` bundle member and issuance practice; not a new protocol layer.
+
+## Decision
+
+Anchoring is **optional in the format and recommended in practice** when a
+consumer needs an independent timestamp:
+
+1. **OpenTimestamps (OTS) is the recommended default** issuance path. It is
+   free, requires no custody, publishes only a hash, and is verifiable with
+   open tooling. An OTS attestation proves the anchored digest existed no
+   later than the Bitcoin block in which it was included.
+2. **Public-chain anchoring is a supported peer type**, for counterparties
+   that require a chain-reachable identifier (SAIHM's reference deployment is
+   an example). The spec recommends no chain; the format stays
+   ledger-agnostic, and the anchor object carries whatever identifier the
+   counterparty's tooling needs.
+3. **`custom` is the escape hatch** for private ledgers and registries. A
+   consumer that cannot describe a custom anchor's verification MUST treat it
+   as opaque metadata, not evidence.
+4. **No mandatory anchoring.** A receipt verifies without anchors. A consumer
+   that requires an anchor states that explicitly (`--require-anchor` →
+   `PROVISIONAL` + `anchor_missing` when absent), so the requirement travels
+   with the verdict instead of being assumed.
+5. **Verification scope is frozen for 0.x:** this repository's verifier checks
+   anchor *shape and digest binding only* — `anchor.hash == receipt_digest(target)`
+   and the declared type. Proof verification (calendar response, Merkle path,
+   Bitcoin header) is delegated to the provider's tooling until a 0.3
+   companion tool lands. Until then, `type: opentimestamps` is a **claim** to
+   a verifier that has not checked the proof, not evidence.
+
+## What an anchor proves — and what it does not
+
+With a checked proof: the anchored digest existed no later than the anchor's
+timestamp, and it was not altered afterwards. Transitively, anchoring a
+chain's final receipt commits to every earlier receipt through the `prev`
+links, provided the chain itself verifies.
+
+It does **not** prove that statements inside the receipt are true. A
+timestamp is evidence of existence and ordering, not of honesty. Erasure and
+revocation semantics are separate (SPEC §6, §7) and are not affected by
+anchoring.
+
+## Options considered
+
+| | OpenTimestamps | Public chain (tx/OP_RETURN) | Defer until asked |
+|---|---|---|---|
+| Cost | free | gas/tx fee | none |
+| Custody | none | wallet + key custody | none |
+| Latency | minutes to hours (block cadence) | seconds to minutes | — |
+| Lock-in | none (federated calendars; Bitcoin anchors) | chain-specific tooling | none |
+| Privacy | hash only; no identity attached | address/value linkability common | — |
+| Dependency | calendar servers + Bitcoin headers | RPC/node/explorer | — |
+| Fit with non-goals | strong (no custody, no payments) | weaker (custody, fee rail) | no anchor evidence |
+
+Decision rationale: the format's non-goals exclude custody and payment rails,
+so the default issuance path must not require either. OTS gives independent
+timestamping at zero cost; chain anchoring remains available where a
+counterparty demands it, without the spec blessing a chain.
+
+## Issuance workflow (recommended)
+
+1. Freeze the bundle. Compute the target receipt's digest exactly as the
+   verifier does (canonical bytes excluding `sig`).
+2. Prefer the **chain tip** as the anchor target: one anchor per task chain
+   commits transitively to the earlier receipts and leaks less than anchoring
+   every receipt.
+3. `ots stamp <bundle-file>` (or the calendar API) and keep `<file>.ots`
+   beside the bundle. **Never mutate the bundle afterwards** — any change to
+   the anchored receipt invalidates the binding.
+4. After Bitcoin confirmation, `ots upgrade` the proof and verify it with
+   `ots verify`. Store the upgraded proof with the bundle.
+5. Record the anchor in the bundle:
+
+   ```json
+   "anchors": [
+     {
+       "target": "urn:uuid:<receipt_id>",
+       "hash": "sha256:<receipt_digest>",
+       "anchor": { "type": "opentimestamps", "value": "https://<calendar>/..." }
+     }
+   ]
+   ```
+
+6. For a counterparty requiring chain anchoring, same shape with
+   `"type": "public-chain"` and the chain-reachable identifier in `value`.
+
+## Failure and renewal guidance
+
+- **Calendar unavailability:** submit to more than one OTS calendar; any one
+  sufficient proof is enough to verify.
+- **Reorgs:** treat an anchor as settled only after the transaction has a
+  small confirmation depth; long-range reorgs are the residual risk.
+- **Long horizons:** keep the upgraded proof; re-upgrade against current
+  headers before archiving if the proof references headers a later verifier
+  may not have.
+- **Mutated bundles:** the digest binding fails (`anchor_invalid`); re-issue
+  under a new receipt, do not edit an anchored one.
+
+## Open items
+
+- **0.3 candidate:** OTS proof verification in the verifier or a companion
+  `continuity_receipt.anchor` tool, plus a documented renewal procedure.
+- Bundle-root anchoring (one anchor for many chains) is not expressible in
+  0.2; the schema binds anchors to receipts. Revisit if consumers need it.
+- No chain recommendation is deliberate; revisit only with deployment demand.
+
+## Interop note
+
+SAIHM (`draft-saihm-memory-protocol-01`) mandates public-chain anchoring per
+mutating operation and is chain-agnostic about the chain. Our `public-chain`
+anchor type is the mapping surface: `value` carries the chain-reachable
+identifier sufficient to reproduce the receipt independently, while the
+digest binding stays ours. See the mapping note offered to the W3C AI Agent
+Memory Interoperability CG.

continuity_receipt-0.2.0/CHANGELOG.md

@@ -0,0 +1,66 @@
+# Changelog
+
+## Unreleased
+
+- Packaging: `pyproject.toml` at 0.2.0 with console scripts
+  (`continuity-receipt-verify`, `continuity-receipt-disclose`), a full sdist
+  via `MANIFEST.in`, and a CI job that builds the wheel, installs it, and
+  exercises both console scripts. PyPI name `continuity-receipt` is available;
+  upload pending maintainer token.
+- `ANCHORING.md` — anchoring policy and decision record: OpenTimestamps as the
+  recommended default issuance path, `public-chain` supported for
+  counterparties that require it, `custom` as an opaque escape hatch;
+  verifier scope stays shape + digest binding only, proof verification
+  targeted for 0.3.
+
+## 0.2.0 — 2026-09-18
+
+Interoperability and robustness release; `0.1` remains supported.
+
+- **New record type** `authority.succession` (authority hand-off).
+- **Millisecond timestamps** (optional 1–3 fractional digits); second precision
+  still valid. Ordering within a chain remains by `seq`.
+- **Counterparty attestations** — signing rule defined (body with
+  `counterparty.attestation` removed) and verified per-signature; invalid
+  attestation → `bad_attestation`. Absence is reported, not penalized.
+- **Revocation statements** — bundle-level, self-signed by the revoked key;
+  receipts issued at or after `revoked_at` fail with `key_revoked`; earlier
+  receipts remain valid. Invalid statements fail closed (`bad_revocation`).
+- **Provenance roots** — `observed_sources_hash` accepts `merkle-sha256:`;
+  unsupported forms fail with `provenance_invalid`.
+- **Anchor typing** — anchor metadata `type` ∈ {`opentimestamps`,
+  `public-chain`, `custom`}; unknown types → `anchor_invalid`.
+- **JSON Schema** (`schema/continuity-receipt-0.2.schema.json`) validated
+  against every schema-valid vector in CI.
+- **CI** (GitHub Actions) + **machine-readable vector manifest**
+  (`vectors/manifest.json`) + CLI-surface verification of all vectors.
+- **THREAT_MODEL.md** (13 threat classes, including the open
+  pre-revocation-compromise gap) and **CONTRIBUTING.md** (DCO, no CLA).
+- Test set grows from 11 to 20 vectors; suite is 10 tests (vectors, schema,
+  primitives).
+
+Deferred to 0.3 with reasons in `SPEC.md` §11: CBOR equivalence, commitment
+HMAC/domain separation, revocation distribution, anchor proof verification,
+succession multi-signatures.
+
+## 0.1.0 — 2026-09-18
+
+Initial public release.
+
+- `continuity-receipt/0.1` specification, including pinned 0.1 decisions:
+  - JSON-only canonicalization (pinned RFC 8785-compatible subset; floats rejected);
+  - commitment scheme `sha256(salt_bytes || 0x7c || JCS(value))`, 16-byte per-field salt;
+  - redaction as an issuance-time act (chain tail re-signed);
+  - flat `observed_sources_hash` (Merkle roots deferred to 0.2).
+- Reference verifier (`continuity_receipt/`) with verdict semantics
+  `TRUSTED | PROVISIONAL | INSUFFICIENT_EVIDENCE | UNTRUSTED` and 13 error codes.
+- 11 test vectors (10 plus anchor sub-cases 10a/10b) with expected verdicts.
+- Vector generator (`tools/make_vectors.py`) for deterministic reproduction.
+- Conformance suite: `python3 -m unittest discover -s tests -v`.
+
+Source lineage: extracted from the MandalaOS gate-lite work, where the module passed
+gate acceptance G1–G8 and the wider project suite; this repository versions independently.
+
+Open items for 0.2 are listed in `SPEC.md` §11 (CBOR profile, Merkle source roots,
+HMAC/domain separation, required-field minimalism review with an underwriter,
+succession receipts).

continuity_receipt-0.2.0/CONTRIBUTING.md

@@ -0,0 +1,34 @@
+# Contributing
+
+## Ground rules
+
+1. **Small specification, testable changes.** A change to `SPEC.md` lands only with a vector, an acceptance test, or a documented negative case. If it cannot be tested, it is a discussion item, not a spec change.
+2. **Additive within 0.x.** Breaking changes require a new minor version and a new vector set (see `SPEC.md` §10).
+3. **Interop beats elegance.** When a choice exists, align with the neutral venues (W3C AI Agent Memory Interoperability CG; IETF agentproto) and with existing implementations.
+4. **Failures publish.** Rejected designs and known gaps are documented in `SPEC.md` §11 and `THREAT_MODEL.md`, not hidden.
+
+## How to contribute
+
+- **Issues first** for spec questions, field-mapping suggestions, or proposed vectors.
+- **Pull requests** must:
+  - add or update vectors and `vectors/manifest.json` via `tools/make_vectors.py` when behavior changes;
+  - keep `python3 -m unittest discover -s tests -v` green (vectors, schema, primitives);
+  - update `SPEC.md`, `CHANGELOG.md`, and `THREAT_MODEL.md` when semantics change.
+- **Developer Certificate of Origin (DCO).** Contributions are accepted under the DCO 1.1: sign off commits with `git commit -s` to certify you wrote the contribution or have the right to submit it. No separate CLA is required. (Decision recorded 2026-09-18; revisit only if the work moves to a foundation.)
+- **License.** By contributing you agree your contribution is licensed under Apache-2.0.
+
+## Running the suite
+
+```bash
+pip install 'cryptography>=42' jsonschema
+python3 tools/make_vectors.py            # regenerates vectors + manifest (non-deterministic ids/timestamps)
+python3 -m unittest discover -s tests -v # 20 vectors + schema + primitives
+```
+
+Note: regenerating vectors rewrites files with fresh random IDs and timestamps; that is expected (the generator is the source of truth for the set).
+
+## Scope guidance
+
+- Spec text, schema, vectors, and the reference verifier are in scope.
+- Gate/orchestrator machinery (the broader MandalaOS project) is out of scope here.
+- Interoperability discussion belongs in the open standards venues; this repository tracks concrete text, code, and vectors.

continuity_receipt-0.2.0/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

continuity_receipt-0.2.0/MANIFEST.in

@@ -0,0 +1,13 @@
+include LICENSE
+include README.md
+include SPEC.md
+include ANCHORING.md
+include CHANGELOG.md
+include ROADMAP.md
+include THREAT_MODEL.md
+include CONTRIBUTING.md
+include SIGNING.md
+recursive-include schema *.json
+recursive-include vectors *.json *.md
+recursive-include tools *.py
+recursive-include tests *.py

continuity_receipt-0.2.0/PKG-INFO

@@ -0,0 +1,100 @@
+Metadata-Version: 2.4
+Name: continuity-receipt
+Version: 0.2.0
+Summary: Continuity Receipt — open specification, test vectors, and reference verifier for verifiable records of governed AI-agent tasks
+Author: Lucas Bailey
+License-Expression: Apache-2.0
+Project-URL: Homepage, https://github.com/lbailey94/continuity-receipt
+Project-URL: Repository, https://github.com/lbailey94/continuity-receipt
+Project-URL: Issues, https://github.com/lbailey94/continuity-receipt/issues
+Project-URL: Specification, https://github.com/lbailey94/continuity-receipt/blob/main/SPEC.md
+Keywords: agent-memory,provenance,verification,receipts,interoperability,ed25519
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Security :: Cryptography
+Classifier: Topic :: Software Development :: Libraries
+Requires-Python: >=3.11
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: cryptography>=42
+Dynamic: license-file
+
+# Continuity Receipt
+
+**An open specification, test vectors, and reference verifier for verifiable records of governed AI-agent tasks.**
+
+**Spec version:** `continuity-receipt/0.2` — published 2026-09-18 (`0.1` remains supported; open items listed in `SPEC.md` §11).
+**License:** Apache-2.0 (specification text, code, and vectors).
+
+A Continuity Receipt is a signed, hash-chained record of one governed task:
+**decision → authority → execution → delivery → termination → settlement**. It is designed to be verified offline by any third party — insurers, arbiters, procurement, courts, other agents — **without requiring trust in the issuer**.
+
+The spec is intentionally small: JSON (RFC 8785 canonicalization), SHA-256, Ed25519, `did:key` identities. No new cryptography. Redaction uses salted commitments so fields can be revealed selectively without breaking integrity; erasure makes commitments opaque while the chain still verifies.
+
+## Why this exists
+
+Agents are accumulating persistent memory and doing delegated work at scale, but accountability is still self-reported. This document is the opposite: claims arrive with evidence, missing evidence is distinguished from false evidence, and "proof it stopped" (`task.termination`) is required for a task to verify as complete.
+
+Verification verdicts (IETF CTQ-aligned):
+`TRUSTED` · `PROVISIONAL` · `INSUFFICIENT_EVIDENCE` · `UNTRUSTED`.
+`INSUFFICIENT_EVIDENCE` is explicitly not the same as false.
+
+## Layout
+
+```
+SPEC.md                    the v0.2 specification (normative; 0.1 supported)
+schema/                    JSON Schema (2020-12) for 0.1 + 0.2 bundles
+THREAT_MODEL.md            what receipts prove, and what they do not
+ANCHORING.md               anchoring policy: OpenTimestamps default, chain optional
+CONTRIBUTING.md            DCO, test rules, scope
+ROADMAP.md                 what lands in 0.3 and beyond, and the selection rule
+continuity_receipt/        reference implementation (Python, cryptography>=42)
+vectors/                   20 test vectors + INDEX.md + manifest.json
+tools/make_vectors.py      regenerates the vectors deterministically
+tests/                     conformance suite (vectors, schema, primitives)
+```
+
+## Quickstart
+
+```bash
+python3 -m venv .venv && . .venv/bin/activate
+pip install 'cryptography>=42'
+
+# verify a vector (TRUSTED / PROVISIONAL / INSUFFICIENT_EVIDENCE / UNTRUSTED)
+python3 -m continuity_receipt.verify vectors/02_happy_full.json
+
+# vectors that require an anchor policy
+python3 -m continuity_receipt.verify vectors/10b_anchor_missing.json --require-anchor
+
+# run the conformance suite (11/11 expected)
+python3 -m unittest discover -s tests -v
+```
+
+## Test vectors
+
+20 vectors with machine-readable expectations in `vectors/manifest.json`
+(human index: `vectors/INDEX.md`): 0.1 conformance (`01`–`10c`) plus 0.2
+additions — succession records, millisecond timestamps, counterparty
+attestations, revocation semantics, Merkle provenance, and anchor typing.
+Every schema-valid vector is also checked against
+`schema/continuity-receipt-0.2.schema.json` in CI.
+
+## Status and provenance
+
+- **Origin:** developed in the MandalaOS gate-lite work, where it passed acceptance G1–G8 and the wider project suite (49 tests, dogfood evidence). This repository is the format's public home; it versions independently of any product release train.
+- **Releases:** `0.1` (2026-09-18) — spec, reference verifier, 11 vectors. `0.2` (2026-09-18) — `authority.succession`, bundle-level revocation statements, counterparty attestation rules, millisecond timestamps, `merkle-sha256:` provenance, anchor typing, JSON Schema, CI, machine-readable vector manifest.
+- **Origin implementation:** [WhiteMagic](https://github.com/lbailey94/whitemagic) — an MIT, local-first memory substrate for agents (this spec repo is Apache-2.0; the two are separate works).
+- **Standards context:** the format is intended as a contribution to the emerging neutral layer (W3C AI Agent Memory Interoperability CG; IETF agentproto work). It is not endorsed by those bodies, and no claim of adoption is made.
+
+## Development disclosure
+
+This project is developed with AI agents as drafting, implementation, and review collaborators, under the direction and accountability of the human maintainer. Every artifact published here — spec text, code, vectors — is reviewed and signed off by the human maintainer, who is responsible for its claims. We disclose this proactively because verifiability is the project's subject as well as its method.
+
+## Contributing
+
+Open an issue for spec questions, mapping suggestions, or implementation feedback. Interoperability discussion belongs in the open standards venues; this repository tracks concrete text and vectors.
+
+## License
+
+Apache License 2.0 — see `LICENSE`. The specification is published for royalty-free implementation. Test keys in the vectors are deterministic and public; **never use them for real receipts**.

continuity_receipt-0.2.0/README.md

@@ -0,0 +1,78 @@
+# Continuity Receipt
+
+**An open specification, test vectors, and reference verifier for verifiable records of governed AI-agent tasks.**
+
+**Spec version:** `continuity-receipt/0.2` — published 2026-09-18 (`0.1` remains supported; open items listed in `SPEC.md` §11).
+**License:** Apache-2.0 (specification text, code, and vectors).
+
+A Continuity Receipt is a signed, hash-chained record of one governed task:
+**decision → authority → execution → delivery → termination → settlement**. It is designed to be verified offline by any third party — insurers, arbiters, procurement, courts, other agents — **without requiring trust in the issuer**.
+
+The spec is intentionally small: JSON (RFC 8785 canonicalization), SHA-256, Ed25519, `did:key` identities. No new cryptography. Redaction uses salted commitments so fields can be revealed selectively without breaking integrity; erasure makes commitments opaque while the chain still verifies.
+
+## Why this exists
+
+Agents are accumulating persistent memory and doing delegated work at scale, but accountability is still self-reported. This document is the opposite: claims arrive with evidence, missing evidence is distinguished from false evidence, and "proof it stopped" (`task.termination`) is required for a task to verify as complete.
+
+Verification verdicts (IETF CTQ-aligned):
+`TRUSTED` · `PROVISIONAL` · `INSUFFICIENT_EVIDENCE` · `UNTRUSTED`.
+`INSUFFICIENT_EVIDENCE` is explicitly not the same as false.
+
+## Layout
+
+```
+SPEC.md                    the v0.2 specification (normative; 0.1 supported)
+schema/                    JSON Schema (2020-12) for 0.1 + 0.2 bundles
+THREAT_MODEL.md            what receipts prove, and what they do not
+ANCHORING.md               anchoring policy: OpenTimestamps default, chain optional
+CONTRIBUTING.md            DCO, test rules, scope
+ROADMAP.md                 what lands in 0.3 and beyond, and the selection rule
+continuity_receipt/        reference implementation (Python, cryptography>=42)
+vectors/                   20 test vectors + INDEX.md + manifest.json
+tools/make_vectors.py      regenerates the vectors deterministically
+tests/                     conformance suite (vectors, schema, primitives)
+```
+
+## Quickstart
+
+```bash
+python3 -m venv .venv && . .venv/bin/activate
+pip install 'cryptography>=42'
+
+# verify a vector (TRUSTED / PROVISIONAL / INSUFFICIENT_EVIDENCE / UNTRUSTED)
+python3 -m continuity_receipt.verify vectors/02_happy_full.json
+
+# vectors that require an anchor policy
+python3 -m continuity_receipt.verify vectors/10b_anchor_missing.json --require-anchor
+
+# run the conformance suite (11/11 expected)
+python3 -m unittest discover -s tests -v
+```
+
+## Test vectors
+
+20 vectors with machine-readable expectations in `vectors/manifest.json`
+(human index: `vectors/INDEX.md`): 0.1 conformance (`01`–`10c`) plus 0.2
+additions — succession records, millisecond timestamps, counterparty
+attestations, revocation semantics, Merkle provenance, and anchor typing.
+Every schema-valid vector is also checked against
+`schema/continuity-receipt-0.2.schema.json` in CI.
+
+## Status and provenance
+
+- **Origin:** developed in the MandalaOS gate-lite work, where it passed acceptance G1–G8 and the wider project suite (49 tests, dogfood evidence). This repository is the format's public home; it versions independently of any product release train.
+- **Releases:** `0.1` (2026-09-18) — spec, reference verifier, 11 vectors. `0.2` (2026-09-18) — `authority.succession`, bundle-level revocation statements, counterparty attestation rules, millisecond timestamps, `merkle-sha256:` provenance, anchor typing, JSON Schema, CI, machine-readable vector manifest.
+- **Origin implementation:** [WhiteMagic](https://github.com/lbailey94/whitemagic) — an MIT, local-first memory substrate for agents (this spec repo is Apache-2.0; the two are separate works).
+- **Standards context:** the format is intended as a contribution to the emerging neutral layer (W3C AI Agent Memory Interoperability CG; IETF agentproto work). It is not endorsed by those bodies, and no claim of adoption is made.
+
+## Development disclosure
+
+This project is developed with AI agents as drafting, implementation, and review collaborators, under the direction and accountability of the human maintainer. Every artifact published here — spec text, code, vectors — is reviewed and signed off by the human maintainer, who is responsible for its claims. We disclose this proactively because verifiability is the project's subject as well as its method.
+
+## Contributing
+
+Open an issue for spec questions, mapping suggestions, or implementation feedback. Interoperability discussion belongs in the open standards venues; this repository tracks concrete text and vectors.
+
+## License
+
+Apache License 2.0 — see `LICENSE`. The specification is published for royalty-free implementation. Test keys in the vectors are deterministic and public; **never use them for real receipts**.