Elnor Repo Reader

# ChatGPT



## Response to the attached adjudication card

**Verdict: I would accept the adjudication card as the operative E0 revision driver, with a small set of ratification caveats.** It is stronger than my standalone review because it does three things my review did not do cleanly enough: it dedupes both review streams into one UR spine, preserves the scope cuts against my over-expanded schema bodies, and turns the findings into anchored patch instructions against `Charter_Draft.md`.

I would **not** treat it as merely advisory. Its own instruction is correct: the full revision is “every accepted item,” not a cherry-picked minimum set, and the verdict properly says `E0_NEEDS_REVISION_ROUND → STAGE_6_CAN_OPEN_AFTER_PATCH`.

I would, however, route it as **proposal accepted subject to architect ratification on the two explicit forks**: UR-37 DOC25 as ReasonCode producer, and UR-38 restoring §4/§19/§20 per baseline. The card already marks both as decided in-card but veto-able at ratification.

------

# 1. High-level decision

## ACCEPT — use this card as the controlling revision plan

The card’s structure is sound:

- It identifies the target artifact as `Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Draft.md`.
- It adjudicates two review files into ~52 deduped items.
- It distinguishes accepted items, rejected over-scope, deferrals, and architect forks.
- It says fixes are anchored to target sections and should be applied after review, without claiming the adjudicator wrote to the spec.

That is the right form for this stage. The card is not just a review; it is a revision-control instrument.

## Revised final status

I would state the operative status this way:

```text
E0 revision required before red-team closure.
No ARCHITECT_STOP.
No global DOC80-family redesign.
Apply all accepted Tier 1–3 items.
Then E0 can proceed to post-patch ratification / downstream Stage 6 opening.
```

That matches the card’s final verdict: the DOC80-family direction is sound, but E0 is not ratifiable as-is because of the P0 `ContextProductKind` conflict, final-prompt learning bug, weak proof spine, revocation/polarity issue, undefined `SemanticProjectionContract`, missing named-lint inventory, absent §18, and dropped §4/§19/§20 plan bodies.

------

# 2. Items I fully accept

## UR-01 — `ContextProductKind` 17-vs-14 is the top blocker

**ACCEPT.**

This should be the first edit. The card is correct that the draft’s 14-kind `ContextProductKind` registry cannot survive. It treats ABC R0.2 §9.2 as senior and directly verified, adopts the 17-value list, says SM-060’s “14” lacks a merge rationale, and instructs replacing the draft’s invented enum.

The proposed replacement enum should be used as-is:

```ts
type ContextProductKind =
  | 'assertion_packet' | 'direct_memory_item' | 'topic_notice' | 'topic_slice'
  | 'library_notice' | 'library_source_slice' | 'cu_source_bound_synthesis'
  | 'recent_work_orientation' | 'issue_frame_orientation' | 'directive_block'
  | 'procedure_block' | 'warning_constraint' | 'null_result_notice'
  | 'conflict_notice' | 'search_affordance' | 'reference_only_notice' | 'blocked_scope_notice';
```

I also accept the ABC §9.3-aligned `ContextProductRegistryEntry` direction: registry in E0, assembly body in DOC84.

**Ratification note:** the card correctly says to patch SM-060 cross-artifact from “14 kinds” to “17 kinds; canonical = ABC R0.2 §9.2.”

## UR-02 — `FinalPromptTruthRef` should be NAMED-only

**ACCEPT.**

This is the right scoped version of my earlier finding. E0 should not own the full DOC11/OpenClaw runtime truth body, but it must name `FinalPromptTruthRef` and enforce the invariant that learning/utility credit requires proof that the relevant span survived into the executed final prompt. The card’s insertion after §3.4 is exactly the right shape.

I would keep these lints:

```text
learning.utility_without_final_prompt_proof
learning.utility_credit_for_trimmed_span
learning.utility_credit_for_suppressed_span
render.context_product_instance_id_lost_before_final_prompt
```

The first is canonical per the card; the latter three are proposed but useful.

## UR-03/04 — MFC discriminated union plus `ec_path`

**ACCEPT.**

The card improves my earlier MFC union by adding the `ec_path` distinction. That is important: durable writes and learning attribution go through serialized durable EC paths, while render/export/carryover/delegation can be EC-signed anchored attestations rather than taking the durable write queue lock.

The union should land. The old optional-ref interface should be deleted.

I especially endorse these lints:

```text
proof.render_without_memory_flow_certificate
proof.learning_attribution_without_memory_flow_certificate
proof.withheld_certificate_missing_reason_code
proof.flow_kind_required_ref_missing
proof.final_prompt_render_missing_final_prompt_truth
ec.delivery_attestation_on_serialized_write_path
```

## UR-05 and UR-07 — proof spine hardening

**ACCEPT.**

The boolean `membership_eligibility_checked` must be replaced by edge-level proof results. The card’s `MembershipEligibilityProof[]` replacement is the correct kind of proof artifact; it makes injected membership auditable instead of merely asserted.

I also accept proof retention classes. Proofs that gate durable writes, final-prompt renders, exports, carryover, delegation, or learning attribution must be retained as durable audit artifacts or referenced by the originating mutation envelope. This is necessary to keep the proof spine from becoming decorative.

## UR-08/09 — revocation cascade plus polarity

**ACCEPT.**

This is a critical correction. Source revocation is not a DOC82-only operation; it cascades through evidence/support edges, membership, delivery/carryover artifacts, learning signals, and Inspector surfaces. The card also correctly catches the contrary-edge polarity problem: removing a contradicting source may raise net warrant, so the invariant must require recompute and trace, not simply forbid increased eligibility.

I would land the `SourceRevocationCascade` interface as E0 invariant grammar and put per-plane execution bodies downstream.

## UR-31 — `SemanticProjectionContract`

**ACCEPT.**

This remains one of the most important missing contracts. E0 must define the umbrella rule: projections do not own truth, must carry source refs, generation ID, invalidation policy, projection owner, and proof/read-model refs. The card’s §3.6 insertion is scoped correctly and keeps concrete projection bodies in DOC82/DOC84/DOC86/DOC87.

Keep the canonical projection lints:

```text
projection.used_as_canonical_truth
projection.owner_missing
projection.missing_invalidation_policy
projection.missing_source_refs
```

## UR-35 and UR-38 — restore missing planned sections

**ACCEPT, subject to final architect ratification on UR-38.**

The card’s section-map diff is persuasive: baseline §2 expected §4 shared runtime vocabularies, §18 golden scenario, §19 amendment magnitude, and §20 per-member obligations, but the draft ends at §17 and drops those bodies.

I accept adding:

```text
§4 Shared runtime vocabularies
§18 Fixture taxonomy and golden scenario
§19 Per-external-doc amendment-magnitude assessment
§20 Per-member obligations tables
```

The proposed §4/§19/§20 text is appropriately compact and does not over-own downstream member bodies.

The §18 golden scenario should definitely be added. It is the fixture spine that lets Stage 8 test the full end-to-end memory path.

## UR-46 — named-lint inventory

**ACCEPT.**

This is a good scope correction. E0 should preserve lint names and lint families, but not implement Stage 9’s lint registry. The card’s coined-lint rule is especially important: canonical source tokens are preserved verbatim, while ChatGPT-coined tokens such as `adapter.*`, `cu_doc73.*`, and `monotonicity.<…>_monotone` are marked proposed pending Stage 9 confirmation.

That directly fixes the risk that my prior review would accidentally canonize proposed lint names as if they were already source tokens.

------

# 3. Items I accept with modifications or ratification notes

## UR-37 — DOC25 as ReasonCode producer

**ACCEPT-WITH-RATIFICATION.**

The card decides DOC25 should be a ReasonCode producer because originating docs own their parse/materialization/source-revocation condition codes. That is plausible and probably right, especially for ingestion/materialization failure modes. But this was originally a source drift issue: DOC25 appeared to be added without prior source support. The card handles that by logging a grounding obligation and making the fork veto-able at ratification.

I would keep the card’s decision, but require one ratification sentence in the patched draft or preservation matrix:

```text
DOC25 is admitted as a ReasonCode producer for ingestion, parsing, materialization,
source-binding, and source-revocation conditions. This is a ratified E0 decision
and must be reflected in Owner Map / ADQ-310.
```

Without that sentence, the patch could still look like accidental drift.

## UR-38 — restore §4/§19/§20

**ACCEPT-WITH-RATIFICATION.**

I agree with restoring the sections because the baseline apparently assigned them to Stage 6. The card explicitly treats this as a decided architect fork, veto-able at ratification.

My only caution: keep §19 and §20 as **first-draft governance scaffolds**, not hard final bodies that freeze every per-member obligation before E1–E10. The card already does this by putting per-member obligation instances in the deferral register.

## UR-11 — DomainProfile vector

**ACCEPT-WITH-SCOPE NOTE.**

The per-axis conservative meet rule should land. The card properly says DOC81 owns policy-axis values/semantics while E0 owns registry/fallback mechanics.

I would add one short line to avoid accidental DOC80 overreach:

```text
E0 defines the fallback/meet mechanics; DOC81 defines the authoritative axis vocabulary,
allowed action semantics, and profile-policy interpretation.
```

## UR-28 / UR-28b — reject meta-schemas, keep naming convention

**ACCEPT.**

This is the correct handling of my over-scoped material. Full `LintRegistryEntry`, `FixtureManifest`, `MemorySchemaMigrationPlan`, JSON-Schema-per-contract bodies, full lifecycle engine, full `FinalPromptTruthRef` schema, and executed `RenderSafetyProof` body do not belong in E0. The card rejects these while preserving lightweight naming conventions and deferrals.

I would not reopen this. The card gets the scope line right.

------

# 4. Items I would tighten before final application

## Tighten A — clarify `RenderMFC.final_prompt_truth_ref`

The card’s `RenderMFC` requires `final_prompt_truth_ref`, while the UR-02 prose says final-prompt truth is required for executed-prompt render and any learning/utility credit; preview/export-only render may use other proof targets and yields no learning credit.

That is almost right, but the union should avoid ambiguity around preview renders. Suggested tweak:

```ts
type RenderTarget = 'executed_prompt' | 'preview' | 'export_render';

interface RenderMFC extends BaseMFC {
  outcome: 'issued';
  flow_kind: 'render';
  ec_path: 'anchored_attestation';
  render_target: RenderTarget;
  context_packet_proof_ref: ContextPacketProofRef;
  render_safety_proof_ref: RenderSafetyProofRef;
  final_prompt_truth_ref?: FinalPromptTruthRefId; // required iff render_target === 'executed_prompt'
}
```

Then add the invariant:

```text
If render_target === 'executed_prompt', final_prompt_truth_ref is required.
Preview/export-only renders may not generate learning or utility credit.
```

This preserves UR-02 without forcing every preview render into DOC11 final-prompt truth.

## Tighten B — mark ABC §9.4 disposition enum as `⚠verify`

The card’s ADJ-1 says ABC §9.4 defines the canonical 7-value `ContextProductDecisionDisposition`. That is plausible and likely right, but unlike ABC §9.2’s 17-kind list, I have not independently re-verified the §9.4 exact enum in this turn. The card itself treats ABC §9.4 as canonical.

I would add a verify tag before final patching:

```text
⚠verify ABC §9.4 exact disposition spellings before applying ADJ-1.
```

If verified, apply exactly as written.

## Tighten C — distinguish canonical vs proposed revocation lints

The card says to add seven canonical revocation lints plus polarity lints. I accept the substance, but the final draft should label which are source-canonical and which are proposed.

Suggested label:

```text
Canonical:
- revocation.support_edge_survives_revoked_source
- revocation.membership_survives_revoked_source_without_restamp
- revocation.carryover_capsule_survives_revoked_source
- revocation.learning_credit_after_revocation
- revocation.learning_signal_survives_revoked_source
- revocation.inspector_leaks_revoked_source
- revocation.published_view_not_invalidated_after_revocation

Proposed Stage 9:
- revocation.supporting_source_removed_without_recompute
- revocation.contrary_source_removed_without_recompute
- revocation.net_warrant_changed_without_recompute_trace
```

That preserves the card’s coined-lint discipline.

## Tighten D — ensure §4 shared runtime vocabulary does not become a junk drawer

The §4 restore is right, but it needs the B10 guardrails to stay sharp. The card says §4 is for runtime-only enums/value types used by at least two family members and excludes process/non-runtime vocabulary.

Add this sentence:

```text
§4 does not admit concepts merely because they are cross-doc discussion terms;
the value must be runtime-consumed by at least two members or be a family-wide
serialization/identity convention.
```

That keeps §4 from becoming the new over-scoped registry.

------

# 5. Cross-artifact implications

I accept the card’s cross-artifact sweep as necessary. The specific list is correct:

```text
Supersession_Matrix.md — SM-060 14 → 17
DOC80_Owner_Map.md — CognitiveDiff row; ReasonCode producers; SemanticProjectionContract pointer
STAGE_6_CHARTER_INPUT_INDEX.md — add ADQ-313 to E0
E0_Red_Team_Review_Prompt.md — stale synthesis path
Architect_Decision_Queue.md — mark resolved-by-E0 items after ratification
OPA_V4.md — confirm support for DOC81–87 obligations; no new DOC80-core target rows
```

The card explicitly says not to edit these from the card itself, which is correct; they are discharge implications, not changes automatically made by adjudication.

I would add one process note: OP-A / SPEC_STATE / ADDENDA_STATE closure should still run as workflow housekeeping, even if the card says no new OP-A rows are required for DOC80 core. The Elnor carryover says OP-A maintenance is required at the close of every spec drafting/revision or red-team review session, including absorbed obligations, partials, new gaps, source registry, and maintenance log updates.

------

# 6. What this changes in my prior final review

The adjudication card supersedes my prior final review as the better revision instrument. My prior review remains useful as background, but this card is more application-ready.

Specifically, I now adopt these changes:

1. **Use UR numbering as the spine**, not my F numbering.
2. **Treat `ContextProductKind` as P0 and first edit.**
3. **Adopt ABC §9.3 entry shape**, not my generic registry-entry shape.
4. **Use `FinalPromptTruthRef` as NAMED-only**, not a full schema.
5. **Use MFC union with `ec_path`**, not my earlier union alone.
6. **Use revocation polarity language**, not a simplistic monotonicity lint.
7. **Restore §4/§18/§19/§20**, subject to ratification.
8. **Preserve coined-lint discipline.**
9. **Reject the over-scoped Stage 7/8/9 meta-schema bodies.**
10. **Use the deferral register and gate table to make deferred work recoverable.**

That is a net improvement over my document.

------

# 7. Final response to the card

## Decision

**ACCEPT AS REVISION PLAN, WITH RATIFICATION NOTES.**

The card should be saved/routed as `E0_Adjudication_Card.md` in the E0 `Reviews/` folder if Will wants to proceed, but I am not writing to GitHub from this response. The project instructions require explicit approval before repo writes.

## Apply order

I agree with the card’s ordering:

1. UR-01 `ContextProductKind` 17 + SM-060.
2. UR-02 `FinalPromptTruthRef`.
3. UR-03/04 MFC union.
4. UR-08/09 cascade + polarity.
5. UR-31 `SemanticProjectionContract`.
6. UR-46 named-lint inventory.
7. UR-07 proof retention classes.
8. UR-05 edge-level membership proof.
9. UR-35 §18 + UR-38 §4/§19/§20.
10. §16.3 / §17.4 / §15.4 registers.
11. Registry + ops hardening.
12. Minor rows.
13. Cross-artifact sweep.

## Ratification checklist I would use

```text
[ ] UR-01 applied; ContextProductKind = ABC §9.2 17 values.
[ ] SM-060 patch queued or applied.
[ ] FinalPromptTruthRef added as NAMED-only hook; no full DOC11 body in E0.
[ ] MFC replaced by discriminated union with ec_path.
[ ] Render preview/export-only behavior clarified.
[ ] Edge-level membership proof replaces boolean.
[ ] Proof retention classes added.
[ ] Five-plane source revocation cascade added.
[ ] Revocation polarity corrected.
[ ] SemanticProjectionContract defined.
[ ] §4, §18, §19, §20 restored or explicitly vetoed by Will.
[ ] §15.4 gate table present.
[ ] §17.4 preservation matrix present.
[ ] §16.3 named-lint inventory present with canonical/proposed distinction.
[ ] DOC25 ReasonCode producer decision ratified or vetoed.
[ ] ADQ-313 index drift patched.
[ ] Owner Map CognitiveDiff residue patched.
[ ] DOC8 ReasonCode / importer drift patched.
[ ] Prompt path drift patched.
[ ] OP-A / SPEC_STATE / ADDENDA_STATE maintenance run as applicable.
```

Final call: **route this card.** It is the best current synthesis of the review work.



According to a document from 2026-05-30, **no — E0 is not at an A yet as a spec.** It is at **A-/B+ architecture direction, with an A-grade adjudication plan, but not an A-grade ratifiable draft until the card is fully applied and a few remaining closure issues are patched.** The adjudication card itself says `E0_NEEDS_REVISION_ROUND → STAGE_6_CAN_OPEN_AFTER_PATCH`, and explicitly says the draft is “not ratifiable as-is” because of the P0 `ContextProductKind` conflict, final-prompt learning bug, proof-spine defects, revocation/polarity gap, undefined `SemanticProjectionContract`, missing lint inventory, missing §18, and dropped §4/§19/§20 plan bodies.

My updated answer is:

```text
Current Charter_Draft.md: not A.
Adjudication Card: A-/A as a revision driver.
Patched Charter_Draft.md after applying the card: probably A-/A.
Patched Charter_Draft.md after applying the card + the extra issues below: A.
```

The card is very strong. But after another harder pass, I see several final defects and closure risks that should be fixed before you call the result an A.

------

## 1. The card is good enough to drive the revision, but not enough to declare victory

The adjudication card is not just a review memo; it is a patch plan. It adjudicates two review streams into ~52 items, applies a disposition vocabulary, sets global schema conventions, marks critical severity highlights, and says all accepted Tier 1–3 items plus additions must be applied — not a subset.

That is exactly the right shape. It also correctly keeps the “harvest then cut” discipline: E0 owns grammar, names, one-owner assignments, invariants, and lint names; Stage 7 owns field bodies, Stage 8 fixtures, and Stage 9 lint implementation. The prior critique’s operational test is still the right one: keep full bodies only when E0 owns the object and design is settled; otherwise keep name + invariant + lint names and defer the body.

So: **the card gets us close.** But an A-grade foundation requires not just a good card; it requires the patched draft and companion artifacts to close the remaining contradictions.

------

## 2. Remaining A-grade blockers / hardening items

### A1 — BUG: close the open `⚠verify` roll-up before A

The card still has an open verification roll-up: V1 trace current fields, V2 Skeletal §10.7 mapping, V3 Skeletal §10.11/§11.9 wording, V4 ABC seniority, V5 §18 as E0 exit criterion, V6 SM-060 verbatim row, and V7 phantom DOC8 `importing_member` cell. Some are already mostly verified, but they are still listed as open.

An A-grade foundation should not ship with unresolved `⚠verify` items unless each is downgraded to a non-blocking post-ratification note. My recommendation:

```text
Before A:
[ ] V1 closed or converted to an explicit patch.
[ ] V2 closed in §17.2.
[ ] V3 source wording checked and cited.
[ ] V4 closed; ABC seniority confirmed.
[ ] V5 closed; §18 body requirement confirmed.
[ ] V6 closed; SM-060 exact row patched or cited.
[ ] V7 closed; phantom DOC8 importing_member removed or logged.
```

**Grade impact:** open verifies keep this at **A-/B+**, not A.

------

