draft-anklet-core-00 — The Anklet Protocol: Online Formation of Legal Agreements

Anklet Protocol Working Group                                A. Anklet
Internet-Draft                                        ankletio/PULSE-WG
Intended status: Standards Track                           19 July 2026
Expires: 19 January 2027

draft-anklet-core-00

Status of This Memo

This document is an Anklet Protocol Working Group Draft. It extends the Protocol for Unified Legal Services (PULSE), a Beckn protocol adaptation, with Anklet, an Agreement Formation track for the online formation of multi-party legal agreements. It is a work in progress and MUST NOT be cited as a stable standard. Distribution of this memo is unlimited.

Discussion of this document takes place at https://github.com/ankletio/Anklet-Improvement-Proposals.

Abstract

This document specifies Anklet, an open, transport-agnostic protocol for forming legally significant agreements between two or more parties over a network. It defines the participant roles, the message envelope, the agreement lifecycle state machine, a selective disclosure model for adverse parties who share a single matter, a verification framework for identity proofing, execution signatures, and attested claims, provenance and transparency requirements, and normative constraints on Artificial Intelligence (AI) participants. The protocol is designed so that no single network operator holds all matter data, every state transition is auditable, and confidentiality obligations — including legal professional privilege and party safety information — are enforced at the protocol layer rather than by application convention. The formation of marriage agreements is the first applicability profile (see draft-anklet-marriage).

Table of Contents

1. Introduction
2. Conventions and Requirements Language
3. Terminology
4. Architecture
5. Message Model
6. Operations
7. Agreement Lifecycle
8. Multi-Party Participation
9. Selective Disclosure and Reconciliation
10. Confidentiality Classes
11. Verification Framework
12. Provenance, Evidence, and Transparency
13. AI Participants
14. Security Considerations
15. Privacy Considerations
16. Registry Considerations
17. References Appendix A. Mapping to Beckn / PULSE Transaction Verbs Appendix B. Relationship to Reference Implementations

1. Introduction

1.1 Motivation

Existing open-commerce protocols (Beckn and its adaptations, including PULSE for Online Dispute Resolution) standardize the discovery and ordering of services: a consumer finds a provider, agrees on a price, and tracks fulfillment. Agreement formation is a different problem. Two or more parties — who may be mutually adverse, in different jurisdictions, and represented by different counsel — must jointly produce a single legal instrument through a process whose fairness, voluntariness, and evidentiary integrity later determine whether the instrument survives challenge.

PULSE version 0.1.x explicitly scopes out legal services other than dispute resolution. Anklet fills part of that gap: it specifies the network protocol for the formation phase of a legal matter — intake, negotiation, disclosure, drafting, review, execution, and archival — while remaining composable with PULSE ODR flows for disputes that arise before or after execution.

The protocol takes its name from the Silappadikaram, the Tamil epic in which an anklet is the self-evident proof that exposes a miscarriage of justice. The design intent is the same: an agreement formed over this protocol carries, within itself, the evidence of the fairness of its own formation.

1.2 Design Goals

1. Protocol, not platform. Any conforming Consumer Application can work with any conforming Provider Platform. No participant is required to trust a central operator with matter content.
2. Adverse-party safety. Parties to one agreement are not presumed to trust each other. Party-private information is protocol-invisible to the other party unless explicitly shared.
3. Evidentiary integrity. The process that produced an instrument is recorded in a tamper-evident form suitable for later judicial scrutiny.
4. Verification pluralism. Identity proofing, execution signature, and claim attestation are abstract rails with interchangeable providers, not fixed vendors or national schemes.
5. AI accountability. AI systems may draft, summarize, and guide, but only under audience-scoped context isolation, recorded provenance, and human-controlled gates.
6. Jurisdiction awareness. Every transaction carries an explicit jurisdiction context; cross-border formation is a first-class case, not an afterthought.

1.3 Scope

In scope: agreement formation between identified parties, including solicitation of professional (lawyer) review, execution by electronic signature, and sealed archival.

Out of scope: dispute resolution (PULSE ODR), court filing and case management, payment processing (the protocol carries payment references, never payment instruments), and the substantive law of any jurisdiction. Substantive requirements belong in applicability profiles (Section 16.6).

