docs: OM World Execution Proof composability + canonical step-hash JSON examples

[flyoung588]

Per #1 — the draft PR for the step-hash definition you offered to review.

OM World's per-step Execution Proof composes with proof-spec and Compliance Receipts v0.1 via the chained prev_hash mechanism (previous_receipt_hash ≡ prev_hash, step.timestamp maps directly). This PR captures the mapping and pins the canonical step-hash JSON shape against the edge case you flagged.

What's in the PR

New file: OM-WORLD-COMPOSABILITY.md

• Step record field mapping — proof-spec / CR v0.1 ↔ OM World Step record, line by line, including what has no proof-spec equivalent (tool_id, context_hash, attestation) and where signing happens (OM World signs at the envelope level, not per step).
• Canonical step hash formula — step_hash = SHA-256(JCS(step_record_without_prev_hash)) against RFC 8785, with prev_hash excluded from its own step's hash input.
• Absent-optional-fields rule — the rule you named in Design question: extending the chain hash format for multi-step agent execution #1: missing optional fields (context_hash, attestation) MUST be omitted from the JCS input, never serialized as null. JCS is deterministic; the disagreement is upstream at JSON-object construction.
• Three worked examples — the part you asked to review:
  1. Stateless tool — context_hash absent (omitted from JCS).
  2. Stateful tool — context_hash present with a snapshot hash.
  3. Anti-pattern — "context_hash": null (NOT conformant). All three use the same tool_id, input_hash, output_hash, and timestamp, so the only variable is the context_hash treatment — making the divergent-hash failure mode concrete.
• plan_hash pre-commitment — first step's prev_hash anchors to the mandate's plan_hash (intent-record value set before execution begins, not agent-computed at proof time). Closes the post-hoc plan-swap attack.

README.md — short subsection under §Composability linking to the new doc. The existing proof-spec ↔ CR v0.1 table is left untouched.

What this PR does not change

• No change to SPEC.md, test-vectors.json, or check_consistency.py. Proof-spec's conformance surface is unchanged.
• No claim that OM World is a proof-spec implementation. The doc is composability reference material, not a conformance profile.

Cross-reference on OM World's side

The three points are already adopted in execution-proof.md (commit 303bcb0). The composability mapping carried here is the same one cited in OM World's §Related work.

Happy to adjust wording, table format, or example shape — the field list and the three context_hash cases are the things to look at first.

— @flyoung588 (for OM World)

🤖 Generated with Claude Code