### A2 — BUG: the ADQ closure list still appears incomplete

The card’s cross-artifact sweep says that after ratification, ADQ-203, ADQ-208, ADQ-210, ADQ-211, ADQ-310, ADQ-313, ADQ-403, and ADQ-404 should be marked resolved-by-E0.

But the card itself relies heavily on **ADQ-207** for `MemoryFlowCertificate` / `FinalPromptTruthRef` and on **ADQ-312** for `WarrantDegradationTrigger`. It also references ADQ-209 for the three-plan model in `MemoryContextPlan`.

This should be made explicit. Otherwise you recreate the earlier ADQ pinning drift.

Patch:

```md
### ADQ landing normalization

E0 resolved-by-E0:
- ADQ-203
- ADQ-207
- ADQ-208
- ADQ-210
- ADQ-211
- ADQ-310
- ADQ-312
- ADQ-313
- ADQ-403
- ADQ-404

E0 consumed-by-E0 / referenced:
- ADQ-209, if not treated as resolved by the MemoryContextPlan section

Rule:
If an ADQ is consumed but not resolved, §17.4 must say why.
```

**Grade impact:** this is a real A-grade traceability issue.

------

### A3 — BUG: `ContextProductKind` needs a 17-row registry table, not just a union

The card correctly fixes the biggest P0: ABC R0.2 §9.2 enumerates 17 values, SM-060’s 14 is stale, and the draft’s 14 names match neither. It also gives the canonical 17-value union and an ABC §9.3-aligned `ContextProductRegistryEntry` shape.

But for A-grade, I would add one more required patch: **populate the registry, not just the enum.** A closed registry means every kind has at least minimal semantics. Otherwise downstream DOC84 still has to guess.

Add a 17-row table:

```md
### ContextProduct registry table

| kind | payload_schema_owner | assembly_owner | role_band | allowed_warrants | degrades_to | learning_target | candidate_injectable | final_prompt_instance_spine_required |
|---|---|---|---|---|---|---|---|---|
| assertion_packet | DOC82 | DOC84 | assertion | ... | ... | ... | ... | true |
| direct_memory_item | DOC87/DOC82? | DOC84 | assertion/source? | ... | ... | ... | ... | true |
| topic_notice | DOC87 | DOC84 | orientation | ... | ... | ... | ... | true |
| topic_slice | DOC87 | DOC84 | source/orientation | ... | ... | ... | ... | true |
| library_notice | DOC25/DOC82? | DOC84 | orientation | ... | ... | ... | ... | true |
| library_source_slice | DOC25/DOC82? | DOC84 | source | ... | ... | ... | ... | true |
| cu_source_bound_synthesis | DOC82/DOC73? | DOC84 | source/orientation | ... | ... | ... | ... | true |
| recent_work_orientation | DOC83/DOC84 | DOC84 | orientation | ... | ... | ... | ... | true |
| issue_frame_orientation | DOC83/DOC84 | DOC84 | orientation | ... | ... | ... | ... | true |
| directive_block | DOC81/DOC84 | DOC84 | constraint | ... | ... | ... | ... | true |
| procedure_block | DOC3/DOC84 | DOC84 | affordance | ... | ... | ... | ... | true |
| warning_constraint | DOC81/DOC86 | DOC84 | constraint | ... | ... | ... | ... | true |
| null_result_notice | DOC84 | DOC84 | affordance | ... | ... | disallowed | false | true |
| conflict_notice | DOC82/DOC86 | DOC84 | constraint | ... | ... | ... | ... | true |
| search_affordance | DOC84/DOC24 | DOC84 | affordance | ... | ... | disallowed | false | true |
| reference_only_notice | DOC82/DOC84 | DOC84 | source | ... | ... | manifest_only | false | true |
| blocked_scope_notice | DOC81/DOC84 | DOC84 | constraint | ... | ... | disallowed | false | true |
```

Do not use my tentative owners above as final. Pull from ABC §9.3 if it has registry rows; otherwise add `⚠owner-confirm` cells and block E7/E8 until filled.

**Grade impact:** without this table, the 17-kind fix is only half done.

------

### A4 — BUG: the `RenderMFC` schema still contradicts the preview/export carveout

The card text says final-prompt truth is required for executed-prompt render and learning/utility credit, while preview/export-only render may use other proof targets and yields no learning credit. But the `RenderMFC` interface itself requires `final_prompt_truth_ref` unconditionally.

That is a schema/prose contradiction. Fix it with a discriminator:

```ts
type RenderTarget =
  | 'executed_prompt'
  | 'preview'
  | 'export_render';

interface RenderMFC extends BaseMFC {
  outcome: 'issued';
  flow_kind: 'render';
  ec_path: 'anchored_attestation';
  render_target: RenderTarget;
  context_packet_proof_ref: ContextPacketProofRef;
  render_safety_proof_ref: RenderSafetyProofRef;

  /**
   * Required iff render_target === 'executed_prompt'.
   * Forbidden as a learning basis if absent.
   */
  final_prompt_truth_ref?: FinalPromptTruthRefId;
}
```

Add invariant:

```text
If render_target === 'executed_prompt', final_prompt_truth_ref is required.
If final_prompt_truth_ref is absent, no learning or utility credit may attach.
```

Add lint:

```text
proof.executed_prompt_render_missing_final_prompt_truth
learning.credit_from_preview_render
```

**Grade impact:** this is important because the spec is supposed to be buildable; a coding agent will read the interface first.

------

### A5 — BUG: export proof needs a content-class discriminator

`ExportMFC` has optional `final_prompt_truth_ref`, which is probably right, but only if the export does not include executed-prompt-rendered content.

Patch:

```ts
type ExportContentClass =
  | 'raw_source_export'
  | 'memory_record_export'
  | 'rendered_prompt_export'
  | 'carryover_export'
  | 'audit_bundle_export';

interface ExportMFC extends BaseMFC {
  outcome: 'issued';
  flow_kind: 'export';
  ec_path: 'anchored_attestation';
  export_content_class: ExportContentClass;
  context_packet_proof_ref?: ContextPacketProofRef;
  export_manifest_ref: ExportManifestRef;

  /**
   * Required iff export_content_class === 'rendered_prompt_export'
   * or the export is used as a learning/utility basis.
   */
  final_prompt_truth_ref?: FinalPromptTruthRefId;
}
```

Add lint:

```text
proof.rendered_prompt_export_missing_final_prompt_truth
```

**Grade impact:** medium-high. It prevents a subtle export path from bypassing the final-prompt truth rule.

------

### A6 — BUG: global `schema_version` convention must be reflected in E0-owned code snippets

The card sets global conventions: branded-string IDs, snake_case JSON, RFC3339 timestamps, `sha256` hashes, and `schema_version` on durable records. But several paste-ready snippets omit `schema_version`. Because these snippets are intended as operative patch text, a coding agent may copy them literally.

Patch rule:

```text
Every E0-owned durable, retained, registry, or proof/audit artifact must include:
schema_version: SchemaVersionRef;
```

At minimum add it to:

```text
ContextProductRegistryEntry
MemoryFlowCertificate / BaseMFC
ProofArtifactRetentionRule
ReasonCodeRegistryEntry
ReasonCodeNamespaceAllocation
DomainProfile
WarrantDegradationTrigger
ExternalDependencyRecord
MemoryPlaneHealthCounter
MemoryOperationQuotaBound
SemanticProjectionContract
SourceRevocationCascade
```

**Grade impact:** medium. It is a consistency bug, not an architecture flaw.

------

### A7 — BUG: cross-artifact sweep should explicitly include Import Graph, Retired Names, and Source Registry

The card’s cross-artifact implications include the Supersession Matrix, Owner Map, Stage 6 Charter Input Index, E0 Red-Team Prompt, ADQ Queue, and OPA. That is good, but I would add three more:

```text
DOC80_Import_Graph.md
DOC80_Retired_Names.md
Source Registry / Target Freeze source registry
```

Why:

- `FinalPromptTruthRef` creates explicit DOC11/OpenClaw dependency.
- `RenderSafetyProof` execution points to DOC84.
- `SourceRevocationCascade` spans DOC82/DOC84/DOC85/DOC86/DOC87.
- `ContextProductKind` relies on ABC R0.2 as a senior target-freeze input.
- The invented 14 draft `ContextProductKind` names should be logged as invalid/retired aliases or “do not reintroduce” terms.

Add to discharge checklist:

```text
[ ] DOC80_Import_Graph.md updated for new/clarified E0 dependencies.
[ ] DOC80_Retired_Names.md updated with invalid ContextProduct draft names if needed.
[ ] Source Registry / Target Freeze records ABC R0.2 §9.2/§9.3/§9.4 as the authoritative ContextProduct source.
```

**Grade impact:** high for drift prevention.

------

### A8 — BUG-light: OP-A handling is ambiguous

The deferral register says DOC25 ReasonCode-producer grounding is recorded as an OP-A candidate plus §17.4 matrix. But the cross-artifact section says no new OP-A rows are required by the card, while also acknowledging workflow housekeeping. The standing carryover says OP-A is attached to every red-team and drafting/revision session and must be updated at close; skipping it loses system memory.

This needs one clarifying sentence:

```md
OP-A clarification:
This card creates no new DOC80-core target obligation rows unless Will ratifies UR-37/UR-38 as cross-doc obligations requiring tracking.
Regardless, OP-A maintenance log, source registry, absorbed/partial status, and any new cross-doc gaps must be updated at session close.
```

**Grade impact:** medium. It matters because your workflow loses decisions if OP-A is skipped.

------

### A9 — BUG: §4 should not declare a generic `LifecycleState`

The proposed §4 shared runtime vocabulary includes `LifecycleState='active'|'deprecated'|'retired'`. That risks reintroducing the lifecycle-engine ambiguity that the card otherwise correctly rejects. The card rejects a full lifecycle/erasure state machine and keeps only lints/non-equivalence language.

Patch:

