# C32 — `r6-implementation-guide.md` + `r6-security-analysis.md` First-Pass Internal-Consistency + Cross-Spec Audit

**Audit ID**: C32
**Targets** (audited as a coupled **pair**):
- `web4-standard/core-spec/r6-implementation-guide.md` (140 lines; last substantive git mod **2026-01-27** `ad9f5ecd`)
- `web4-standard/core-spec/r6-security-analysis.md` (195 lines; last substantive git mod **2026-01-23** `52aa67a9`)

**Date**: 2026-06-05
**Auditor**: autonomous web4 session (legion, slot `000000`), v2 protocol
**Type**: First-pass internal-consistency audit (within each file **and across the pair**) + cross-spec consistency audit
**Prior coverage**: none — both files are genuinely un-audited. They are the **last two un-audited core-spec normative files** and the **oldest live files in `core-spec/`** (untouched since January 2026 while every sibling — `r6-framework.md`, `security-framework.md`, `data-formats.md`, `errors.md` — advanced through the C-series). With C32, **first-pass core-spec normative coverage is COMPLETE**.

**Why the pair is one audit**: the impl-guide's "Security Considerations" (line 132) explicitly defers to `r6-security-analysis.md`; the two are an implementation-guide + its companion threat-model. §A includes a genuine **pair-vs-pair** consistency pass (e.g. the impl-guide defines three tiers — does the security analysis cover all three?). The deliverable is still **one** audit file.

**Method note**: executed as a multi-agent audit per `feedback_audit_workflow_adversarial_verify.md` — **five parallel lens-finders** (internal-consistency incl. pair-vs-pair / cross-spec vs `r6-framework.md` / cross-spec vs SDK `r6.py`+vectors+`security-framework.md` / identifier-form / altitude-placement), each followed by an adversarial verifier instructed to **refute by default**. **36 candidate findings → 32 survived, 4 fully refuted**; critically, the adversarial pass **moderated severity *downward* on 17 of the survivors** (mostly MEDIUM→LOW or LOW→INFO) and corrected several routings. After de-duplication across lenses (multiple finders independently surfaced the same placement / cross-ref / identifier issues), the distinct findings are consolidated below. Every surviving finding was re-verified by hand against the live files.

---

## Scope & Methodology

Both files declare implementation-survey purposes: the impl-guide (line 5) states *"The R6 framework … **is implemented across multiple projects** with different purposes and levels of enforcement,"* and the security-analysis (line 5) *"This document analyzes attack vectors and mitigations."* They describe **cross-project implementation tiers** — Tier 1 Observational (`web4/claude-code-plugin` + `moltbot/extensions/web4-governance`), Tier 2 Authorization (`hardbound/hardbound-core`, a **private** repo), Tier 3 Training (`HRM/sage/…`) — and reference external repos and dated PRs. The canonical **normative** R6 specification is the separate `r6-framework.md` (the R6 equation, §4 R6 Security Properties, §7 status taxonomy + `R6Error` hierarchy).

Three passes:
1. **Internal-consistency (§A)** — each file vs itself, and the **pair vs each other**.
2. **Cross-spec (§B)** — vs `r6-framework.md`, `security-framework.md` (just-merged C31), `data-formats.md` (identifier SSOT), the SDK (`implementation/sdk/web4/r6.py` `ActionStatus` enum + `R7Error` hierarchy), the conformance vectors (`testing/conformance/r6-r7-actions.json`), and the `web4-standard/README.md` index.
3. **Primitive-clustered (§C)** (`auditor-blindspot-pattern`) — re-read through the **altitude/placement** lens (are these normative core-spec or implementation-status notes?) and the **identifier-form** lens.

**Severity**: **HIGH** = correctness/normative contradiction (esp. a spec statement contradicting a conformance vector/SDK); **MEDIUM** = cross-spec divergence needing reconciliation, or a structural/placement question with corpus consequences; **LOW** = hygiene/wording/naming/staleness; **INFO** = forward-awareness or positive confirmation, no action.

**Routing**: **AUTONOMOUS** (a future remediation turn can fix it inside one of the two r6 files with no design decision); **DESIGN-Q** (requires an operator canonicity decision; recorded, *not resolved here*); **CROSS-TRACK** (fix/verify lands in another file — including **anything** touching `hardbound`/`moltbot`/`HRM` internals or external repos).

**Binding conditions honored**:
- **Descriptive-vs-normative discipline (the defining feature of this audit)**: both files are largely *descriptive*. Per the policy-review mandate, descriptive prose was **not** scored against normative conformance it never claimed. Instead, the *descriptive-document-presented-as-core-spec-normative* mismatch is itself flagged (C-M1). This is why **4 candidate findings were fully refuted** — all were variants of "the Hardbound tier state-machine contradicts the SDK/canonical statuses," which is a category error: the states are explicitly tier-labeled proprietary lifecycle, not a normative claim.
- **Private-repo protection**: findings touching `hardbound-core`/`moltbot`/`HRM` internals are routed **CROSS-TRACK**; no non-public detail is reproduced (only what is already printed in the two public files is cited).
- **Anti-padding**: the six INFO items are honest positive confirmations / fairness-checks / negative results, explicitly labelled.

**Headline result (honest, and unlike every prior C-series target)**: **zero HIGH findings and zero normative contradictions.** Every previous C-series file was a normative spec with real conformance contradictions (e.g. C18-H3, C31-B-H1 — a spec failing its own vector). The r6 pair has **none**, for a structural reason: it makes **zero normative claims** (a corpus grep confirms **no RFC-2119 keywords** in either file). The substantive issue is therefore **altitude/placement** (C-M1), not correctness. The remaining findings are LOW/INFO hygiene.

---

## Findings Summary

| ID | Sev | Routing | One-line |
|----|-----|---------|----------|
| **C-M1** | MED | DESIGN-Q | ⭐ **Placement/altitude root**: both files are descriptive cross-project implementation-status / threat-survey docs sitting in `core-spec/` with no non-normative marker (reference a private repo + dated PRs; zero RFC-2119 keywords) |
| **A-L1** | LOW | AUTONOMOUS | impl-guide defines **3 tiers**, security-analysis analyzes only **2** (Tier 3 Training has no threat model / scoping note) |
| **A-L2** | LOW | AUTONOMOUS | impl-guide §"R6Status States" subsection labels are inconsistent (SAGE row lacks the tier parenthetical; no lead sentence stating these are per-tier lifecycles, not one shared state machine) |
| **A-L3** | LOW | AUTONOMOUS | impl-guide Hardbound R6Status states (`Approved/Rejected/Completed/Failed`) need a one-line clarifier that they are tier-internal, distinct from canonical R6 Result statuses `{success, failure, error}` |
| **B-L1** | LOW | AUTONOMOUS | Neither file references the canonical `r6-framework.md` it implements/analyzes (impl-guide References omit it; security-analysis References are external-only) |
| **B-L2** | LOW | CROSS-TRACK | `README.md` index points to a **nonexistent** `r6-framework-legacy.md` **and omits all three live `r6-*.md` docs** (both audited files undiscoverable from the ToC) |
| **C-L1** | LOW | AUTONOMOUS | Staleness: demote time-bound live-status phrasing (`← Live implementation`, `(January 2026)`, `PR #1`/`PR #2`) to undated, repo-neutral wording (couples C-M1) |
| **C-L2** | LOW | AUTONOMOUS + DESIGN-Q | Orphan identifier schemes `r6:{uuid8}` / `audit:{uuid8}` / `web4:session:{hash12}` are coined here and registered nowhere (incl. `data-formats.md` SSOT) — relabel as illustrative (AUTONOMOUS); canonical-scheme question folds into the unified-identifier DESIGN-Q |
| **B-I1** | INFO | CROSS-TRACK | `security-framework.md` ↔ `r6-security-analysis.md` still lack a reciprocal cross-ref (C31-A-L3 follow-through; FROM-security-framework edit is CROSS-TRACK) |
| **B-I2** | INFO | — | ✅ Positive: R6 equation, six-component set, and `{success/failure/error}` status model are **consistent** across the pair, `r6-framework.md`, SDK, and vectors — no contradiction |
| **B-I3** | INFO | — | security-analysis attack catalog (A1–A6/B1–B6/C1–C3) is consistent with but not mapped to `r6-framework.md` §4 Security Properties (optional additive mapping) |
| **C-I1** | INFO | DESIGN-Q | ✅ Fairness PASS: `lct:web4:{type}:{id}` (incl. the `root` example) is **corpus-consistent** with `r6-framework.md` + vectors + `multi-device-lct-binding.md` — **not** a new divergence; folds into the existing unified-identifier cluster |
| **C-I2** | INFO | DESIGN-Q | security-analysis threat-table names a specific vendor AI (`Compromised Claude`) among otherwise-generic actor rows — altitude question for a vendor-neutral standard (couples C-M1) |
| **C-I3** | INFO | — | ✅ A4 `16-byte truncation = 128 bits` describes the audit-**record** hash, a different artifact from the conformance vector's 64-hex **action** hash — three distinct hash surfaces, no contradiction; policy simply not normatively pinned |

**8 actionable** (0H / 1M / 7L) split **6 AUTONOMOUS / 4 DESIGN-Q / 3 CROSS-TRACK** (C-L2 and C-M1 each carry both an autonomous lever and a design-Q; B-L1 splits autonomous/cross-track), **plus 6 INFO**.

**4 fully refuted** (recorded for honesty / to prevent re-litigation, see §D).

---

## §A — Internal-Consistency Findings (within & across the pair)

### A-L1 (LOW, AUTONOMOUS) — Three tiers defined, only two analyzed

The impl-guide defines **three** tiers: Tier 1 Observational (line 9), Tier 2 Authorization (line 40), **Tier 3 Training Evaluation** (lines 63–83, with its own T3 trust integration at line 82), and the Trust Integration table (lines 105–109) lists Training as a first-class trust-bearing tier. The security-analysis contains attack-vector sections for only **Tier 1** (line 7) and **Tier 2** (line 66), and its "Cross-Tier Concerns" C1/C2/C3 (lines 121–139) span only Tier 1↔Tier 2 (e.g. line 124 *"Present Tier 1 … as Tier 2"*, line 129 *"Import malicious Tier 1 records into Tier 2"*). **Tier 3 has zero threat content.**

- **Routing**: AUTONOMOUS. The security-analysis already implicitly scopes itself Tier-1/Tier-2 at line 5 (*"audit trails and (in Tier 2) authorization"*); a one-line explicit scoping note ("This analysis covers Tier 1 and Tier 2; the Tier 3 Training threat model is out of scope — training runs in a controlled, non-adversarial environment") closes the gap inside the file. Authoring an *actual* Tier-3/HRM threat model would be CROSS-TRACK.
- *Severity note*: finders rated MEDIUM; moderated to LOW — a coverage gap in descriptive prose is hygiene-level, not a cross-spec divergence.

### A-L2 (LOW, AUTONOMOUS) — `R6Status States` subsection labels are inconsistent

The §"R6Status States" heading (line 85) is bare, and its three subsections are `### Hardbound (Authorization)` (line 87), `### Web4 Plugin (Observational)` (line 93), and `### SAGE Training` (line 98). The first two carry the tier name in a parenthetical; **the SAGE row omits it** and matches neither pattern (its tier section is `Tier 3: Training Evaluation`, line 63). There is also no lead sentence stating that the three blocks are **distinct per-tier lifecycles**, not one shared state machine.

- **Routing**: AUTONOMOUS. Normalize the SAGE heading to the parenthetical convention and add one clarifying lead sentence under line 85. Pure hygiene.
- *Severity note*: the finder's "reader must mentally re-map" framing was over-stated (the parentheticals at lines 87/93 already supply the mapping); scope tightened to the line-98 asymmetry + missing lead sentence.

### A-L3 (LOW, AUTONOMOUS) — Hardbound R6Status states need a "tier-internal, not canonical" clarifier

impl-guide lines 89–90 (Hardbound): `Pending → InProgress → Approved/Rejected → Completed/Failed ↳ Cancelled`. The tokens `Approved`/`Rejected`/`Completed`/`Failed` exist in **neither** the canonical `r6-framework.md` §7 Result statuses (`success`/`failure`/`error`) **nor** the SDK `ActionStatus` enum (`r6.py:75-84` = `PENDING/VALIDATED/IN_PROGRESS/SUCCESS/FAILURE/ERROR/CANCELLED`). **This is *not* a contradiction** — the block is explicitly labeled "Hardbound (Authorization)," a private-repo approval lifecycle the core spec does not own (this is exactly why the four "contradiction" framings were refuted, §D). But because the shared heading is "R6Status" and the SDK independently has `pending`/`in_progress`/`cancelled`, a casual reader could mistake `Approved/Rejected/Completed` for canonical statuses.

- **Routing**: AUTONOMOUS. Add a one-line note under §"R6Status States" that these are tier/product-specific lifecycle states distinct from the canonical R6 Result status set `{success, failure, error}` defined in `r6-framework.md` §7. This is the **constructive residue** of the four refuted overcalls — it inoculates against a future auditor re-manufacturing the (non-)contradiction, without reproducing any hardbound internal (the states are already printed in the file).

---

## §B — Cross-Spec Findings

### B-L1 (LOW, AUTONOMOUS) — Neither file references the canonical `r6-framework.md`

The impl-guide References (lines 134–139) list `web4-standard/README.md`, `hardbound/README.md`, the moltbot `ARCHITECTURE.md`, and the SAGE `README.md` — but **not** `r6-framework.md`, the spec that defines the very R6 equation the impl-guide restates at line 5. The security-analysis References (lines 190–194) cite only external standards (OWASP, NIST SP 800-92, TPM 2.0). A grep for `r6-framework` in both files returns nothing. The one good intra-pair link exists (impl-guide line 132 → security-analysis), but the pair is orphaned from its normative anchor.

- **Routing**: AUTONOMOUS (forward direction). Add a `- R6 Framework (normative): r6-framework.md` pointer to the impl-guide References, and an anchor in the security-analysis (its Attack Surface Overview and/or References) to `r6-framework.md` (its §4 R6 Security Properties is the natural normative baseline). The **reciprocal** pointer *from* `r6-framework.md` §10 → these two files lands in `r6-framework.md` and is **CROSS-TRACK** (it has a curated §10 References listing six siblings but omitting both R6-family companions).
- *Severity note*: moderated MEDIUM→LOW — a missing additive cross-reference is hygiene; the files do not *contradict* `r6-framework.md` on any value.

### B-L2 (LOW, CROSS-TRACK) — `README.md` index is broken for the entire r6 doc-family

`web4-standard/README.md:83` is the only r6 entry in the index and points to `core-spec/r6-framework-legacy.md` — a file that **does not exist** anywhere in `web4-standard` (only `r6-framework.md`, `r6-implementation-guide.md`, `r6-security-analysis.md` exist). So the index simultaneously (a) dangles a pointer to a missing file and (b) omits **all three** live r6 docs, including both audited files. They are undiscoverable from the standard's table of contents.

- **Routing**: CROSS-TRACK. Fix the stale `r6-framework-legacy.md` pointer and add index entries for the three live r6 docs. The edit lands in `README.md`, not in either audited file.

### B-I1 (INFO, CROSS-TRACK) — `security-framework.md` ↔ `r6-security-analysis.md` reciprocal cross-ref still missing (C31-A-L3 follow-through)

C31-A-L3 trimmed `security-framework.md`'s abstract, noting `r6-security-analysis.md` *"already supplies an R6-scoped threat model."* Confirmed: `security-framework.md` (97 lines) contains **zero** reference to R6 or to `r6-security-analysis.md`, and `r6-security-analysis.md`'s References are external-only. `r6-security-analysis.md` does supply a real threat model (lines 55–64 Tier-1 threat table; lines 121–139 Cross-Tier Concerns).

- **Routing**: CROSS-TRACK + forward-awareness. If/when the C31 security-considerations work proceeds, a one-line `See r6-security-analysis.md for the R6-scoped threat model` from `security-framework.md` closes the loop. That edit is in the C31 file, not an r6 file. **No action inside the two audited files.**

### B-I2 (INFO) — ✅ Positive confirmation: R6 grammar is coherent across pair / framework / SDK / vectors

impl-guide line 5 restates the R6 equation *"Rules + Role + Request + Reference + Resource → Result"* **verbatim** matching `r6-framework.md:14`; all three tier component-breakdowns use the six canonical component names. `r6-framework.md` §7 (lines 515–517) defines `error` (pre-execution) vs `failure` (execution-time) plus `success`, matching SDK `ActionStatus` `SUCCESS/FAILURE/ERROR`. The conformance vectors (`r6-r7-actions.json`) assert `validation_errors`/`error_contains`/reputation deltas/`hash_length`, **never** R6 Result-status strings — so the descriptive tier prose makes no falsifiable claim against them. *(The `"status": "completed"` at `r6-framework.md:563` is a nested `refund` settlement sub-status, not an R6 Result status — not a contradiction.)* Recorded to prevent a future auditor manufacturing a false §4/§7 contradiction.

