draft-anklet-marriage-00 — Applicability Profile: Marriage 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-marriage-00

Status of This Memo

This document is an Anklet Protocol Working Group Draft. It profiles draft-anklet-core for the formation of marriage agreements. It is a work in progress and MUST NOT be cited as a stable standard.

Abstract

This profile binds the Anklet core protocol to the formation of marriage agreements (prenuptial and analogous instruments) between two parties, including cross-border couples. It fixes the Party model, enumerates the Section catalog and its disclosure and reconciliation obligations, defines profile-specific gates (financial disclosure, safety holds, customary-payment schedules, restricted-clause review), sets verification requirements for execution, and states cross-border formation requirements. It deliberately does not specify the substantive marriage law of any jurisdiction; jurisdictional annexes carry those bindings.

1. Introduction

Marriage agreements are the adversarial-cooperation case the core protocol was designed around: two people who intend to cooperate for life but whose interests at formation are legally adverse, whose bargaining power may be asymmetric, and whose agreement will be scrutinized — possibly decades later — for voluntariness, full disclosure, independent advice, and procedural fairness. Enforcement outcomes turn on the process; this profile therefore standardizes the process signals, not clause content.

2. Conventions

BCP 14 [RFC2119] [RFC8174] language as in the core specification. "Core" refers to draft-anklet-core. All core requirements apply unless explicitly profiled here.

3. Party Model

• Exactly two Parties: party_1 (Initiating) and party_2 (invited via the core capability-invitation mechanism).
• Both joint and separate filling modes MAY be offered; separate is RECOMMENDED as default where either Party indicates asymmetric circumstances.
• Additional humans participate as non-Party actors: professional reviewers (per-Party counsel MUST be distinguishable from joint process counsel), witnesses, notarial officers. Their acts enter the process record with actor role.

4. Section Catalog

A conforming implementation MUST support the following Section classes. (Names are protocol identifiers; display language is unconstrained.)

Per-Party Sections exist as an owned instance per Party; the reconciliation gate (core §9.2) applies to each reconciled class.

5. Lifecycle Profile

The core state machine applies unmodified, with these bindings:

1. The completeness gate REQUIRES, at minimum: purpose, jurisdiction_context, financial_disclosure (both Parties), and counsel (both Parties).
2. The disclosure gate REQUIRES financial_disclosure and customary_payments (where applicable) to be in state shared by both Parties before instrument_ready.
3. review_required MUST be entered when any hold-severity risk flag (Section 6) is raised.
4. Post-execution amend SHOULD be supported as a linked successor Agreement; in-place mutation of an executed instrument MUST NOT occur.

6. Risk and Review Gates

6.1 Clause Risk Tones

Implementations MUST classify offered clauses with a risk tone:

• clear — freely selectable;
• review — selectable only with professional review or the selecting Party's recorded informed acknowledgment;
• hold — MUST NOT be auto-drafted; requires professional review and MAY be prohibited by jurisdictional annex (typical members: predetermination of child custody/support; waivers of non-waivable statutory rights).

Tone enforcement is a gate obligation (server-side), not an interface convention.

6.2 Safety Holds

A safety-class signal indicating coercion, violence, or incapacity MUST place the Matter in review_required with a safety_hold Blocking Reason visible only to the reporting Party and process counsel — the other Party MUST observe only generic progress states (core §14, side-channel requirement).

6.3 Customary Payments

Where the Parties record customary marriage payments or gifts, the implementation MUST require an itemized schedule (giver, recipient, description, value, voluntariness attestation) before the disclosure gate passes, and the schedule MUST be annexed to the instrument. Jurisdictional annexes state where such payments are unlawful and the corresponding declarations required.

7. Instrument Requirements

1. The following MUST be rendered deterministically from structured data (core §13.4): parties and verified identities; effective date and condition on solemnization; representations of disclosure, voluntariness, independent advice, and preservation of non-waivable rights; property-regime declaration; governing law and severability; execution formalities.
2. A Statement of Assets and Liabilities per Party MUST be annexed, derived from the reconciled financial_disclosure record.
3. Narrative clauses MUST cite the recorded facts they rely on; citations MUST resolve only to evidence that remains active in the record.
4. The Process Record annexure (core §12.1) MUST be included, covering at minimum: when each Party joined, disclosure acts, advice status, reconciliation dispositions, and the seal event.

8. Verification Profile

• Identity proofing (REQUIRED) for both Parties before awaiting_signature; cross-Party uniqueness check (core §11.3) REQUIRED — one person MUST NOT complete proofing for both Party slots.
• Execution signature (REQUIRED): a signature mechanism with statutory recognition in the governing jurisdiction, bound to the sealed Instrument Version hash; the signer-to-proofed-Party name join (core §11.3) is REQUIRED for each Party.
• Attested claims (OPTIONAL, RECOMMENDED for financial disclosure): income/asset corroboration SHOULD use privacy-preserving attestation (bands or thresholds rather than raw statements) per core §11.1(3) and §15.
• Stamp, notarization, witness, and registration formalities are jurisdictional-annex matter; where required they enter the execution checklist gate.

9. Cross-Border Formation

Where Parties reside or hold assets in different jurisdictions:

1. jurisdiction_context MUST record each Party's jurisdiction and the elected governing law; the instrument MUST address the non-elected jurisdiction's recognition posture explicitly rather than by silence.
2. Immigration-linked commitments (e.g., visa cooperation) MUST be drawn from both Parties' immigration Sections, not one Party's account of the other.
3. Remote execution (signing from abroad, consular or notarial formalities) MUST be reflected in the execution checklist, and time-zone-separated Parties MUST each receive the full pre- signature disclosure set in their own session.
4. This profile is jurisdiction-pair-agnostic: no country pair or visa category is normative.

10. Security Considerations

All core considerations apply. Profile-specific: the adversary model includes an abusive or coercive co-party with legitimate protocol access; every profile mechanism (safety class, disclosure privacy, side-channel constraints, cross-Party uniqueness at proofing) MUST be evaluated against that adversary. Implementations MUST NOT allow the invitation flow, reminders, or receipts to become a harassment channel (rate limits; reporting; unilateral exit that preserves the exiting Party's data rights).

11. Privacy Considerations

Core §15 applies. Additionally: marriage formation data is category-sensitive in most privacy regimes (financial, familial, potentially religious and health-adjacent). Retention after cancelled/expired SHOULD default to deletion; retention after executed follows the evidentiary needs of the instrument. Safety-class content MUST be excluded from any analytics, model training, or telemetry.

12. Conformance

An implementation conforms to this profile if it (a) conforms to core, (b) implements the Section catalog of Section 4 with the stated disclosure/reconciliation obligations, (c) enforces the gates of Sections 5–6 server-side, (d) meets the instrument requirements of Section 7, and (e) meets the verification profile of Section 8. A published conformance corpus (example message exchanges per lifecycle phase) accompanies this profile in examples/.

13. References

Normative: draft-anklet-core-00; [RFC2119]; [RFC8174]. Informative: [PULSE] v0.1.1; jurisdictional annexes (to be published as separate documents, first annex: India).