```text
Replace generic LifecycleState with RegistryEntryLifecycleState.

RegistryEntryLifecycleState =
  'candidate' | 'active' | 'deprecated' | 'retired'

Do not use this for memory lifecycle, erasure, legal hold, suppression,
revocation, or render eligibility.
```

Keep `MembershipLifecycleState` separate. Do not create a generic memory lifecycle enum in §4.

**Grade impact:** medium-high because it prevents a closed decision from leaking back in.

------

### A10 — GAP: `ContextProductDecision` should be named, not just its disposition enum

The card fixes `ContextProductDecisionDisposition` by adopting ABC §9.4’s canonical seven values. But E0 should also name `ContextProductDecision` itself as a DOC84-owned decision record, because the instance spine, final-prompt truth, and learning eligibility all depend on it.

Patch:

```md
### ContextProductDecision — NAMED-only DOC84-owned runtime record

E0 role:
- names the decision record;
- requires every product request to resolve to a decision;
- requires every assembled/degraded/blocked/suppressed product to preserve request_id, kind, disposition, reason_codes, registry_version, and product_instance_ref if any;
- requires context_product_instance_id to survive into FinalPromptTruthRef when rendered.

Owner:
- DOC84 owns the field body.
```

Add lints:

```text
context_product.request_without_decision
context_product.decision_missing_registry_version
context_product.decision_missing_reason_code_for_blocked
context_product.instance_id_missing_from_final_prompt_truth
```

**Grade impact:** medium-high. It binds the `MemoryContextPlan`, ABC §9.4 disposition, final-prompt truth, and DOC85 learning chain.

------

### A11 — GAP: classify new E0-owned contracts by retention/audit class in the object table

The card adds an `audit_replay_class` column and new rows for proof, trace, prompt, projection, health, quota, and dependency objects. But after the latest additions, the table should explicitly include these new or clarified objects:

```text
ContextProductRegistryEntry
ContextProductDecision
ContextProductInstanceRef
FinalPromptTruthRef
SourceRevocationCascade
ProofArtifactRetentionRule
ExternalDependencyRecord
SemanticProjectionAxisRegistration
RenderSafetyCheck vocabulary
RegistryEntryLifecycleState
```

And classify them:

```text
ContextProductRegistryEntry → canonical
ContextProductDecision → durable_audit or derived? DOC84 decides, but E0 should gate it
FinalPromptTruthRef → durable_audit_required when learning/utility attaches
SourceRevocationCascade → durable_audit_required
SemanticProjectionContract → canonical
SemanticProjectionAxisRegistration → canonical
RenderSafetyCheck vocabulary → canonical
```

**Grade impact:** medium. This is how you stop “proof-ish” objects from becoming transient.

------

### A12 — GAP: a post-patch regression review should be required before calling it A

The card says `STAGE_6_CAN_OPEN_AFTER_PATCH`. I would add one narrow post-patch review before declaring A:

```text
Post-patch E0 regression review:
- Verify every Tier 1 item landed.
- Verify every accepted Tier 2/3 item either landed or is in §7 deferral register.
- Verify V1–V7 closed.
- Verify §15.4 gate table, §17.4 preservation matrix, §18 golden scenario, §4/§19/§20 bodies exist.
- Verify SM-060, Owner Map, Import Graph, Stage 6 Index, ADQ Queue, Retired Names, Source Registry, and prompt path sweep.
- Verify no over-scoped Stage 7/8/9 bodies snuck back into E0.
```

**Grade impact:** high. Without this, you are trusting patch application rather than verifying it.

------

## 3. What I would not add

I would **not** reopen full lifecycle/erasure machinery. The card correctly rejects the lifecycle engine and accepts only lints/non-equivalence, preserving the “do not reopen DOC88” decision.

I would **not** add full `FinalPromptTruthRef`, `FixtureManifest`, `LintRegistryEntry`, or `MemorySchemaMigrationPlan` bodies to E0. The deferral register correctly places MME/MPG bodies, DOC81 policy-axis values, DOC84 executed `RenderSafetyProof`, DOC11/OpenClaw final prompt truth, and lint/fixture/migration meta-schemas in their owning stages.

I would **not** rename `ContextProduct` to `ContextArtifact`. The card correctly rejects that because ABC uses `ContextProduct` and the churn would be negative value.

------

## 4. Revised grade

### Current draft

```text
Grade: B+/A- architecture direction, not ratifiable.
Reason: the core decomposition is sound, but the draft still has unresolved source conflict, proof gaps, missing bodies, and drift.
```

### Adjudication card

```text
Grade: A- as a revision driver.
Reason: it captures the right defects, cuts over-scoped bodies, and gives paste-ready patches.
Not A because it leaves open verifies and a few closure ambiguities.
```

### Patched draft if the card is applied exactly

```text
Grade: A-/A.
Reason: all major architectural defects are closed.
Remaining risk: cross-artifact and verification discipline.
```

### Patched draft if the card plus the additional items above are applied

```text
Grade: A.
Reason: the spec becomes source-stable, misuse-resistant, owner-bounded, and downstream-actionable.
```

------

## 5. My final recommendation

Do **not** declare A now. Declare:

```text
E0 is one revision round away from A.
The adjudication card is the correct controlling patch plan.
Before final A/routing, add the small “A-grade closure addendum”:
1. close V1–V7;
2. normalize ADQ-207/312/313/209 disposition;
3. populate the 17-row ContextProduct registry table;
4. fix RenderMFC / ExportMFC final-prompt-truth discriminators;
5. add schema_version to E0-owned durable snippets;
6. expand cross-artifact sweep to Import Graph, Retired Names, and Source Registry;
7. clarify OP-A handling;
8. rename generic LifecycleState to RegistryEntryLifecycleState;
9. name ContextProductDecision;
10. require a post-patch regression review.
```

After that, yes: **I would be comfortable calling E0 an A-grade foundation.**

Yes — but I would **not** reopen the architecture or add another large schema layer. I would make a final **lock addendum** to the card: mostly traceability, consistency, and copy-paste-safety fixes. After that, I would lock it.

The card is already strong as the controlling revision plan: it identifies `ContextProductKind` as the P0 issue, keeps the “harvest findings, cut over-scoped bodies” discipline, restores dropped DOC80 sections, and routes full bodies to the correct later owner/stage where appropriate. The attached adjudication also correctly warns that the real fix is to keep the findings while cutting premature E0-owned schema bodies unless the object is both E0-owned and design-settled.

My answer: **yes, make these final changes before locking.**

------

## Final changes I would make before locking the card

### 1. BUG — Do not lock with unresolved `⚠verify` items

The card still has an “Open `⚠verify` roll-up” for V1–V7. That is fine in a draft adjudication card, but not in a locked one.

I would replace the open roll-up with a **resolved or explicitly queued verification table**:

```md
## Lock-state verification disposition

| Verify item | Lock disposition |
|---|---|
| V1 §3.4 trace current fields | Convert to explicit patch: add `session_ref`, `turn_id`, `request_correlation_id`, optional `parent_trace_ref`. |
| V2 Skeletal §10.7 mapping | Convert to explicit patch: §17.2 maps Skeletal §10.7 to DOC82↔DOC83 disposition seam → §12, not proof spine → §4. |
| V3 Skeletal §10.11/§11.9 wording | Close during source sweep; revocation cascade + polarity rows remain mandatory. |
| V4 ABC seniority | Closed: ABC §9.2 is senior source for the 17-value `ContextProductKind` list. |
| V5 §18 as E0 exit criterion | Closed unless Will vetoes UR-35; §18 body is required by the baseline checklist. |
| V6 SM-060 verbatim row | Convert to cross-artifact patch: SM-060 “14” → 17 or explicit architect rationale. |
| V7 phantom DOC8 `importing_member` cell | Convert to cross-artifact patch: remove or mark legacy/non-runtime. |
```

A locked card can still contain work items, but it should not contain unresolved ambiguity about whether the finding is real.

------

### 2. BUG — Normalize the ADQ closure/disposition list

The card’s cross-artifact ADQ resolution list omits ADQ-207 and ADQ-312 even though the card relies on them for `MemoryFlowCertificate` / `FinalPromptTruthRef` and `WarrantDegradationTrigger`. It also uses ADQ-209’s three-plan context model.

Add this to the card:

```md
## ADQ landing normalization

E0 resolved-by-E0:
- ADQ-203
- ADQ-207
- ADQ-208
- ADQ-210
- ADQ-211
- ADQ-310
- ADQ-312
- ADQ-313
- ADQ-403
- ADQ-404

E0 consumed-by-E0 / referenced:
- ADQ-209, unless ratified as resolved by the `MemoryContextPlan` grammar.

Rule:
Any ADQ consumed by E0 but not resolved by E0 must be listed in §17.4 with:
- consumed_by_E0
- downstream_owner
- why_not_resolved_here
- pickup gate
```

This closes the earlier ADQ drift class permanently.

------

### 3. BUG — Require a 17-row `ContextProduct` registry table, not just the enum

The card correctly replaces the draft’s bad 14-kind enum with ABC §9.2’s 17 canonical values. The attached review verified that this was the strongest catch and that the senior source really does list 17 values.

But an A-grade registry needs more than a union. It needs a table with at least minimal semantics per kind.

Add to UR-01:

```md
In addition to replacing the enum, E0 must include a 17-row `ContextProductRegistryEntry` table.

Minimum columns:
- kind
- payload_schema_owner
- assembly_contract_owner
- packet_executor
- role_band
- allowed_warrants
- allowed_support_roles
- header_fields_required
- default_budget_band
- evictable
- degrades_to
- learning_target
- candidate_injectable
- final_prompt_instance_spine_required
- owner_status = confirmed | ⚠owner-confirm

If ABC §9.3 gives exact row values, use those. If not, fill only source-confirmed cells and mark the rest `⚠owner-confirm`; E7/E8 may not treat those rows as final until confirmed.
```

Also add:

```md
ContextProductDecision is NAMED-only in E0.

DOC84 owns the field body, but E0 requires:
- every product request resolves to a decision;
- every decision records request_id, kind, disposition, reason_codes, registry_version, and product_instance_ref if assembled;
- context_product_instance_id survives into FinalPromptTruthRef when rendered;
- learning attribution cannot attach without that instance spine.
```

This binds `ContextProductKind`, `MemoryContextPlan`, final-prompt truth, and DOC85 learning into one coherent spine.

------

### 4. BUG — Fix `RenderMFC` final-prompt-truth contradiction

The card prose says final-prompt truth is required for executed-prompt render and learning/utility credit, but preview/export-only render may use other proof targets and yields no learning credit. The pasted `RenderMFC` interface, however, requires `final_prompt_truth_ref` unconditionally.

Patch the union:

```ts
type RenderTarget =
  | 'executed_prompt'
  | 'preview'
  | 'export_render';

interface RenderMFC extends BaseMFC {
  outcome: 'issued';
  flow_kind: 'render';
  ec_path: 'anchored_attestation';
  render_target: RenderTarget;

  context_packet_proof_ref: ContextPacketProofRef;
  render_safety_proof_ref: RenderSafetyProofRef;

  /**
   * Required iff render_target === 'executed_prompt'.
   * If absent, this render may not become a learning or utility-credit basis.
   */
  final_prompt_truth_ref?: FinalPromptTruthRefId;
}
```

Add lints:

```text
proof.executed_prompt_render_missing_final_prompt_truth
learning.credit_from_preview_render
learning.credit_from_export_render_without_final_prompt_truth
```

------

### 5. BUG — Add an export-content discriminator to `ExportMFC`

`ExportMFC.final_prompt_truth_ref` is optional in the card, which is correct only for exports that do not include executed-prompt-rendered content. Make that explicit.

```ts
type ExportContentClass =
  | 'raw_source_export'
  | 'memory_record_export'
  | 'rendered_prompt_export'
  | 'carryover_export'
  | 'audit_bundle_export';

interface ExportMFC extends BaseMFC {
  outcome: 'issued';
  flow_kind: 'export';
  ec_path: 'anchored_attestation';

  export_content_class: ExportContentClass;

  export_manifest_ref: ExportManifestRef;
  context_packet_proof_ref?: ContextPacketProofRef;

  /**
   * Required iff export_content_class === 'rendered_prompt_export'
   * or the export is used as a learning / utility-credit basis.
   */
  final_prompt_truth_ref?: FinalPromptTruthRefId;
}
```

Add lint:

```text
proof.rendered_prompt_export_missing_final_prompt_truth
```

------

### 6. BUG — Make `schema_version` copy-paste-safe in snippets

The card states global schema conventions, including `schema_version` on durable records. That is good, but some snippets omit it. Since this card is paste-ready, a later agent may copy the interface literally.

Add this once:

```ts
interface E0DurableRecord {
  schema_version: SchemaVersionRef;
  created_at: string; // RFC3339 UTC
}
```

Then add this instruction:

```md
Every E0-owned durable, registry, retained-proof, or audit artifact extends or includes `E0DurableRecord`.

Applies at minimum to:
- ContextProductRegistryEntry
- ReasonCodeRegistryEntry
- ReasonCodeNamespaceAllocation
- DomainProfile
- WarrantDegradationTrigger
- BaseMFC / MemoryFlowCertificate variants
- ProofArtifactRetentionRule
- ExternalDependencyRecord
- MemoryPlaneHealthCounter
- MemoryOperationQuotaBound
- SemanticProjectionContract
- SemanticProjectionAxisRegistration
- SourceRevocationCascade
```

This prevents the global convention from being lost in implementation.

------

### 7. BUG — Rename generic `LifecycleState` in §4 to avoid reopening the lifecycle engine

The proposed §4 shared runtime vocabulary includes:

```text
LifecycleState='active'|'deprecated'|'retired'
```

That is dangerous because the card otherwise correctly rejects reopening the full lifecycle/erasure engine. The attached critique also warned against quietly rebuilding a collapsed lifecycle/DOC88 decision.

Change it to:

```ts
type RegistryEntryLifecycleState =
  | 'candidate'
  | 'active'
  | 'deprecated'
  | 'retired';
```

Add:

```md
`RegistryEntryLifecycleState` applies only to registry entries and schema/control-plane declarations.
It must not be used as a memory lifecycle, erasure, legal-hold, suppression, revocation, or render-eligibility state.
```

Keep `MembershipLifecycleState` separate. Do not create a generic memory lifecycle enum in DOC80.

------

### 8. GAP — Make helper types in the `ContextProductRegistryEntry` shape explicit

The UR-01 registry-entry snippet uses `OwnerDocId`, `UseWarrant`, and `SupportRole`. That is fine, but a locked card should say where those live.

Add:

```md
All helper types used by `ContextProductRegistryEntry` must be either:
1. declared in §4 Shared runtime vocabularies, or
2. referenced to their canonical owner.

At minimum:
- OwnerDocId → DOC80 §4 shared runtime vocabulary.
- UseWarrant → DOC82-owned semantics; E0 may reference but not redefine warrant semantics.
- SupportRole → DOC82-owned support/evidence semantics unless ABC §9.3 defines a narrower product-support role enum.
- BudgetBand → DOC80 §4 shared runtime vocabulary.
```

This prevents §3.1 from smuggling DOC82 semantics into DOC80.

------

### 9. GAP — Mark canonical vs proposed revocation lints

The card has a good coined-lint rule, and it correctly carries canonical source tokens verbatim. But in the source-revocation patch, canonical lints and newly proposed polarity lints are adjacent. Label them.

```md
Canonical revocation lints:
- revocation.support_edge_survives_revoked_source
- revocation.membership_survives_revoked_source_without_restamp
- revocation.carryover_capsule_survives_revoked_source
- revocation.learning_credit_after_revocation
- revocation.learning_signal_survives_revoked_source
- revocation.inspector_leaks_revoked_source
- revocation.published_view_not_invalidated_after_revocation

Proposed Stage 9 polarity lints:
- revocation.supporting_source_removed_without_recompute
- revocation.contrary_source_removed_without_recompute
- revocation.net_warrant_changed_without_recompute_trace
```

That keeps the card’s provenance discipline intact.

------

### 10. GAP — Expand the cross-artifact sweep

The card’s cross-artifact sweep is good, but I would add three items:

```md
Additional cross-artifact / discharge implications:
- [ ] DOC80_Import_Graph.md — update for clarified DOC11/OpenClaw, DOC84, DOC85, DOC82, DOC86, DOC87 dependencies introduced by FinalPromptTruthRef, RenderSafetyProof, SourceRevocationCascade, and SemanticProjectionContract.
- [ ] DOC80_Retired_Names.md — add invalid draft-only ContextProductKind names as “do not reintroduce” aliases if they are not part of ABC §9.2.
- [ ] Source Registry / Target Freeze — record ABC R0.2 §9.2 / §9.3 / §9.4 as authoritative ContextProduct source material.
```

Also keep OP-A / tracker closure explicit. The carryover says OP-A maintenance is non-negotiable at the close of every spec drafting/revision or red-team review session.

Add:

```md
OP-A / tracker closure:
- [ ] OP-A maintenance log updated.
- [ ] OP-A §6/§7 rows updated for absorbed, partial, or newly discovered cross-doc obligations.
- [ ] SPEC_STATE updated if E0 stage/review status changed.
- [ ] ADDENDA_STATE updated if any addendum/source-card state changed.
```

------

### 11. GAP — Add a post-patch regression gate before declaring A

The card currently says:

```text
E0_NEEDS_REVISION_ROUND → STAGE_6_CAN_OPEN_AFTER_PATCH
```

I would refine that to:

```text
E0_NEEDS_REVISION_ROUND → STAGE_6_CAN_OPEN_AFTER_PATCH_AND_REGRESSION_CHECK
```

Add this checklist:

```md
## Post-patch E0 regression gate

Before E0 is called A-grade / red-team-closed:

- [ ] Every Tier 1 item landed.
- [ ] Every accepted Tier 2/3 item landed or is explicitly enrolled in §7 Deferral Register.
- [ ] V1–V7 closed or converted to explicit cross-artifact tasks.
- [ ] §4, §15.4, §16.3, §17.4, §18, §19, and §20 exist.
- [ ] ContextProductKind = ABC §9.2 17 values.
- [ ] 17-row ContextProduct registry table exists or has explicit `⚠owner-confirm` cells.
- [ ] MFC union uses render/export discriminators correctly.
- [ ] No full FinalPromptTruthRef / LintRegistry / FixtureManifest / lifecycle-engine body snuck into E0.
- [ ] SM-060, Owner Map, Import Graph, Stage 6 Index, ADQ Queue, Retired Names, Source Registry, and prompt path are swept.
- [ ] OP-A / SPEC_STATE / ADDENDA_STATE closure completed as applicable.
```

This is the difference between “a good card exists” and “DOC80 is actually safe to lock.”

------

## Things I would **not** change

I would not add full field bodies for:

```text
FinalPromptTruthRef
MemoryMutationEnvelope
MemoryProvenanceGraph
LintRegistryEntry
FixtureManifest
MemorySchemaMigrationPlan
DOC84 RenderSafetyProof execution body
DOC81 policy-axis values
full lifecycle / erasure state machine
```

That would violate the card’s own scope discipline and repeat the over-build pattern the attached critique warned about.

I also would not rename `ContextProduct`; the senior source uses that term, and the churn would be negative value.

------

## Final answer

**Yes, I would make a final lock addendum with the items above.** The most important are:

1. close V1–V7;
2. normalize ADQ-207 / ADQ-312 / ADQ-209 disposition;
3. require a 17-row `ContextProduct` registry table;
4. fix `RenderMFC` and `ExportMFC` final-prompt-truth discriminators;
5. make `schema_version` copy-paste-safe;
6. rename generic `LifecycleState` to `RegistryEntryLifecycleState`;
7. expand the cross-artifact sweep to Import Graph, Retired Names, and Source Registry;
8. require a post-patch regression gate.