### B-I3 (INFO) — security-analysis attack catalog is consistent with but unmapped to `r6-framework.md` §4

`r6-framework.md` §4 enumerates five Security Properties (Determinism / Non-repudiation / Resource Bounds / Role Isolation / Atomic Settlement). The security-analysis organizes by attack vector and never references them, though the mappings are clean (B3 ATP Drain ↔ §4.3 Resource Bounds; B2 Role Escalation ↔ §4.4 Role Isolation; A2/A6 ↔ §4.2 Non-repudiation). The two are **consistent** (no contradiction).

- **Routing**: optional/INFO. An additive per-vector mapping to the §4 property each attack threatens would improve traceability; not required.

---

## §C — Primitive-Clustered Pass (`auditor-blindspot-pattern`)

Re-reading through the **altitude/placement** and **identifier-form** lenses surfaces the single root finding (C-M1) of which most §A/§B items are downstream symptoms, plus the confirmations bounding coverage.

### C-M1 (MEDIUM, DESIGN-Q) — ⭐ Placement/altitude root: descriptive impl-status docs in a normative directory, no non-normative marker

Both files live in `web4-standard/core-spec/` (the normative home) yet are substantively **implementation surveys**, not protocol grammar. Decisive evidence:
- **Zero RFC-2119 keywords** in either file (grep: 0 `MUST`/`SHALL`/`SHOULD`/`REQUIRED` each), vs `r6-framework.md`'s §6 obligations.
- Tiers map to specific repos including a **private** one: impl-guide line 41 *"Tier 2: Authorization (Proprietary) … hardbound/hardbound-core"*; line 12 *"moltbot/extensions/web4-governance … ← Live implementation"*; line 64 *"HRM/sage/raising/tracks/training"*.
- Dated, PR-numbered external facts: line 34 *"Moltbot Integration (January 2026):"*, lines 35–36 *"PR #1 … PR #2 …"*.
- References (lines 134–139, 190–194) point at other repos' READMEs / external standards.
- Neither carries a Status/Informative banner. *(Note: `r6-framework.md` and `security-framework.md` also lack a status banner, so this is a soft corpus convention, not an enforced norm — the placement question, not the banner per se, is the real issue.)*

This is the `auditor-blindspot` altitude root. It is **not** a normative contradiction (hence not HIGH), but it is more than wording hygiene: directory placement determines what conformance the corpus may later assert against these files, and they reference non-public material that will age.

- **Routing**: **DESIGN-Q** (record, not resolve). Operator must choose: **(a)** relocate to a `docs/` or `implementation/` / `guides/` subtree as non-normative implementation notes; or **(b)** keep in `core-spec/` but add an explicit *"Status: Informative — non-normative implementation survey; the normative R6 spec is `r6-framework.md`"* banner and strip live-status. **Autonomous companion**: adding such a banner is itself a no-design-decision in-file edit and would immediately defuse the A-L3 / C-L1 / C-L2 misread risks — but the *relocate-vs-reframe choice* is the gating operator decision. Record as **`carry-C32-placement`**.

### C-L1 (LOW, AUTONOMOUS) — Time-bound live-status phrasing will silently stale

impl-guide line 12 *"← Live implementation"*, line 34 *"(January 2026)"*, lines 35–36 *"PR #1 … PR #2 …"*; security-analysis line 178 *"Integrate with policy engine (done)"*. These are point-in-time, externally-unverifiable status assertions; git confirms both files have been untouched since Jan 2026 while siblings advanced to May/June.

- **Routing**: AUTONOMOUS. Demote to undated, repo-neutral wording (e.g. *"PR #1/PR #2 (January 2026)"* → *"as of early 2026"*; *"← Live implementation"* → neutral phrasing). This only **removes** decaying status assertions — it touches no moltbot/hardbound internals. Wording couples to the C-M1 banner decision; per BC#13, date-staleness alone is INFO, but here it is coupled to verifiable-status claims, so LOW.

### C-L2 (LOW, AUTONOMOUS relabel + DESIGN-Q record) — Orphan identifier schemes coined only here

