docs: RCE Profile v0.1 — replay-constrained episode normative schema by Haserjian · Pull Request #5 · Haserjian/assay-protocol

Haserjian · 2026-04-06T22:36:52Z

Summary

Adds RCE_PROFILE.md: normative profile defining Replay-Constrained Episodes as a companion to SPEC.md
Adds schemas/rce_episode_contract.schema.json: JSON Schema for the Episode Contract
Schema/docs only — no implementation code

What this defines

An RCE is a verifiable work unit whose correctness is defined by replay against recorded evidence. Episodes compile into existing Assay Proof Packs.

Identity model: three identities (episode_id, episode_spec_hash, pack_root_sha256) with explicit replay-normative view separating descriptive from identity-bearing fields.

ReplayScript v0: 4 opcodes (LOAD_INPUT, ASSERT_HASH, APPLY_TRANSFORM, EMIT_OUTPUT) in a typed DAG.

Receipt types: 4 CRS-conformant types (episode_open, episode_step, episode_close, replay_result).

Verdict semantics: MATCH/DIVERGE/INTEGRITY_FAIL mapped to existing receipt_integrity × claim_check axes (exit 0/1/2).

Deterministic verification: 4 mandatory phases in fixed order. Two conforming verifiers produce the same verdict.

Derived hash inventory: Every hash field has a normative derivation rule or explicit local-attestation classification.

Design lineage

5-pass tightening from ~/RCE_V0_NORMATIVE_SPEC.md:

Initial draft (identity, receipts, verdicts, boundaries)
Replay-normative view, ULID deconfliction, version strata, Tier B collapse
Step status model, failure propagation, verification order, DIVERGE policy
Environment identity narrowing, missing-artifact classification
Derived hash inventory (Appendix C)

Test plan

JSON Schema validates against golden-path Episode Contract fixture
Profile cross-referenced against CRS v0.1 receipt envelope fields
All derived hash derivation rules checked for field-name consistency with schema
No semantic expansion beyond normative spec

🤖 Generated with Claude Code

Adds the Replay-Constrained Episode (RCE) profile as a companion to SPEC.md, defining verifiable agent work units whose correctness is determined by replay against recorded evidence. Schema-only — no implementation code. New files: - RCE_PROFILE.md: normative profile (identity model, ReplayScript v0 opcodes, 4 receipt types, verdict semantics, deterministic verification order, derived hash inventory) - schemas/rce_episode_contract.schema.json: JSON Schema for Episode Contract Design lineage: 5-pass tightening from ~/RCE_V0_NORMATIVE_SPEC.md. Semantics preserved; presentation adapted to assay-protocol conventions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Copilot

Pull request overview

Adds a first-cut normative “Replay-Constrained Episode (RCE)” profile and a companion JSON Schema for the Episode Contract, defining replay identity, ReplayScript v0 structure, receipt types, and deterministic verification semantics.

Changes:

Introduces RCE_PROFILE.md defining RCE identity model, ReplayScript v0 opcodes, receipt types, and verifier phase ordering.
Adds schemas/rce_episode_contract.schema.json to validate Episode Contract envelopes and core replay-normative fields.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
`schemas/rce_episode_contract.schema.json`	New draft-07 JSON Schema for the Episode Contract (inputs, script, policy, environment).
`RCE_PROFILE.md`	New normative profile describing RCE semantics, hashes, receipts, and verification procedure.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-06T22:41:01Z

+        "opcode": {
+          "type": "string",
+          "enum": ["LOAD_INPUT", "ASSERT_HASH", "APPLY_TRANSFORM", "EMIT_OUTPUT"]
+        },
+        "params": {
+          "type": "object",
+          "description": "Opcode-specific parameters"
+        },
+        "depends_on": {


step.params is unconstrained and the schema does not enforce the opcode-specific required parameters described in §3.1 of RCE_PROFILE.md (e.g., LOAD_INPUT requires ref, ASSERT_HASH requires target and expected_hash, etc.). This means invalid Episode Contracts can still validate against the schema. Consider using draft-07 if/then conditionals (or oneOf) keyed on opcode to require and constrain the correct params shape per opcode.

Copilot · 2026-04-06T22:41:01Z

+          "type": "array",
+          "items": {
+            "type": "string"
+          },


depends_on permits duplicate step IDs because there is no uniqueItems: true. Duplicates would make dependency semantics and the corresponding input_hashes ordering ambiguous. Add uniqueItems: true (and optionally default: []) to prevent duplicates.

Suggested change

},

},

"uniqueItems": true,

"default": [],

Copilot · 2026-04-06T22:41:01Z

