# CQR Path Audit — Census Conflict Addendum v1

Addendum to `claude-code-prompt-cqr-path-audit.md`, same rules: read-only hash-verified copies, nothing staged, no ledger/tracker/findings-doc updates. Report only, no conclusions. Full census: `census_v1.json`. Copies used: `scratch/cqr/census_copies/{pristine,primary,condition_c}/`, each hash-verified unchanged before/after (`.ready` excluded from the hash, same justification as the original audit: unconditionally rewritten by any server startup, never touched here since this script never launches a server).

## (1) Identical edge_type census, three datadirs

| edge_type | pristine | primary | condition_c |
|---|---|---|---|
| concept_relation | 699 | 549 | 0 |
| semantic | 2771 | 3334 | 2688 |
| consolidated | 628 | 628 | 628 |
| **total** | **4098** | **4511** | **3316** |

`custom_edge_type` breakdown (a metadata sub-field of `edge_type=semantic` and `edge_type=concept_relation`; `consolidated` carries no `custom_edge_type`):

| custom_edge_type | pristine | primary | condition_c |
|---|---|---|---|
| concept_relation | 699 | 549 | 0 |
| entity_coref | 1650 | 1583 | 1583 |
| structural_adjacency | 1121 | 1105 | 1105 |
| consequence | 0 | 646 | 0 |
| None (consolidated) | 628 | 628 | 628 |

`entity_coref + structural_adjacency + consequence` sums to the `edge_type=semantic` total in every column (pristine 1650+1121+0=2771; primary 1583+1105+646=3334; condition_c 1583+1105+0=2688).

## (2) Condition-c prune's own recorded output

`condition_c_manifest.json` (written by `build_condition_c.py`, source datadir `cqr_datadir_primary`):

```
"deleted_types": ["concept_relation", "consequence"],
"edges_pruned": 1195,
"edge_count_before": 4511,
"edge_count_after": 3316,
"type_counts_before": {"concept_relation": 549, "entity_coref": 1583, "structural_adjacency": 1105, "consequence": 646, "null": 628},
"type_counts_after": {"entity_coref": 1583, "structural_adjacency": 1105, "null": 628}
```

`type_counts_before`/`_after` are computed by iterating `store._edge_metadata.values()` and keying on `metadata.get("custom_edge_type")` (`build_condition_c.py:81-84` for before, `:90-93` for after), not on `edge_type`. `1195 pruned = 549 concept_relation + 646 consequence`, matching this addendum's own independent census of both `primary` and `condition_c` exactly (part 1, above).

## (3) Where "646 consequence edges" is emitted in source

No single ingest-time acceptance check emits the literal number 646 as a runtime stat. Three distinct, separately-verified numbers are in play:

- **`run_consequence_lift`** (`engram_store.py:5612-5702`) is the sole edge-writing code for this population: at `engram_store.py:5691` it calls `create_typed_edge(s, d, edge_type="consequence", weight=weight, bidirectional=True, metadata={...})` inside a nested loop over `cause_engrams × effect_engrams` pairs for each causal-predicate relation. Its own `stats["edges_created"]` counter increments once per loop iteration (`engram_store.py:5701`) — a count of **iterations**, not final stored edges. The actual recorded run (`lift_and_verify_results.json`, key `the_one_lift_stats`) shows `"edges_created": 378`.
- **`create_typed_edge`** (`engram_store.py:5258-5324`) stores the string `edge_type` argument into `metadata["custom_edge_type"]` (`engram_store.py:5316`) while writing the actual graph-level `EdgeType` enum field as `EdgeType.SEMANTIC` unconditionally (`engram_store.py:5320`) — there is no `EdgeType.CONSEQUENCE` member anywhere in `models/__init__.py`'s `EdgeType` enum. With `bidirectional=True`, each of the 378 iterations calls `_write_edge` up to twice (forward and reverse), so up to 756 directed edge records could result from 378 iterations.
- **646** is a **post-hoc stored-edge census**, not a lift-time emission: first recorded in `condition_c_manifest.json`'s `type_counts_before.consequence` field (`build_condition_c.py:81-84`, direct iteration over `primary`'s loaded `_edge_metadata`, keyed on `custom_edge_type`), independently reproduced in this addendum's own fresh census (part 1, above; `census_edges.py`), and cited a third time in `aura-persona/consequence-question-retrieval-preregistration-v0_1.md` line 299 ("v2 acceptance record") and `ngramdb/scratch/cqr/checkpoint_during_ingest.md` (Item 9, "Writer-tagged census"), both attributing it to the same single call site (`engram_store.py:5691`) and both stating the 378→646 gap is loop-iteration-count vs. final-stored-edge-count, reconciled there as 413 new-key writes + 233 key-collision overwrites of pre-existing edges = 646 (arithmetic reconciliation, not independently re-traced edge-by-edge in that document, and not re-traced edge-by-edge here either).