After those changes, I would lock the card. Without them, the card is still excellent, but it leaves a few seams that could recreate exactly the drift and under-specification DOC80 is supposed to prevent.



# CLAUDE:



 E0 / DOC80-Core — Adjudication Card Review

**Card under review:** `…/Stage 6 E0 Red Teaming/S6 E0 DOC80 Adj Card 1.md` (Claude Opus 4.8; 50,901 chars). **Reviewer:** Claude Opus 4.8, repo-verified (`wbrody/Elnor-Specs@main`). **Method:** every cited source (ABC R0.2 §9.2–§9.6, Skeletal §2/§10.11/§11.9/§11.10, both source reviews F1–F40 / UR-01–48) read directly. **Bottom line:** the card is reference-grade and overwhelmingly correct — its dispositions, traceability, coined/canonical split, section-map diff, both decided forks, and verdict hold up. It has a small set of fixable defects, two of which are correctness issues an implementer would inherit. **Verdict: `RATIFY_WITH_MINOR_FIXES`.**

### FINDINGS

**[BUG] UR-01 — paste-ready `ContextProductRegistryEntry` drops two ABC §9.3 fields.** *(card §3 §C → draft §3.1; ABC §9.3.)* The block is labelled "ABC-§9.3-aligned," but ABC §9.3 `ProductRegistryEntry` has `allowed_roles: MemoryObjectRole[]` and `header_fields_na: (keyof WarrantedItemHeader)[]`, and the card's entry contains **neither**. It also weakens `header_fields_required` from `(keyof WarrantedItemHeader)[]` to `string[]`. For an A/A+ registry where agents must not guess, omitting which `MemoryObjectRole`s a kind admits and which header fields are N/A removes real contract. **Disposition ACCEPT stands; the fix is incomplete.** Restore:

ts

```ts
  allowed_roles: MemoryObjectRole[];                 // ABC §9.3 (dropped)
  header_fields_required: (keyof WarrantedItemHeader)[];   // restore keyof typing
  header_fields_na: (keyof WarrantedItemHeader)[];   // ABC §9.3 (dropped)
```

Sub-note: confirm the inlined `learning_target: 'allowed'|'disallowed'|'manifest_only'` matches ABC's `LearningTarget` alias (not separately verified).

**[BUG] UR-08/09 — polarity correction left unreconciled with the §11.9 monotonicity law.** *(card §3 §G → draft §12.1; Skeletal §11.9.)* Skeletal §11.9 states categorically: *source revocation … cannot raise warrant.* UR-09 (correctly) adds: *a contrary-source removal MAY raise net warrant.* The card updates the §12.1 invariant row to be polarity-aware but never scopes the monotonicity **law**, so if both land verbatim the spec self-contradicts. **Disposition ACCEPT stands; add the reconciliation.** Scope the law: *"source revocation cannot raise the warrant of any assertion the revoked source **supported**; net warrant of assertions the source **contradicted** may rise on recompute — this is not a monotonicity violation."* Tie to the existing `revocation.net_warrant_changed_without_recompute_trace`; optionally add `monotonicity.polarity_unaware_revocation_law`.