+          "description": "Step IDs this step depends on. Empty array for root steps."
+        },
+        "output_schema": {
+          "description": "Optional JSON Schema for step output validation"


output_schema is described as an optional JSON Schema, but it has no type (or $ref) so any JSON value will validate (string/array/etc.). Consider constraining it to a JSON Schema shape (e.g., type: ["object", "boolean"] for draft-07) and documenting whether it must be a schema object vs a boolean schema.

Suggested change

"description": "Optional JSON Schema for step output validation"

"type": ["object", "boolean"],

"description": "Optional JSON Schema for step output validation. Must be a draft-07 schema object or boolean schema."

Copilot · 2026-04-06T22:41:02Z

+|-----|-----------|---------------|
+| **2. Truth = Replay** | Every decision is deterministically replayable | RCE operationalizes this law as a protocol |
+| **3. No Action Without Receipt** | All consequential acts emit receipts | Episode steps emit receipts into proof packs |
+| **4. Tri-Temporal Integrity** | valid_time ≤ observed_at ≤ recorded_at | Receipt timestamps in episode steps are proofs |


The "Tri-Temporal Integrity" row uses field names valid_time, observed_at, and recorded_at, but CRS v0.1 defines the optional tri_temporal object as {event_ts, record_ts, valid_from} (CONSTITUTIONAL_RECEIPT_STANDARD_v0.1.md §3.2). Consider aligning the names here to CRS, or explicitly stating these are conceptual timestamps and mapping them to CRS fields.

Suggested change

| **4. Tri-Temporal Integrity** | valid_time ≤ observed_at ≤ recorded_at | Receipt timestamps in episode steps are proofs |

| **4. Tri-Temporal Integrity** | valid_from ≤ event_ts ≤ record_ts | Receipt timestamps in episode steps are proofs |

Copilot · 2026-04-06T22:41:02Z

+| Stratum | Field | Example | Semantics |
+|---------|-------|---------|-----------|
+| Protocol type | `receipt_type` | `rce.episode_open/v0` | RCE protocol version |
+| Container | `schema_version` | `"3.0"` | Assay receipt pack envelope version |


This table claims schema_version is an Assay container/envelope version (example "3.0"), but CRS v0.1 defines schema_version as the CRS version (e.g., crs/0.1) and marks it as a required envelope field (§3.1). If RCE receipts "conform to the CRS v0.1 envelope", the schema_version semantics/examples here should match CRS (or use a different field name for an Assay-specific container version).

Suggested change

| Container | `schema_version` | `"3.0"` | Assay receipt pack envelope version |

| CRS envelope | `schema_version` | `crs/0.1` | CRS envelope version, as defined by CRS v0.1 §3.1 |

Copilot · 2026-04-06T22:41:02Z

+
+### 3.2 Deferred Opcodes
+
+Explicitly deferred to v0.1+: `LLM_CALL` (live execution), `TOOL_CALL` (live execution), `COMPARE_SEMANTIC` (Tier C), `ANCHOR` (witness layer), `FETCH` (network I/O during replay).


"Deferred Opcodes" says they are "deferred to v0.1+", but this document itself is v0.1. That wording is internally inconsistent—consider changing to "deferred to future versions" or a specific later version (e.g., v0.2+).

Suggested change

Explicitly deferred to v0.1+: `LLM_CALL` (live execution), `TOOL_CALL` (live execution), `COMPARE_SEMANTIC` (Tier C), `ANCHOR` (witness layer), `FETCH` (network I/O during replay).

Explicitly deferred to future versions: `LLM_CALL` (live execution), `TOOL_CALL` (live execution), `COMPARE_SEMANTIC` (Tier C), `ANCHOR` (witness layer), `FETCH` (network I/O during replay).

Copilot · 2026-04-06T22:41:02Z

+episode_spec_hash = SHA256( JCS( replay_normative_view ) )
+```
+
+JCS canonicalization per [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785). This matches the existing Assay canonicalization regime (`canon_version: "jcs-rfc8785"`).


The parenthetical reference to an "existing Assay canonicalization regime" via canon_version: "jcs-rfc8785" is currently undocumented elsewhere in this repo (no other canon_version references found). Consider either defining canon_version in the relevant spec/contract doc, or removing this aside and simply stating that RFC 8785 JCS is used.

Suggested change

JCS canonicalization per [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785). This matches the existing Assay canonicalization regime (`canon_version: "jcs-rfc8785"`).

JCS canonicalization is performed per [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785).

1. SKIPPED steps: output_hash is null, input_hashes is [], excluded from outputs_hash and Phase 4 replay comparison. 2. INTEGRITY_FAIL: claim_check is null (comparison not reached), verdict table updated to match receipt field definition. 3. Hash encoding: all hashes use sha256:<64-char-hex> format, stated once in §0.1 as a profile-wide convention. 4. Phase 3 outputs_hash: explicitly recomputed from step receipt payload values, not replay artifacts. Phase 4 resolves per-step comparator tier from comparator_tiers_by_step. Also: Phase 1 explicitly requires verifier-enforced step_id uniqueness (JSON Schema cannot enforce object-field uniqueness). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Founding Laws section was numbered 0.2, colliding with Pinned Invariants which was also 0.2 after the hash encoding convention was inserted. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

1. opcode→params enforcement: allOf/if-then constraints enforce required params per opcode (LOAD_INPUT→ref, ASSERT_HASH→target+ expected_hash, APPLY_TRANSFORM→transform, EMIT_OUTPUT→claim_type+ output_ref). Schema now rejects structurally invalid step params. 2. depends_on: add uniqueItems:true — duplicate dependency IDs are semantically nonsensical and now schema-rejected. 3. output_schema: constrained to type:object (must be a valid JSON Schema object, not arbitrary scalar/array values). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Copilot AI review requested due to automatic review settings April 6, 2026 22:36

Copilot started reviewing on behalf of Haserjian April 6, 2026 22:37 View session

Copilot AI reviewed Apr 6, 2026

View reviewed changes

Haserjian and others added 2 commits April 6, 2026 15:48

fix(rce): renumber duplicate §0.2 to §0.3

55fe0b9

Founding Laws section was numbered 0.2, colliding with Pinned Invariants which was also 0.2 after the hash encoding convention was inserted. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Haserjian mentioned this pull request Apr 6, 2026

feat: RCE recorded-trace verifier v0 Haserjian/assay#59

Merged

7 tasks

This was referenced Apr 7, 2026

feat: RCE replay scenarios (match, diverge, tampered) Haserjian/assay-proof-gallery#4

Open

docs: RCE replay mode action contract (PR E gate) Haserjian/assay-verify-action#3

Merged

Haserjian and others added 5 commits April 7, 2026 20:42

docs(rce): update RCE profile after review tightening

18863ec

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Add GLIMPS birth protocol profile

d89a4ff

Add GLIMPS profile validator

0c3fb81

Add GLIMPS dispatch to Assay validator

44b2041

Register GLIMPS profile metadata

12e0276

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs: RCE Profile v0.1 — replay-constrained episode normative schema#5

docs: RCE Profile v0.1 — replay-constrained episode normative schema#5
Haserjian wants to merge 9 commits into
mainfrom
feat/rce-profile-v0.1

Haserjian commented Apr 6, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Copilot AI Apr 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-          },
+          },
+          "uniqueItems": true,
+          "default": [],

	"description": "Optional JSON Schema for step output validation"
	"type": ["object", "boolean"],
	"description": "Optional JSON Schema for step output validation. Must be a draft-07 schema object or boolean schema."

	\| 4. Tri-Temporal Integrity \| valid_time ≤ observed_at ≤ recorded_at \| Receipt timestamps in episode steps are proofs \|
	\| 4. Tri-Temporal Integrity \| valid_from ≤ event_ts ≤ record_ts \| Receipt timestamps in episode steps are proofs \|

	\| Container \| `schema_version` \| `"3.0"` \| Assay receipt pack envelope version \|
	\| CRS envelope \| `schema_version` \| `crs/0.1` \| CRS envelope version, as defined by CRS v0.1 §3.1 \|


		### 3.2 Deferred Opcodes

		Explicitly deferred to v0.1+: `LLM_CALL` (live execution), `TOOL_CALL` (live execution), `COMPARE_SEMANTIC` (Tier C), `ANCHOR` (witness layer), `FETCH` (network I/O during replay).

	Explicitly deferred to v0.1+: `LLM_CALL` (live execution), `TOOL_CALL` (live execution), `COMPARE_SEMANTIC` (Tier C), `ANCHOR` (witness layer), `FETCH` (network I/O during replay).
	Explicitly deferred to future versions: `LLM_CALL` (live execution), `TOOL_CALL` (live execution), `COMPARE_SEMANTIC` (Tier C), `ANCHOR` (witness layer), `FETCH` (network I/O during replay).

	JCS canonicalization per [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785). This matches the existing Assay canonicalization regime (`canon_version: "jcs-rfc8785"`).
	JCS canonicalization is performed per [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785).

Conversation

Haserjian commented Apr 6, 2026

Summary

What this defines

Design lineage

Test plan

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants