How-To · Cluster 20 · OpenChainGraph v0.4

Agreement Acceptance Receipt Flow

An agent that needs to close a mutual NDA with court-checkable artifacts composes two already-shipped nodes: assemble the agreement from Cover Page Key Terms, then have each party bind their acceptance to the exact assembled artifact by hash. No new node type — this page documents the composition, the receipt trio it produces, and where real signing happens.

Composition, not a new kernel ART-276 → ART-277 → ART-277 previous_proof_hash chain Zero PII
EDUCATIONAL: the assembled agreement and acceptance receipts are drafts and stated-acceptance records, not executed contracts or legal conformity certificates. Real party identity, signatures, and legal effect stay off-platform. Consult a licensed attorney for your jurisdiction.

The flow, step by step

Three artifacts, each hash-referencing the one before it — never re-embedding party identity or the agreement text.
1
Assemble the MNDA from Cover Page Key Terms
Call assemble_mutual_nda with purpose, effective date, term settings, governing law, and jurisdiction. The Standard Terms body is vendored verbatim (Common Paper Mutual NDA v1.0, CC BY 4.0) and never touched by this step. No party identity is passed in. Output: an artifact with an execution_hash and a contract_api variable-map twin.
assemble_mutual_nda → ART-276
2
Party A binds acceptance to the exact artifact
Call bind_agreement_acceptance with referenced_execution_hash, template_id, and body_sha256 copied from Step 1's output, plus accepting_party_role: "party_a". No prior acceptance exists yet, so previous_proof_hash stays empty. The receipt references the agreement by hash — it never re-embeds the text.
bind_agreement_acceptance → ART-277
3
Party B binds acceptance, chained to Party A's
Call bind_agreement_acceptance again with the same referenced_execution_hash/template_id/body_sha256, accepting_party_role: "party_b", and previous_proof_hash set to Party A's acceptance execution_hash. This is the proof-chain hook: the resulting artifact carries the PROOF_CHAIN_REFERENCED compliance flag and links both parties' acceptances into one verifiable sequence.
bind_agreement_acceptance → ART-277

Chain topology

accept-api composed flow (3 artifacts, not a registered chain — a documented composition) ART-276 (assemble_mutual_nda) → ART-277 (bind_agreement_acceptance, party_a) [referenced_execution_hash = ART-276.execution_hash] → ART-277 (bind_agreement_acceptance, party_b) [previous_proof_hash = party_a.execution_hash]
Where real signing happens: each of the three artifacts can optionally carry a §16 eddsa-jcs-2022 Proof Binding, turning a stated acceptance into a countersignable receipt. Real party identity and e-signature collection happen off-platform at anchor.ainumbers.co/sign (Anchorproof) — never at a retired browser.ainumbers.co link.

Worked example

Minimal policy_parameters for each call, in sequence. See ART-276 and ART-277 for the full parameter and output_payload schemas.
1. assemble_mutual_nda({
  purpose: "Evaluating a potential commercial integration",
  effective_date: "2026-07-10",
  mnda_term_mode: "expires_after_period", mnda_term_years: 2,
  confidentiality_term_mode: "fixed_period", confidentiality_term_years: 5,
  governing_law: "Delaware", jurisdiction: "Delaware"
}) → { execution_hash: H0, output_payload: { template_id, body_sha256, ... } }

2. bind_agreement_acceptance({
  referenced_execution_hash: H0, template_id, body_sha256,
  accepting_party_role: "party_a"
}) → { execution_hash: H1, output_payload: { previous_proof_hash: null, ... } }

3. bind_agreement_acceptance({
  referenced_execution_hash: H0, template_id, body_sha256,
  accepting_party_role: "party_b", previous_proof_hash: H1
}) → { execution_hash: H2, output_payload: { previous_proof_hash: H1, ... }, compliance_flags: [..., "PROOF_CHAIN_REFERENCED"] }

Related

Not a new node: this page documents an SDK-level composition of two live nodes. It mints no new kernel, no new mcp_name, and makes no chaingraph.json change.
Zero-PII: neither node accepts party identity, signatures, or notice addresses. Those stay literal placeholder tokens for your own off-platform e-sign flow.
OpenChainGraph v0.4 · © 2024–2026 Post Oak Labs · Suite · Spec v0.8.7 · Zero PII · CC BY 4.0