2. Conventions and Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

JSON [RFC8259] is used for all message examples. Field names are case-sensitive. Durations use ISO 8601. Timestamps use RFC 3339 UTC.

3. Terminology

Agreement : The legal instrument being formed, together with its structured data, disclosure state, and process record. Identified by an Agreement Identifier scoped to one Matter.

Matter : The overall engagement within which one or more Agreements are formed. A Matter maps to one protocol transaction_id.

Party : A natural or juridical person who will be bound by the Agreement. Parties are enumerated as party_1 … party_n. A Party is not assumed to trust any other Party.

Initiating Party : The Party that opens the Matter and issues invitations.

Consumer Application (CA) : The application through which a Party participates. Distinct Parties MAY use distinct CAs.

Provider Platform (PP) : The platform that hosts the Agreement state and executes the formation process (drafting, gating, verification orchestration).

Professional Reviewer : A credentialed human (e.g., an advocate) who reviews an Agreement on behalf of a Party or of the process. Communications between a Professional Reviewer and their client are Privileged (Section 10).

Verification Provider (VP) : A service that performs identity proofing, execution signature ceremonies, or claim attestation, reachable through the Verification Framework (Section 11).

Registry : The network directory of participants, their roles, credentials, and public keys.

Transparency Log : A content-blind, append-only record of transaction metadata (Section 12.4).

Section : A named unit of structured Agreement data (e.g., a disclosure module). Sections are the unit of capture, sharing, and gating.

Audience : The set of principals for whom a piece of content is eligible: one Party, all Parties (shared), or counsel (Section 10, 13).

Gate : A server-side predicate that MUST hold before a lifecycle transition, reported as typed Blocking Reasons (Section 7.4).

Instrument Version : An immutable, content-addressed rendering of the Agreement text.

Evidence Seal : A hash manifest freezing the evidentiary state of a Matter prior to execution (Section 12.3).

4. Architecture

4.1 Participant Roles

 Party A ──── CA-A ──┐                       ┌── CA-B ──── Party B
                     │                       │
                     ▼                       ▼
              ┌──────────────────────────────────┐
              │        Provider Platform         │
              │  (agreement state, gates, draft) │
              └───┬──────────┬──────────┬────────┘
                  │          │          │
                  ▼          ▼          ▼
           Verification   Registry   Transparency
            Providers                    Log

A network deployment additionally includes a Gateway when discovery across multiple PPs is offered; discovery reuses the underlying Beckn/PULSE machinery (Appendix A) and is not respecified here.

4.2 Trust Model

• Parties trust their own CA and, to the extent of the published process, the PP. Parties do not trust each other.
• The PP is trusted to enforce gates, disclosure, and audience isolation; its honesty is checkable through the process record, hash-anchored Instrument Versions, and the Transparency Log — the design goal is "verify, then trust".
• Verification Providers are trusted only for their declared capability, and their assertions MUST be independently re-fetchable (Section 11.4).
• The Registry is the trust root for participant identity and keys.

4.3 Layering

Anklet is defined above the Beckn transport conventions (asynchronous request/callback, ACK/NACK, signed HTTP messages) but does not depend on them normatively. A binding to the Beckn transaction API is given in Appendix A; other bindings (e.g., DIDComm) MAY be defined.

5. Message Model

5.1 Envelope

Every Anklet message consists of a context object and a message object.

{
  "context": {
    "protocol": "anklet",
    "version": "0.1.0",
    "domain": "legal-agreements:0.1.0",
    "action": "share_section",
    "transaction_id": "d3f2…",
    "message_id": "9c41…",
    "timestamp": "2026-07-19T10:30:00Z",
    "ttl": "PT10M",
    "source":      { "id": "ca.example",  "role": "consumer_application" },
    "destination": { "id": "pp.example",  "role": "provider_platform" },
    "jurisdiction": { … },
    "confidentiality": { "class": "standard" },
    "consent": { … }
  },
  "message": { … }
}

Requirements:

• transaction_id identifies the Matter and MUST be stable across the Matter's life. message_id MUST be unique per message.
• Every state-changing request MUST carry an idempotency key (message.idempotency_key or the message_id by binding convention); a PP receiving a duplicate MUST return the original outcome and MUST NOT repeat side effects.
• jurisdiction is REQUIRED on Matter creation and on any message that changes governing-law-relevant data. Its schema: { "country", "subdivision", "forum", "applicable_law": [], "cross_border": { "enabled", "party_jurisdictions": {} } }.
• confidentiality.class MUST be one of the classes in Section 10 and governs how intermediaries may handle the message.
• consent carries a reference to a consent artifact (an identifier resolvable at the PP), never the artifact body.

5.2 Asynchronous Exchange

Operations are asynchronous. A request is acknowledged synchronously (ACK/NACK with a machine-readable Error on NACK); the substantive result arrives as a callback message whose action is the request action prefixed with on_ and whose transaction_id/message_id correlate to the request. A requester MUST treat an ACK as receipt, not success.

5.3 Content by Reference

Message bodies MUST NOT embed document bodies, media, or secrets. Content is carried as typed references:

• sha256:<hex> — content address of an immutable object;
• record:<opaque> — a PP-scoped record reference;
• blob:<opaque> — a retrievable object reference whose dereference is subject to authorization.

A recipient dereferences a reference through an authorized, short-lived retrieval channel granted out of band by the reference issuer. This keeps routing intermediaries content-blind and makes privilege enforcement a property of dereference authorization rather than message inspection.

6. Operations

Anklet defines the following abstract operations. Each has a paired on_<operation> callback. Bindings map these onto transport verbs (Appendix A).

A PP MUST reject (NACK with reason state_conflict) any operation not permitted in the current lifecycle state (Section 7).

7. Agreement Lifecycle

7.1 States

 initiated ──► awaiting_party ──► party_in_progress ─┐
     │                                               │
     └──────────► in_progress ◄──────────────────────┘
                      │
                      ▼
              information_complete ──► review_required
                      │                     │ (flag disposition
                      ▼                     ▼   only exit)
               instrument_ready ◄───────────┘
                      │
        ┌─────────────┼──────────────┐
        ▼             │              │
 professional_review  │              │
        │             │              │
        ▼             ▼              │
 professional_reviewed│              │
        └────────►  awaiting_signature   ══ SEALED PHASE ══
                      │
                      ▼
             ready_for_execution
                      │
                      ▼
                  executed
                      │
                      ▼ (optional, profile-gated)
                   amended / closed

  Any pre-sealed state ──► cancelled | expired

7.2 Transition Rules

1. States prior to awaiting_signature are reversible: a PP MAY reopen an earlier state, and every reopen MUST be recorded as an audited revision event with actor and reason.
2. From awaiting_signature onward the Matter is sealed: Section data, disclosure state, and Party composition MUST NOT change. The only exits are completion of execution, or an audited abort that returns the Matter to instrument_ready and voids the Evidence Seal.
3. review_required is entered when risk conditions are detected and MUST only be exited by explicit disposition of each triggering flag by an authorized actor.
4. Status is derived, not declared: a PP MUST compute state from recorded facts (sections, disclosures, gates, events) and MUST NOT accept a client instruction to set an arbitrary state.
5. executed is terminal for the instrument. Changes after executed occur only through amend, which opens a new Agreement linked to its predecessor.

7.3 Gates

A transition into instrument_ready, awaiting_signature, ready_for_execution, or executed MUST be guarded by a gate evaluated server-side. Profiles define which predicates apply; the core predicate classes are:

• participation: all invited Parties joined and submitted;
• completeness: all REQUIRED Sections complete for each Party;
• disclosure: all Sections whose profile marks them disclosable have been shared by their owning Party;
• reconciliation: no unresolved conflicts between Party accounts of the same facts;
• risk: no unresolved hold-severity risk flags;
• review: professional review obtained where required;
• verification: identity proofing complete for all signing Parties;
• execution: instrument version sealed, execution checklist complete.

7.4 Blocking Reasons

When a gate fails, the PP MUST report the failure as a list of typed Blocking Reasons:

{ "code": "disclosure_unshared",
  "message": "…",
  "section": "financial_disclosure",
  "party": "party_2",
  "action_hint": "share_section" }

The initial code registry (Section 16.2): missing_consent, safety_hold, party_pending, section_incomplete, disclosure_unshared, reconciliation_unresolved, risk_unresolved, professional_review_required, identity_unverified, instrument_version_missing, execution_checklist_incomplete. action_hint names a protocol operation, never an application route.

8. Multi-Party Participation

8.1 Invitations as Capabilities

An invitation is a bearer capability, not an account requirement:

• The invitation token MUST be unguessable (≥128 bits entropy), MUST be stored only in hashed form by the PP, MUST expire, and MUST be revocable by the Initiating Party.
• The token scopes the holder to exactly one Party slot and to the operations and Sections that profile allows that Party.
• Pre-join, an invitation resolves to a privacy-safe public context: enough for the invitee to decide to join (agreement type, inviter display name, jurisdiction) and nothing captured by any Party.

8.2 Participation State

Per Party: pending → joined → in_progress → submitted, with revoked and expired terminal. After submitted, a Party's Sections are locked; the Initiating Party MAY request a reopen (submitted → revision_open → submitted), which MUST be audited and MUST notify the affected Party. While any Instrument Version is pending or the Matter is sealed, Party mutation MUST be refused.

8.3 Filling Modes

Profiles MAY offer joint capture (Parties share one capture surface; inter-Party privacy is moot) and separate capture (each Party captures privately, then discloses per Section 9). Separate capture is the default assumption of this specification; its guarantees MUST NOT silently degrade when a deployment offers joint mode.

9. Selective Disclosure and Reconciliation

9.1 Disclosure State Machine

Each disclosable Section, for each Party, carries:

 captured (private) ──► shared ──► withdrawn ──► shared …

• captured: visible to the owning Party (and their counsel) only. MUST be structurally excluded from every cross-Party surface — reads, prompts, notifications, and logs available to the other Party.
• shared: a deliberate consent act by the owning Party. The PP MUST record the act (actor, timestamp, content revision) as an audit event, and only then project the content into the Matter's shared space.
• withdrawn: reverses projection for future use; content already lawfully relied upon (e.g., cited in a generated draft that was shown to the other Party) cannot be unshown, and the PP MUST retain the disclosure history.

Disclosure state MUST be locked in the sealed phase.

9.2 Reconciliation

Where both Parties independently answer the same substance, the PP MUST surface a reconciliation view of aligned and conflicting entries. Each conflict MUST receive an explicit disposition by an authorized actor before the reconciliation gate passes, and each disposition MUST be bound to the content revisions it reconciled (a later content change voids the disposition).

9.3 Safety Information

Profiles MAY designate Sections as safety class (Section 10): self-reported information (e.g., coercion or violence indicators) collected to protect a Party. Safety Sections MUST NOT be disclosable, MUST NOT enter reconciliation, MUST NOT appear in any shared or cross-Party output, and MUST be excluded from AI context for any audience other than the reporting Party (Section 13). Their existence MUST NOT be inferable by the other Party from protocol responses (no distinguishable errors, counts, or timing).

10. Confidentiality Classes

Every object and message carries exactly one class:

Class assignments are monotonic toward restriction: content derived from a classified source inherits at least that class. A PP MUST fail closed: content whose class cannot be determined is treated as restricted-safety.

11. Verification Framework

11.1 Rails

Three abstract verification rails are defined; profiles state which are REQUIRED:

1. Identity proofing — binding a Party slot to a proofed natural person (document + biometric or equivalent), producing a proofed name/date-of-birth and check results.
2. Execution signature — a legally recognized electronic signature ceremony over a specific Instrument Version, producing a signed artifact and signer evidence.
3. Attested claims — third-party attestation that a specific claim about a Party is corroborated (e.g., an income band or a government-credential attribute), preferably via privacy-preserving presentation (selective disclosure, zero-knowledge, or verifiable-credential mechanisms) rather than raw evidence hand-over.

11.2 Verification Outcome

Each rail yields a normalized outcome:

{ "rail": "identity_proofing",
  "status": "verified",
  "subject": "party_2",
  "assertions": { "name": "…", "birth_date": "…" },
  "checks": [ { "type": "liveness", "score": 0.98 } ],
  "evidence_refs": [ "sha256:…" ],
  "provider": { "id": "vp.example", "session_ref": "…" },
  "expires_at": "2026-10-19T00:00:00Z" }

status ∈ pending | awaiting_subject | in_review | verified | rejected | expired | cancelled. Scores MUST be normalized to [0, 1]. Provider-native payloads MAY be archived as evidence references but MUST NOT be required for interoperation.

11.3 Binding Requirements

• An execution signature is valid for the Matter only if the signer identity matches the Party's identity-proofing outcome under the profile's name-matching rules. "Someone signed" is not "the proofed Party signed"; the PP MUST enforce the join.
• For multi-Party matters, the PP MUST apply cross-Party uniqueness checks where the rail supports them (one person MUST NOT satisfy proofing for two Party slots).

11.4 Callbacks Are Hints

A VP callback (webhook or push) MUST be treated as a hint, never as a fact: on receipt, the PP MUST re-fetch the authoritative outcome from the VP over an authenticated channel before changing state, and MUST also poll as a fallback. Callback payloads MUST NOT mutate state directly.

12. Provenance, Evidence, and Transparency

12.1 Process Record

Every material act in a Matter — section writes, disclosure acts, reconciliation dispositions, gate evaluations that change state, review outcomes, verification outcomes, seal and execution events — MUST be recorded in an append-only, tamper-evident event log (e.g., digest-chained). The log MUST support export as a human-readable Process Record suitable for annexure to the instrument, demonstrating voluntariness and procedural fairness. Events referencing classified content MUST reference, not embed, it.

12.2 Instrument Versions

Every generated or professionally edited rendering of the Agreement text MUST be stored as an immutable Instrument Version identified by its content hash, with status draft | reviewed | ready_for_execution | executed | superseded. Execution binds signatures to exactly one version's hash.

12.3 Evidence Seal

Before execution, the PP MUST compute an Evidence Seal: a manifest of content hashes covering the executed Instrument Version, consent artifacts, disclosure ledger, verification outcomes, and the process record head. If any covered object changes after sealing, the seal is stale and execution MUST be re-blocked until re-sealed.

12.4 Transparency Log

Network deployments SHOULD operate a content-blind Transparency Log recording, per transaction: that an event of a given type occurred, when, between which registered participants, and the hash of any instrument involved — and nothing else. The log MUST be append-only and SHOULD be publicly auditable. It exists to make process misconduct (backdating, silent substitution, denial of service to one Party) detectable without exposing matter content.

13. AI Participants

AI systems (drafting, extraction, summarization, guidance, and evaluation components) are participants with obligations, not invisible tooling.

1. Disclosure. Use of AI in producing any output shown to a Party MUST be disclosed to that Party. Networks MAY require model/provider disclosure at the Registry.
2. Audience-scoped context isolation. Every AI invocation MUST carry an explicit Audience (party_n, shared, or counsel), and its input context MUST pass through a single enforcement point that excludes all content not eligible for that Audience (party-private captures, privileged, restricted-safety, bookkeeping/disclosure ledgers). Unknown or missing Audience MUST fail closed to the most restrictive shared view.
3. Egress control. Output destined for a broader audience than any excluded content SHOULD be scanned for verbatim reproduction of excluded values; a detected leak MUST be treated as an incident (blocked and reported), not silently redacted.
4. Determinism where enforceability lives. Text on which enforceability depends (definitions, execution formalities, statutory acknowledgments) SHOULD be produced deterministically from structured data; free generation SHOULD be confined to narrative content and audited against the record.
5. Groundedness. Generated instruments SHOULD cite the recorded facts and evidence they rely on, and a coverage audit SHOULD verify that every material recorded fact is either reflected or consciously omitted.
6. Quality gates. Before an AI-generated Instrument Version may reach instrument_ready, it SHOULD pass declared evaluation criteria; if evaluation did not run, the PP MUST say so rather than imply it passed.
7. Bounded authority. Autonomous AI execution MUST operate under an explicit, expiring, server-clamped capability grant enumerating permitted tools, records, and Audiences, and its actions MUST be recorded in the process record with the grant decision trail.
8. Untrusted recall. Content recalled from memory or prior context and re-injected into AI input MUST be framed as untrusted data, not instructions.

