From 4adef85cee9122ce5b01180d5ef74277de17b5f4 Mon Sep 17 00:00:00 2001 From: iret77 <63622643+iret77@users.noreply.github.com> Date: Mon, 15 Jun 2026 16:37:03 +0000 Subject: [PATCH] release: promote spec to v0.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Drop the -draft suffix now that the June 2026 review wave (issues #4–#30, PRs #32–#43) and the Codex consistency follow-up (#44–#46) have landed and a grounded Codex re-review converged clean. Bumps the SPEC.md front matter, README badge + status line, the roadmap Phase-1 note, and the Appendix C heading from v0.3-draft to v0.3. Status remains 'Draft (Concept) — not a final standard'; only the version identity is finalized. anp_version was already 0.3. --- README.md | 4 ++-- SPEC.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 04d5558..0801ba6 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](./LICENSE) [![Status: Draft](https://img.shields.io/badge/status-draft%20concept-orange.svg)](#status) -[![Spec: v0.3-draft](https://img.shields.io/badge/spec-v0.3--draft-informational.svg)](./SPEC.md) +[![Spec: v0.3](https://img.shields.io/badge/spec-v0.3-informational.svg)](./SPEC.md) **An open, DLT-neutral trust layer for agent-to-agent agreements, notarization, and dispute resolution.** @@ -78,7 +78,7 @@ The spec is chain-agnostic. The **reference profile** targets **IOTA Rebased** ( ## Status -**v0.3-draft — Draft / Concept.** This is a design specification, stable enough to implement against, with unresolved questions explicitly marked ([§16 Open Questions](./SPEC.md#16-open-questions)). It is **not** a final standard. Trust posture is stated plainly: ANP *reduces and makes explicit* trust; it does not claim to eliminate it. +**v0.3 — Draft / Concept.** This is a design specification, stable enough to implement against, with unresolved questions explicitly marked ([§16 Open Questions](./SPEC.md#16-open-questions)). It is **not** a final standard. Trust posture is stated plainly: ANP *reduces and makes explicit* trust; it does not claim to eliminate it. Roadmap: concept (now) → proof-of-concept per pillar → spec v1.0 → community & ecosystem. See [§17](./SPEC.md#17-roadmap). diff --git a/SPEC.md b/SPEC.md index 3c04afe..ff2728c 100644 --- a/SPEC.md +++ b/SPEC.md @@ -2,7 +2,7 @@ ## An Open, DLT-Neutral Trust Layer for Agent-to-Agent Agreements, Notarization, and Dispute Resolution -*Concept Paper / Draft Specification — v0.3-draft (June 2026)* +*Concept Paper / Draft Specification — v0.3 (June 2026)* **Status:** Draft (Concept). This document is a design specification intended to be stable enough to implement against, while explicitly marking unresolved questions. It is not a final standard. @@ -916,7 +916,7 @@ Conformance levels: **Minimal** = Core + exactly one of {Notarization, Contracti ## 17. Roadmap -**Phase 1 — This document (now).** Publish the concept/draft spec (v0.2, May 2026; v0.3 draft under review); gather feedback; refine. +**Phase 1 — This document (now).** Publish the concept/draft spec (v0.2, May 2026; v0.3, June 2026); gather feedback; refine. **Phase 2 — Proof of Concept (per pillar).** - *Contracting:* two agents negotiate a structured service agreement; Objects anchored on IOTA testnet; mandate-gated approval; settlement via a completion `assert` backed by accepted criteria, then an uncontested `enforce`. @@ -966,7 +966,7 @@ Seller asserts "delivered, criteria met" → `ASSERTED`. Buyer files `dispute` w ### Appendix C: Change Log -#### Changes from v0.2 (v0.3 draft) +#### Changes from v0.2 (v0.3) - **Signature input & hash coverage defined (§6.1, §6.2, §6.3; review issue #4):** every Object now has two normative canonical forms — the **signing form** (envelope with `proof` removed; the signature input for every proof entry) and the **anchored form** (incl. the assembled `proof[]`; what `object_hash` commits to). All inter-Object hash references use the anchored hash; `proof[]` order is pinned to `signers[]` order; a detached-signature **co-signing flow** specifies how `memorandum` is assembled. This also resolves the v0.2 §7.2 ↔ §8.3 contradiction on single-object multi-signatures. - **Chain vs. attachment linkage (§6.1, §7.4, §8.3; review issue #5):** `accept`, `approve`, `witness`, `evidence`, and `revoke` are now **attachment Objects** that reference their target via an anchored hash in `body` (`accepts_hash`, `approves_hash`, `attestation_hash`, `dispute_hash`, `revokes`) and carry `previous_hash: null` — N-party `accept`s therefore no longer fork the linear chain. `sequence` is normatively defined (predecessor + 1 on the chain; the target's value for attachments); the ledger's anchor order is the ordering authority; an `accept` is valid iff its `accepts_hash` equals the head current at its anchoring time.