Generic Workflow: Separate-Mode Marriage Agreement

Non-normative walkthrough mapping the logical formation journey onto Anklet operations, in the style of the ODR track's Generic-ODR-workflow.md. Personas: P1 (initiating party, India) and P2 (invited party, USA); a professional reviewer; a verification provider. Each step names the example pair in this directory.

Phase 1 — Matter creation and joining

1. P1's Consumer Application opens the Matter: create_matter (separate-mode-cross-border). Context carries the jurisdiction object with both party jurisdictions; state becomes initiated.
2. P1 invites P2: invite_party (second-party). The PP returns an invitation reference; the bearer token travels out of band and is stored only hashed. State: awaiting_party.
3. P2 redeems the invitation from their own CA: join_matter (invitation-redeemed). Pre-join, P2 saw only the privacy-safe public context. State: party_in_progress.

Phase 2 — Private capture and selective disclosure

4. Each party captures sections privately: update_section (financial-disclosure-private-capture). Content travels by reference; disclosure state is captured — structurally invisible to the other party.
5. Sharing is an explicit consent act: share_section (financial-disclosure). The PP records the act as an audited event before projecting content into the shared space.
6. A party may reverse a pending disclosure: withdraw_section (ceremony-expenses); history is retained.
7. When done, each party declares completion: submit_participation (party-two-complete), locking their sections.

Phase 3 — Gates, reconciliation, drafting, review

8. Any participant may ask where things stand: request_status (blocked-on-disclosure-and-reconciliation) — the PP answers with lifecycle state plus typed Blocking Reasons and operation-level action hints (never application routes).
9. With gates green, a draft is requested: request_instrument (first-draft). The callback carries the content-addressed Instrument Version, evaluation status (fail-loud if evaluation did not run), and the coverage audit.
10. Professional review: request_review (professional-review-risk-flag) assigns a reviewer; record_review (approved-with-privileged-notes) records the outcome — note the privileged confidentiality class on the exchange and the privileged notes traveling only as a reference.

Phase 4 — Verification and execution

11. Identity proofing for each signer: verify (identity-proofing-party-two). The callback shows the normalized outcome — including the cross-party uniqueness check — and refetched_from_provider: true, reflecting the callbacks-are-hints rule (core §11.4).
12. Execution: execute (seal-and-sign), carried under the sealed class. The callback returns the Evidence Seal manifest (instrument hash, disclosure ledger hash, process-record head) and pending signature ceremonies for both parties. Signer identity must join to the proofing outcome before completion.

Phase 5 — After execution

13. Changes happen only as linked successors: amend (successor-agreement).
14. Process grievances: escalate (process-grievance) — with an offered handoff to PULSE ODR for independent resolution.
15. Mutual wrap-up: close (mutual-acknowledgment) returns the vault export reference and the final process-record hash.

Reading the corpus

Every file pairs <op>-request-<scenario>.json with on_<op>-callback-<scenario>.json. All exchanges share one transaction_id (the Matter). Bodies never embed documents or secrets — only record:, blob:, and sha256: references per core §5.3.