14. Security Considerations

• Message authenticity. All inter-participant messages MUST be integrity-protected and attributable to a Registry-listed key (transport binding defines the mechanism; the Beckn binding uses signed HTTP messages). Signature verification failures MUST NACK.
• Capability tokens (Section 8.1) are bearer secrets: transport only over confidential channels, store hashed, expire, revoke, and bind to single Party slots.
• Fail-closed defaults govern every classification, audience, and gate decision; ambiguity resolves to the more restrictive outcome.
• Sealed-phase invariants (Section 7.2) are the primary defense against last-minute substitution attacks; implementations MUST verify the Evidence Seal at signature time, not only at seal time.
• Cross-Party side channels. Error shapes, timing, counts, and push notifications MUST NOT reveal the existence or content of the other Party's private captures (notably safety class).
• Verification spoofing. The re-fetch rule (Section 11.4) and the identity/signature join (Section 11.3) close the two known classes of execution fraud: forged callbacks and signer-substitution.
• AI prompt injection. Sections 13.2 and 13.8 are the normative mitigations; implementations SHOULD additionally constrain AI tool authority via 13.7.

15. Privacy Considerations

• Data minimization. Attested claims SHOULD be collected as the narrowest sufficient assertion (a band, a threshold, a boolean) rather than raw source data.
• Erasure. A PP SHOULD support cryptographic erasure with per-subject key scoping, such that one person's data can be made permanently unreadable without affecting co-parties — subject to the retention the executed instrument itself requires.
• National identifiers MUST NOT be stored by the PP when the verification rail can operate on derived assertions.
• The Transparency Log is metadata-only by construction; deployments MUST resist scope creep toward content logging.
• Safety-class handling (Sections 9.3, 10) exists because the threat model includes an abusive co-party; reviewers evaluating changes to it should assume that adversary.

16. Registry Considerations

This specification establishes the following registries, initially populated as listed, with policy Specification Required (a published AIP at ankletio/Anklet-Improvement-Proposals):

1. Lifecycle States (Section 7.1).
2. Blocking Reason Codes (Section 7.4).
3. Confidentiality Classes (Section 10).
4. Verification Rails and Outcome Statuses (Section 11).
5. Process Event Types (Section 12.1).
6. Applicability Profiles — named profiles binding this core to an agreement type and jurisdictional requirements. Initial entry: marriage-agreement (draft-anklet-marriage).

17. References

17.1 Normative

• [RFC2119] Bradner, S., "Key words for use in RFCs", BCP 14.
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14.
• [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format".
• [PULSE] "Protocol for Unified Legal Services", v0.1.1, Beckn Open Community, 2023.
• [BECKN-CORE] "Beckn Protocol Specification", v1.1.0.

17.2 Informative

• [BECKN-006] "Signing Beckn APIs in HTTP", Draft 04.
• [VC-DATA-MODEL-2.0] W3C, "Verifiable Credentials Data Model 2.0".
• [ACCORD] Accord Project: Concerto, Cicero, Ergo.
• [CASE-UCO] "Cyber-investigation Analysis Standard Expression / Unified Cyber Ontology".
• [SALI-LMSS] SALI "Legal Matter Standard Specification".

Appendix A. Mapping to Beckn / PULSE Transaction Verbs

Non-normative. When bound to the Beckn transaction API, Anklet operations map as follows; legal-specific operations with no Beckn counterpart travel as update/on_update with an update_target of the operation name, pending upstream verbs.

Appendix B. Relationship to Reference Implementations

Non-normative. This specification was distilled from an operating implementation of online marriage-agreement formation. Conformance is defined solely by the normative sections of this document and the relevant profile; nothing in this specification requires any particular workflow engine, database, model provider, sandbox technology, or vendor. Implementation experience reports and change proposals are received as AIPs at https://github.com/ankletio/Anklet-Improvement-Proposals.