The impl-guide "ID Formats" table (lines 121–128) introduces `r6:{uuid8}` (line 125), `audit:{uuid8}` (line 126), and `web4:session:{hash12}` (line 127) — a corpus grep finds these **bare** forms only here; they are not registered in `data-formats.md` (the declared identifier SSOT: `w4id = "did:web4:" method-name ":" method-specific-id`, line 19) nor in `r6-framework.md` nor any conformance vector. *(Distinct from the `lct:web4:` row — see C-I1.)* `data-formats.md:27` declares its method list non-exhaustive/extensible, so these are **unregistered**, not contradictory.

- **Routing**: **AUTONOMOUS** lever — relabel the table as *"illustrative implementation-specific formats, not canonical Web4 identifier schemes"* (makes the descriptive doc honest about its own non-canonical status; no design decision). **DESIGN-Q** record — whether R6-request / audit-record / session-token identifiers *should* have canonical schemes under the W4ID grammar folds into the existing **`carry-C28/C29/C30` unified-identifier** cluster.

### C-I1 (INFO, DESIGN-Q) — ✅ Fairness PASS: `lct:web4:{type}:{id}` is corpus-consistent, not a new divergence

The lens asked whether the impl-guide's `lct:web4:{type}:{id}` (example `lct:web4:root:abc123`, line 128) is a *new* identifier divergence from the `did:web4:`/`w4id:` forms. **It is not.** `r6-framework.md` itself uses `lct:web4:<type>:<id>` ~16 times (agent/client/entity/oracle/role/society/subauthority/witness); the conformance vectors use `lct:web4:society:test`, `lct:web4:agent:alice`; and the specific `root` type segment is canonical — `multi-device-lct-binding.md:163,262` use `lct:web4:root:mb32:…` and SDK `tests/test_binding.py` uses `root_lct_id="lct:web4:root:…"`. So the impl-guide is **in-family** with the rest of the R6 corpus.

- **Routing**: INFO + DESIGN-Q record. Do **not** open a fresh identifier fight on the `lct:` form or single out the impl-guide. Any `lct:web4:` vs `did:web4:`/`w4id:` normalization is the spec-wide `carry-C28/C29/C30` decision and must be corpus-wide + SSOT-driven.

### C-I2 (INFO, DESIGN-Q) — Vendor-named threat actor (`Compromised Claude`)

The security-analysis Tier-1 threat-model table (line 62) has a row `| Compromised Claude | Can bypass hooks | No |`, among otherwise-generic actor classes (Remote attacker, Local user, Malicious plugin). For a vendor-neutral standard this is an altitude question; *however*, the section is explicitly scoped to the Tier-1 `web4-governance` plugin deployment (line 7), whose enforcement surface **is** Claude Code's hook system — so the row is internally consistent with the doc's own deployment framing.

- **Routing**: INFO + DESIGN-Q (couples C-M1). If C-M1 resolves to "keep as informative implementation note," the vendor name is acceptable in context; if it resolves to "normative," generalize to *"compromised agent runtime."* Wording therefore couples to the placement decision; record, don't unilaterally rename.

### C-I3 (INFO) — ✅ Hash-truncation figures describe different artifacts; no contradiction

security-analysis A4 (line 38) *"16-byte truncation is still 128 bits"* concerns the **audit-record** hash chain (impl-guide line 30, *"Hash-linked JSONL audit chain"*); the conformance vector `r6-chain-001` (`r6-r7-actions.json:135-141`) pins the canonical **action** hash at full 64-hex / 256-bit; and `web4:session:{hash12}` (line 127) is a third, 12-hex surface. Three distinct hashes — **no internal contradiction**. The only observation: no normative file pins a canonical hash/truncation policy, so A4's bit-strength figure stands without a normative anchor.

- **Routing**: INFO / forward-awareness. No change inside the two files.

---

## §D — Refuted Candidates (recorded for honesty / to prevent re-litigation)

The adversarial pass **fully refuted 4 candidates**. All four are recorded so a future turn does not "fix" a non-defect:

1. **Hardbound `R6Status` states contradict canonical §7 + SDK enum** (three near-identical variants from the internal / sdk-sec / identifiers lenses). **REFUTED** — the states are explicitly tier-labeled (`### Hardbound (Authorization)`, line 87) proprietary-lifecycle prose; scoring them against the SDK `ActionStatus` / `r6-framework.md` §7 is the exact descriptive-vs-normative category error the binding discipline forbids. The doc deliberately lists three *divergent* per-tier flows to **show** the tiers differ; it never claims they are canonical. *(A useful by-product: the verifiers corrected the audit's own ground-truth lead — `IN_PROGRESS` and `CANCELLED` **do** exist in the SDK enum at `r6.py:80,84`; only `Approved/Rejected/Completed/Failed` are absent, and they are correctly-attributed private-repo labels.)* The only legitimate residue — a clarifying note — survives separately as **A-L3**.
2. **security-analysis B6 replay mitigation is redundant with the canonical §1.3 nonce.** **REFUTED** — B6 describes the `hardbound-core` (private) processor's *enforcement* roadmap ("check ID uniqueness in processor"); a wire-grammar field existing in `r6-framework.md` §1.3 does not mean a given implementation enforces uniqueness. The "divergent vocabulary" claim is also false: the framework nonce value is literally `"unique_request_id"`, identical in concept to B6's "unique request IDs (uuid)." No defect.
3. **A4 truncation is really 8 bytes / 64 bits (per SDK `hexdigest()[:16]`).** **REFUTED** — rests on an unverified assumption about an external/private repo's hashing; the SDK `[:16]` is an *identifier* (`r7:` action-id), not the audit-record content hash A4 describes; and the one authority on hash length (vector `r6-chain-001`) asserts the canonical hash is full 64-hex, untruncated. The finder itself recommended "do NOT edit on assumption." No defect.

*(The 4th refuted item is the third Hardbound-state variant noted in (1).)*

---

## Disposition Ledger (for the next remediation turn)

**AUTONOMOUS (6)** — fixable inside the two r6 files alone, no design decision:
- **A-L1**: add a Tier-1/Tier-2 scoping note to `r6-security-analysis.md` (Tier-3 threat model out of scope).
- **A-L2**: normalize the §"R6Status States" SAGE heading + add a "these are per-tier lifecycles" lead sentence.
- **A-L3**: add a clarifier that the Hardbound states are tier-internal, distinct from canonical `{success, failure, error}` (`r6-framework.md` §7).
- **B-L1** (forward direction): add a `r6-framework.md` cross-ref to both files' References.
- **C-L1**: demote time-bound live-status wording to undated, repo-neutral phrasing.
- **C-L2** (relabel): mark the impl-guide ID-Formats table "illustrative implementation-specific formats, not canonical Web4 identifier schemes."
- *(Companion to C-M1: adding an Informative banner is autonomous, but its exact wording depends on the placement decision — defer to the design-Q.)*

**DESIGN-Q (4)** — operator canonicity, *recorded not resolved*:
- **C-M1 / `carry-C32-placement`** (the root): do `r6-implementation-guide.md` + `r6-security-analysis.md` belong in `core-spec/` (relocate to a non-normative subtree) or be reframed in place as Informative? Affects what conformance the corpus may assert against them.
- **C-L2 (scheme question)**: should `r6:` / `audit:` / `web4:session:` identifiers get canonical schemes under the W4ID grammar? → folds into `carry-C28/C29/C30` unified-identifier cluster.
- **C-I1**: `lct:web4:` vs `did:web4:`/`w4id:` corpus-wide normalization → same unified-identifier cluster (do not single out the impl-guide).
- **C-I2**: vendor-name (`Compromised Claude`) wording — couples to C-M1's normative-vs-informative resolution.

**CROSS-TRACK (3)** — fix/verify lands in another artifact:
- **B-L2**: fix `README.md` index (stale `r6-framework-legacy.md` pointer + add the three live r6 docs).
- **B-L1 (reciprocal)**: add an Informative-References pointer in `r6-framework.md` §10 → the impl-guide + security-analysis.
- **B-I1**: add a `security-framework.md` → `r6-security-analysis.md` cross-ref (C31-A-L3 follow-through; gate on the same placement/home decision).

---

*Audit produced under Autonomous Session Protocol v2 — slot `000000`, LEAD voice. Read-only: no spec, SDK, or test-vector files were modified this turn. With C32, first-pass internal-consistency + cross-spec coverage of the core-spec normative corpus is **complete**. Remediation of the C32 AUTONOMOUS findings is the next alternation turn. Method: 5-lens multi-agent fan-out + adversarial refute-by-default verification (36 candidates → 32 surviving → 4 refuted; 17 severities moderated downward), per `feedback_audit_workflow_adversarial_verify.md`.*