**[GAP] Card silently dropped ChatGPT F11 — `PromptShellLearningContract` / `PromptShellExposure` hooks.** *(card coverage §4 claims full F## fold; draft §2.3; Skeletal §2 §7 / ADQ-208.)* F11 appears **nowhere** in the card — not accepted, modified, rejected, or deferred — and `PromptShellLearningContract` is a baseline-§7/ADQ-208 E0 element. **Corrected disposition: ACCEPT name-only.** Add NAMED-only hooks for `PromptShellLearningContract` (and `PromptShellExposure` as the variant exposure/selection contract), bodies to DOC85/Stage 7, mirroring UR-02's `FinalPromptTruthRef`; enroll in the §7 register.

**[GAP] Card silently dropped ChatGPT F30 — debug/dev-mode contract.** *(draft §1.x/§3.)* An ungoverned dev/debug mode that renders or feeds learning outside the proof spine is a litigation-grade integrity hole, and F30 is absent from the card entirely. **Corrected disposition: ACCEPT name-only.** Name a `DebugModeContract` (NAMED-only): debug/dev flows are non-learning and either still carry an MFC or are explicitly out-of-band and excluded from any durable/learning effect; lint `debug_mode.flow_without_non_learning_guarantee`. At minimum disposition it; do not drop.

**[GAP / BETTER_IDEA] UR-03/04 — `RenderMFC` cannot represent a preview render (all three missed).** *(card §3 §C → draft §3.3/§3.5.)* `RenderMFC` mandates `final_prompt_truth_ref`, yet §3.5 (UR-02) explicitly contemplates *"preview/export-only render [that] may use other proof targets but yields no learning credit."* `ExportMFC` already made `final_prompt_truth_ref?` optional; `RenderMFC` should be reconciled the same way. **Fix:** add `render_mode: 'executed'|'preview'` to `RenderMFC` (final-prompt truth required iff `executed`), or split `ExecutedRenderMFC`/`PreviewRenderMFC`; preview carries packet+render-safety proofs, no final-prompt truth, non-learning. Lint `proof.preview_render_with_learning_credit`.

**[SUGGESTION] UR-37 fork — narrow DOC25's reason-code grounding.** *(card §3 §B; ADQ-310 / Owner Map 86; Skeletal §10.11.)* DOC25 as a producer for **parse/materialization/ingestion** codes is right (originating-doc-owns-its-codes). But the rationale also hands DOC25 "source-revocation conditions" — and source revocation is a **DOC82** knowledge-source event (per §10.11 DOC82 owns the support-edge plane). **Fork stance: AGREE-with-modification** — keep DOC25 as producer, but narrow the grounding obligation to parse/materialization/ingestion and route source-revocation reason codes to DOC82.

**[SUGGESTION] Deferral tracking — UR-34 has no recorded home.** *(card §7 / §15.4.)* UR-34 says `IngestionCostBudget`=DOC25 (E3) and `WarrantConsequenceRegistry`=DOC82 (E4) "confirm at E3/E4," but neither the §7 register nor the §15.4 gate table carries a row, so the OFAR resolution has no pickup trigger. **Fix:** add gate-table rows (IngestionCostBudget→E3; WarrantConsequenceRegistry→E4). (Everything else in §7 is properly enrolled.)

**[SUGGESTION] UR-08 / UR-46 — revocation-lint citation imprecise.** The card calls all seven revocation lints "canonical … Skeletal §10.11," but §10.11 enumerates **six**; the seventh, `revocation.learning_signal_survives_revoked_source`, is from the Stage 5R synthesis inventory (the card's own UR-46(a) lists it there). Tighten to "§10.11 (6) + Synthesis §4 (learning_signal_survives)." Token is genuinely canonical; cosmetic.

**[SUGGESTION] ChatGPT F28 only partially folded.** UR-41 covers the un-merge consequence of embedding-model migration but not F28's provenance ask. Add NAMED-only `embedding_generation_id` + a comparability invariant ("embeddings not comparable across generations without a re-embedding pass"). Low priority.

**[SUGGESTION] Housekeeping — strip the trailing sign-off from the committed file.** The committed card ends, after `*End of … Adjudication Card.*`, with the generating model's chat sign-off ("That's the entire card… Want me to draft the reviewer prompt…"). Strip it so the artifact is clean before ratification.

### CONFIRMED (verified correct — apply as written)

- **UR-01** 17-kind enum == ABC §9.2 **verbatim**. ✓
- **ADJ-1** `ContextProductDecisionDisposition` == ABC §9.4's exact 7 values (`inject_inline … suppressed_manifest_only`) — canonical, not coined. ✓
- **ADJ-2** DOC8→DOC85 grounded in ABC §9.5 ("BDSM/DOC8 utility attribution must use it") + ADQ-221. ✓
- **UR-08** `SourceRevocationCascade` 5 planes == Skeletal §10.11's 5 planes (DOC82/DOC87/DOC84/DOC85/DOC86), all `required_outcomes` faithful. ✓
- **UR-31** `SemanticProjectionAxisRegistration` plane→owner == Skeletal §11.10 (Delivery→84, UI→86, Org→87, Knowledge→82, contract→80). ✓
- **UR-47** "all four monotonicity laws already present" == Skeletal §11.9's four laws. ✓
- **Coined-vs-canonical split** correct: `adapter.*`/`cu_doc73.*`/`monotonicity.<…>_monotone` = coinage (Stage-9 confirms); `learning.*`/`erasure.*`/`projection.*`/`revocation.*` = canonical. ✓
- **Section-map diff** correct and complete: baseline §2 is exactly 21 sections; all 21 accounted for; drops only at §4/§18/§19/§20 + §17 partial; **no other silent drop**. ✓
- **Coverage**: all 40 ChatGPT findings exist in source; UR-01–48 spine fully carried; F33 folded into UR-48; rejects (meta-schemas→Stage 7/8/9, full bodies, `ContextProduct→ContextArtifact`) correctly rejected. ✓
- **MFC `ec_path`** keeps `durable_write`/`learning_attribution` on `serialized_durable` and `render`/`export`/`carryover`/`delegation` on `anchored_attestation` — renders off the write-commit path. ✓ (modulo the preview-render gap above)
- **UR-38** restore §4/§19/§20 — baseline §2 explicitly assigns all three to DOC80/E0. ✓

### TIER-1 STANCE TABLE

| Card row       | Stance               | One-line reason                                              |
| -------------- | -------------------- | ------------------------------------------------------------ |
| **UR-01**      | **AGREE** (with fix) | ACCEPT/P0 right; 17 kinds verbatim — but the entry must restore `allowed_roles` + `header_fields_na` (Finding 1). |
| **UR-02**      | **AGREE**            | NAMED-only hook, DOC11 owns body; grounded in Skeletal §18 + ABC §9.5. |
| **UR-03/04**   | **AGREE** (with fix) | MFC union + `ec_path` is the right shape; add `render_mode` to reconcile with §3.5 (Finding 5). |
| **UR-05**      | **AGREE**            | Edge-level `MembershipEligibilityProof` + set hashes — correct and complete. |
| **UR-07**      | **AGREE**            | Four `ProofRetentionClass` values + retention rule; correctly blocking. |
| **UR-08/09**   | **AGREE** (with fix) | 5-plane cascade matches §10.11 and polarity is right; add the §11.9 monotonicity-law reconciliation (Finding 2). |
| **UR-31**      | **AGREE**            | Contract + axis registration match §11.10 ownership exactly. |
| **UR-35**      | **AGREE**            | §18 skeleton is E0-appropriate (Stage 8 owns bodies); ⚠ exact step list not line-verified vs baseline §18 (card's own ⚠V5). |
| **UR-46**      | **AGREE**            | Owner-split inventory + coinage caveat is exactly right; split verified. |
| **UR-38**      | **AGREE**            | Baseline §2 assigns §4/§19/§20 to E0; restore is correct.    |
| **Fork UR-37** | **AGREE w/ mod**     | DOC25 is a producer for parse/materialization/ingestion; narrow grounding and send source-revocation codes to DOC82 (Finding 6). |
| **Fork UR-38** | **AGREE**            | Conform-to-baseline is correct; §19 is the only debatable one but the iterated baseline governs. |

### VALUE-TIERED SYNTHESIS

- **Critical (fix before applying the card):** Finding 1 (UR-01 dropped contract fields); Finding 2 (UR-08/09 ↔ §11.9 reconciliation).
- **Substantive:** Finding 3 (F11 orphan); Finding 4 (F30 orphan); Finding 5 (RenderMFC preview split); Finding 6 (UR-37 narrowing).
- **Minor:** Finding 7 (UR-34 gate-table enrollment); Finding 8 (revocation-lint citation); Finding 9 (F28 embedding provenance); Finding 10 (strip sign-off).
- **Considered-and-declined:** I concur with every card REJECT — UR-28 meta-schemas → Stages 7/8/9; ChatGPT full bodies (mis-own DOC11 / reopen synthesis §6); `ContextProduct→ContextArtifact` rename (ABC §9.2 senior). I concur with deferring the UR-42–45 BETTER_IDEA annex. No reject should be reversed.

### VERDICT

**`RATIFY_WITH_MINOR_FIXES`** — the card is correct in structure, traceability, and judgment; apply it, with these ordered must-changes folded in first:

1. **UR-01** — restore `allowed_roles` + `header_fields_na`; use `(keyof WarrantedItemHeader)[]`; confirm `learning_target` vs ABC `LearningTarget`.
2. **UR-08/09** — add the source-revocation monotonicity clause scoping §11.9's law to *supported* assertions.
3. **F11** — add NAMED-only `PromptShellLearningContract` (+ `PromptShellExposure`) hooks; enroll in §7.
4. **F30** — name a NAMED-only debug/dev-mode contract (non-learning, proof-gated or out-of-band); disposition + §7.
5. **UR-03/04** — add `render_mode` (or split Preview/Executed MFC) to reconcile `RenderMFC` with §3.5.
6. **UR-37** — narrow DOC25 grounding to parse/materialization/ingestion; route source-revocation codes to DOC82.
7. **UR-34** — add §15.4 gate rows (IngestionCostBudget→E3; WarrantConsequenceRegistry→E4).
8. **Citation + housekeeping** — fix the §10.11-vs-synthesis lint attribution; strip the trailing chat sign-off from the committed file.

The card's own verdict on the **draft** — `E0_NEEDS_REVISION_ROUND → STAGE_6_CAN_OPEN_AFTER_PATCH` — is correct and should be retained; nothing here rises to a harder `ARCHITECT_STOP` beyond the already-affirmed do-not-reopen on the lifecycle engine (UR-29).

------

That's the full review. I've kept it inline so it renders cleanly. Want me to commit it to `…/Stage_6_Charters/E0_DOC80_Core/Reviews/Card Reviews/Claude_Opus_4_8_E0_Adjudication_Card_Review.md`? Given the author of the card is also Opus 4.8, you may want a reviewer-distinguishing filename — say the word on the path and I'll write it (otherwise it stays here for you to place).





Deeper dive done — and reading the draft end-to-end (which my first pass didn't do; it checked the card against its *sources*, not against the draft's actual text) surfaced a set of real defects that **all three — both source reviews and the card — missed.** These are additions to my prior review; the verdict on the card itself is unchanged, but the E0 revision should absorb these alongside the card's items.

## E0 / DOC80-Core — Adjudication Card Review, Deeper-Dive Addendum

### New findings (none of the three caught these)

**[BUG · litigation-grade] N1 — `MemoryFlowKind` has no `erasure` flow; destruction has a detection lint but no certificate.** *(draft §3.3 MFC + §12.1 legal-hold row; affects card UR-03/04, UR-07, UR-29.)* The draft enumerates six flows (`durable_write|render|export|carryover|delegation|learning_attribution`) and the card's MFC union copies exactly those six. Yet §12.1 carries `legal_hold.destructive_job_skipped_check`, and the prose names real destructive jobs (DOC72 §42 graph cleanup, DOC23 retention/expiry, DOC25 source-deletion) plus "hard destruction… remains manual." So destruction is a first-class durable, **irreversible**, audit-critical effect — and it is the one effect with *no certificate*. The legal-hold check is only a Stage-9 *detection* lint, not a proof carried at erase time. For a securities-litigation system, defensible deletion (proving *what* was destroyed, *who* authorized it, and that legal hold was cleared) is exactly the artifact you need. **Fix — add an `erasure` flow + `ErasureMFC`:**

ts

```ts
type MemoryFlowKind =
  | 'durable_write' | 'render' | 'export' | 'carryover'
  | 'delegation' | 'learning_attribution' | 'erasure';
interface ErasureMFC extends BaseMFC {
  outcome: 'issued'; flow_kind: 'erasure'; ec_path: 'serialized_durable';
  mutation_envelope_ref: MemoryMutationEnvelopeRef;     // tombstone/delete envelope
  erasure_kind: 'soft_tombstone' | 'hard_destruction' | 'redaction';
  legal_hold_clearance_ref: LegalHoldClearanceRef;      // DOC81 LegalHoldState cleared AT erase time
  authorized_by: ActorRef;                              // hard destruction is manual
  irreversibility_attested: boolean;
}
```

Lints: `erasure.without_memory_flow_certificate`, `erasure.hard_destruction_without_legal_hold_clearance_ref`, `erasure.certificate_not_durable_audit_retained`. Retention (UR-07): `ErasureMFC` + its envelope = `durable_audit_required`. This upgrades the legal-hold check from "lint that might fire" to "clearance ref the certificate cannot be issued without."

**[GAP · determinism] N2 — `ReproducibilityKey` (UR-19) omits the warrant-degradation-trigger registry generation.** *(draft §3.1 `determinism_rule: 'product_is_a_pure_function_of_named_inputs'`; affects card UR-19.)* Warrant degradation can flip a product's disposition (`inject_inline`→`reference_only`/`blocked`) or `candidate_injectable`, so it is part of the function that selects/renders products. The card's key names `context_product_registry_version` but **not** the degradation-trigger registry — so a degradation-registry change between two runs alters the selected set with an identical key, violating the very determinism rule the key exists to guarantee. **Fix:** add `warrant_degradation_trigger_registry_version`, `reason_code_registry_version`, `domain_profile_registry_version` to `ReproducibilityKey`; lint `determinism.degradation_or_reasoncode_registry_version_not_named_input`. (UR-14b already versions the trigger registry — wire that generation in.)

**[GAP · ARCHITECT_STOP-adjacent] N3 — `SourceRevocationCascade` (UR-08) has no DOC83 extraction plane.** *(draft §12.1 + §20 seed; Skeletal §10.11.)* The 5-plane cascade (DOC82/84/85/86/87) faithfully matches §10.11, and §20 has DOC83 re-gating only on *policy* change — so on **source revocation**, extraction candidates (DOC83) derived from the revoked source are unaddressed. A candidate quoting a clawed-back source could later promote into an assertion. Either (a) add a sixth plane `doc83_extraction_candidates: 'invalidated' | 're_gate_required'`, or (b) add the invariant *"an extraction candidate cannot promote against a revoked source"* + lint `revocation.extraction_candidate_promoted_from_revoked_source`. Because option (a) amends the Skeletal §10.11 baseline, **this is an architect call, not a silent card fix** — flag `OPEN_FOR_ARCHITECT_REVIEW`.

**[GAP · completeness] N4 — UR-01's 14→17 sweep is under-specified and will leave stale "14"s in the shipped spec.** *(draft §3.1, §6/§14 taxonomy row, §15.3, §17.2.)* The card names only "§3.1 prose, the `…has_exactly_14_kinds` fixture, §16.1 item 3, SM-060." But "14 (product) kinds" also appears in: the §3.1 registry inline comment (`// the canonical 14 kinds`) and two traceability notes; the **taxonomy-table row** ("14 fixed kinds (§3.1)"); the **§15.3 discharge sweep** (3 references); the **discharge-sweep fixture list**; and the **§17.2 SM-060 cross-ref** ("ContextProduct 14-kind registry"). **Fix:** make UR-01 a *global* `14 kinds`→`17 kinds` sweep across §3.1/§6/§14/§15.3/§17.2 and rename the fixture token in **every** occurrence — while explicitly **not** touching the unrelated "14 Skeletal §10/§11 fold-ins" count (which SA-B correctly preserves). Without this, an A+ spec ships self-contradicting kind counts.

**[BUG · policy ceiling] N5 — the restamp-ceiling invariant is only half-linted.** *(draft §12.1 policy-monotonicity row; ADQ-316.)* The row states "restamp cannot exceed original ceilings (ADQ-316)" but its only lint, `monotonicity.policy_widened_without_restamp`, catches widening *without* a restamp — **not** a restamp that *exceeds* the original ceiling. A restamp that silently over-grants disclosure passes the lint. **Fix:** add `policy.restamp_exceeds_original_ceiling` with gate at the DOC81 restamp path. Direct disclosure-leak risk in a litigation context.

**[GAP · medium · litigation] N8 — export/delegation MFCs don't require disclosure re-evaluation at the boundary.** *(draft §3.3; card UR-03/04.)* `ExportMFC`/`DelegationMFC` carry a `policy_generation_id`, and UR-03/04 adds "EC-signed against a **read-consistent** policy generation" — but read-consistency is not boundary-freshness. If a source is revoked between packet assembly (gen 5) and an export to co-counsel (now gen 6), a packet attested at gen 5 is internally consistent yet **stale**, and the export proceeds against superseded policy. **Fix (E0 names it; DOC81/DOC84 execute):** invariant that `export`/`delegation` certificates re-evaluate the disclosure meet at the boundary (`policy_generation_id` must be current-at-boundary) and carry a `disclosure_scope_attestation_ref`; lints `export.disclosure_policy_not_reevaluated_at_boundary`, `delegation.scope_envelope_not_reevaluated_at_boundary`. Ties the flatten plan's "task-handoff scope-envelope confirmation" surface to a proof.

**[SUGGESTION · reconciliation] N7 — UR-02 adds a final-prompt learning gate but leaves the pre-existing weaker one unreconciled.** *(draft §12.1 "learning signal with no packet proof → `proof.learning_signal_without_context_packet_proof`".)* UR-02 *inserts* the final-prompt-truth row but doesn't revise the existing ContextPacketProof-gated row, so the table reads as if packet proof alone suffices for learning — the exact misread UR-02 corrects. **Fix:** revise the existing row to "ContextPacketProof is **necessary, not sufficient**; final-prompt truth (UR-02) also required," applying the UR-40 necessary-not-sufficient pattern so the two rows compose.

**[SUGGESTION · consistency] N6 — `WithheldMFC.withheld_reason_code` is singular.** *(draft §3.3; card UR-03/04.)* ABC §9.4 `ContextProductDecision` and the card's own `MembershipEligibilityProof` use `reason_codes: ReasonCodeId[]`; a withhold routinely has several causes (policy + scope + budget). **Fix:** `withheld_reason_codes: ReasonCodeId[]`.

**[SUGGESTION · disagree-with-card] N9 — UR-03/04 drops the MFC `executor` field; keep it.** *(draft §3.3 `executor: ProducerDocRef`.)* The card removes per-flow `executor` because `issued_by` is uniformly `'EC'`. But `issued_by` (certifier) and `executor` (the member that actually performed the render/export/write — DOC24 vs DOC84 vs DOC11) are different provenance. Auditors tracing "which subsystem produced this delivery" want the executor. **Fix:** retain `executor: ProducerDocRef` alongside `issued_by: 'EC'`.

### Forward idea (capability, not a defect)

**[BETTER_IDEA] Destruction ledger = N1 (`ErasureMFC`) + UR-42 (hash-chained proof log) + UR-07 (`durable_audit_required`).** Fold these into one named, append-only, tamper-evident **destruction ledger**: every erasure writes an `ErasureMFC` into a hash-chained log that *survives the destruction it records* (you retain proof of what was deleted, by whom, with legal-hold state — without retaining the content). That is the defensible-deletion / spoliation-defense capability that puts ELNOR ahead of 2027–2028 peers for legal work, and it costs almost nothing once N1 and UR-42 exist. Worth promoting from the deferred UR-42 annex into a named E0 obligation seam (body in DOC84/DOC85 + DOC11).

### Net effect on the verdict

The card's own conclusions stand — it correctly and faithfully adjudicated the two reviews, and my verdict on **the card** remains **`RATIFY_WITH_MINOR_FIXES`**. What this pass shows is that *the underlying draft has more residual gaps than any of the three reviews caught*, so the E0 revision round should fold these in too. Two of them rise above "minor": **N1 (erasure flow)** — the only durable effect with no certificate, and the most litigation-relevant — and **N3 (DOC83 cascade plane)**, which is an `ARCHITECT_STOP`-adjacent baseline question you should decide explicitly rather than inherit silently.

**Additions to the must-change list (append to my prior 8):** 9. **N1** — add `erasure` flow + `ErasureMFC` (legal-hold clearance ref, irreversibility, `durable_audit_required`). 10. **N3** — decide the DOC83-on-revocation question (sixth cascade plane *or* promotion-time re-check); `OFAR`. 11. **N2** — add the degradation/reason-code/domain-profile registry generations to `ReproducibilityKey`. 12. **N4** — global `14→17` sweep (§3.1/§6/§14/§15.3/§17.2 + fixture token), excluding the "14 fold-ins" count. 13. **N5** — add `policy.restamp_exceeds_original_ceiling`. 14. **N8** — export/delegation boundary disclosure re-evaluation invariant + attestation. 15. **N7 / N6 / N9** — reconcile the §12.1 learning row; pluralize `withheld_reason_codes`; retain MFC `executor`.

Want me to consolidate review #1 + this addendum into a single clean `Claude_Opus_4_8_E0_Adjudication_Card_Review.md` and commit it to `…/E0_DOC80_Core/Reviews/Card Reviews/`? I'd merge the findings into one ordered list, fold these into the stance table and value tiers, and keep the verdict token. Say the word on the path and I'll write it.

### Yes — one structural item, then I'd lock

**[BUG · litigation-grade] N10 — a policy \*restamp\* is a durable, privilege-\*widening\* effect with no certificate.** *(draft §12.1 policy-monotonicity row; §9 health; affects card UR-03/04, UR-07, and subsumes my N5.)* I verified it: `MemoryFlowKind` has six values, `RestampMFC` appears zero times, and `PolicyStampRestamp` is named **only** as the widening mechanism in the §12.1 invariant ("policy only narrows without a `PolicyStampRestamp`; restamp cannot exceed original ceilings, ADQ-316"), with nothing but a gate, the half-lint from N5, and a `policy_restamp_failures` health counter behind it.

That's the same hole as N1 (erasure), and arguably more dangerous: DOC80's whole design rule is *"every durable/external/learning effect leaves a proof"* — yet the **two most legally-sensitive effects of all (irreversible destruction and re-widening access to previously-restricted/privileged material) are precisely the two with no certificate.** A restamp can re-expose work-product or privileged content; in a securities matter you want an audit-grade record of every one. **Fix — make restamp a certified flow (this also turns N5's ceiling check from a Stage-9 lint into a carried attestation):**

ts

```ts
type MemoryFlowKind =
  | 'durable_write' | 'render' | 'export' | 'carryover'
  | 'delegation' | 'learning_attribution' | 'erasure' | 'policy_restamp';
interface RestampMFC extends BaseMFC {
  outcome: 'issued'; flow_kind: 'policy_restamp'; ec_path: 'serialized_durable';
  mutation_envelope_ref: MemoryMutationEnvelopeRef;   // the EffectiveMemoryPolicy change
  prior_policy_generation_id: PolicyGenerationId;     // before (BaseMFC.policy_generation_id = after)
  original_ceiling_ref: PolicyCeilingRef;             // ceiling the restamp may not exceed (ADQ-316)
  ceiling_compliance_attested: boolean;
  authorized_by: ActorRef; reason_codes: ReasonCodeId[];
}
```

Lints: `restamp.without_memory_flow_certificate`, `restamp.exceeds_original_ceiling` (= N5), `restamp.certificate_not_durable_audit_retained`. Retention (UR-07): `durable_audit_required`. With N1 + N10, the certified-flow set finally closes over **every** durable effect.

### One optional consolidation (low-cost)

**[BETTER_IDEA] A single "negative-outcome → reason codes" invariant.** There's no cross-cutting lint (`reason_code_required` / `without_reason_code` = 0 in the draft); reason codes live per-object (MFC withhold, `MembershipEligibilityProof`, ABC §9.4 decision) but nothing guarantees that *every* block / withhold / suppress / degrade / exclude / revoke / restamp-deny carries ≥1 reason code. One invariant + lint family (`*.negative_outcome_without_reason_code`) would harden the "why-not-remembered" Inspector (a crown-jewel) and cost almost nothing. Optional — fold in if you want the inspectability story airtight.

### Beyond that, I'd lock it

I've now read the load-bearing surfaces directly — the registries (§2, §3.1), the MFC/proof spine (§3.3/§4), the trace (§3.4), the invariant table (§12.1), revocation (§12), determinism (§3.1), ext-dep (§7), lifecycle/legal-hold (§1.4/§1.5), and export/delegation — and that's where defects live. The remaining sections (§5 NAMED-only, §6 classification, §9/§10 ops, §13 ext-dep, §14 AC-004/005, §16 lint suite) I spot-checked rather than line-read, and they're covered by the card's UR rows with nothing jumping out. **I'm at diminishing returns; further passes would be polish, not substance.**

So my honest lock judgment: **`RATIFY_WITH_MINOR_FIXES` stands**, and DOC80/E0 is lockable once the consolidated change-list is folded into the card. Net-new since my last message is just **N10** (+ the optional reason-code invariant); everything in review #1 (the 8 must-changes) and the addendum (N1–N9) still holds. The only residual risk is in those few spot-checked sections — if you want *zero* residual before locking, the single highest-value remaining move is one dedicated line-read pass over §5/§6/§9/§10/§13/§16; otherwise I'd lock.

Want me to consolidate everything — review #1 + the addendum + N10 + the optional idea — into one clean `Claude_Opus_4_8_E0_Adjudication_Card_Review.md` (merged ordered findings, updated stance table and value tiers, single verdict token) and commit it to `…/E0_DOC80_Core/Reviews/Card Reviews/`? Say the word on the path and I'll write it.