# i™ Lineage Registry — Corrected Evidence State

## 1. Measured inventory

This graph represents accounting categories and measured model inventory. It is
not presented as parent-child training ancestry.

```mermaid
graph TD
    Registry["Measured Registry"]
    Native["Native inventory<br/>11 architectures<br/>118,378,249 dedup"]
    Materialized["Native materialized accounting<br/>25 trained lanes<br/>274,743,332 parameters"]
    Adapter["Adapter inventory<br/>QLoRA: 10,092,544 parameters"]
    Catalog["External catalog<br/>Addressable metadata only"]

    Registry --> Native
    Native --> Materialized
    Registry --> Adapter
    Registry --> Catalog

    Native --> iFemto["iFemto Native<br/>526,473"]
    Native --> iZeroGRU["iZero GRU<br/>5,659,904"]
    Native --> iZeroRoPE["iZero RoPE<br/>4,864,256"]
    Native --> iZeroTransformer["iZero Transformer<br/>4,903,168"]
    Native --> iZeroNAR["iZero NAR<br/>4,935,936"]
    Native --> iRiXP["iRiXP<br/>921,856"]
    Native --> Buddy4E["Buddy 4E<br/>5,319,424"]
    Native --> CODED["CODED MiniLM<br/>22,713,216"]
    Native --> SmallCODED["small-CODED MiniLM<br/>17,389,824"]
    Native --> iPU["iPU checkpoint<br/>25,576,448"]
    Native --> iFemtoLlama["iFemto-Llama-Native<br/>25,567,744"]

    Adapter --> QLoRA["QLoRA adapter<br/>10,092,544"]

    classDef default fill:#0f1622,stroke:#e8a33d,color:#e8eaf0;
    classDef native fill:#1a2530,stroke:#4fd69c,color:#e8eaf0;
    classDef adapter fill:#2a1a2a,stroke:#e8a33d,color:#e8eaf0;
    classDef hold fill:#1a1a2a,stroke:#5a6480,color:#aeb6ca;
    class Native,Materialized native;
    class Adapter,QLoRA adapter;
    class Catalog hold;
```

The materialized value is an accounting total across 25 trained lanes. It is
not the sum of the 11 architecture nodes displayed above and must not be
inferred from this diagram.

## 2. Training-lineage DAG state

Actual training ancestry is held until complete evidence exists. Eight-character
hash prefixes are display labels only and are never accepted as identifiers.

```mermaid
graph TD
    Inventory["Measured checkpoint inventory"]
    Evidence["Required lineage evidence"]
    Validator["i_lineage_dag_validator.py"]
    Hold["HOLD<br/>full hashes and parent edges incomplete"]
    Pass["PASS<br/>deterministic DAG commitment"]

    Inventory --> Evidence
    Evidence --> Validator
    Validator -->|missing or invalid| Hold
    Validator -->|all invariants pass| Pass
```

No model-to-model edge may be drawn until its complete child record contains:

```json
{
  "checkpoint_sha256": "<64-character checkpoint hash>",
  "parents": ["<complete parent checkpoint hash>"],
  "parent_set_sha256": "<SHA-256 of canonical sorted parent array>",
  "lineage_id": "<stable lineage identifier>",
  "lane_id": "<stable lane identifier>",
  "generation": 1,
  "classification": "NATIVE",
  "origin": "DERIVED",
  "native_parameters": 1,
  "tensor_count": 1,
  "training_receipt_sha256": "<64-character hash>",
  "dataset_manifest_sha256": "<64-character hash>",
  "trainer_source_sha256": "<64-character hash>",
  "training_config_sha256": "<64-character hash>",
  "evaluation_receipt_sha256": "<64-character hash>",
  "lineage_node_sha256": "<commitment calculated without this field or signature fields>"
}
```

Root nodes use `generation: 0`, an empty `parents` array, and an origin of
`FROM_SCRATCH` or `EXTERNAL_BASE` as appropriate.

## 3. Correct commitment rules

1. Normalize and sort the complete parent checkpoint hashes.
2. Compute `parent_set_sha256` from the canonical JSON parent array.
3. Remove `lineage_node_sha256`, `ed25519_signature`, and `signature_key_id`
   from the node before calculating its commitment.
4. Canonically serialize every remaining field.
5. Compute `lineage_node_sha256 = SHA256(canonical_node_bytes)`.
6. Verify every parent exists in the submitted graph.
7. Reject cycles, dangling parents, generation gaps, duplicate checkpoint
   nodes, duplicate node commitments, and duplicate lineage-lane generations.
8. Reject any attempt to reclassify external or adapter ancestry as native.

Input ordering is irrelevant. A legitimate DAG may branch or merge when the
required transition or merge receipt is present. The validator rejects
unauthorized ancestry, not all branching.

## 4. Current receipt

```json
{
  "artifact": "iLineage_Registry_State_v1",
  "status": "INVENTORY_MEASURED_LINEAGE_HOLD",
  "registry": {
    "native_architectures": 11,
    "native_dedup": 118378249,
    "native_materialized_lanes": 25,
    "native_materialized": 274743332,
    "adapter": 10092544,
    "catalog_counted_as_native": false
  },
  "lineage": {
    "actual_parent_child_edges_complete": false,
    "complete_checkpoint_hashes_attached": false,
    "dag_validator_receipt_available": false,
    "enforced": false
  },
  "perimeters": {
    "1T_native": "NOT_REACHED",
    "50T_native": "NOT_REACHED",
    "100T_native": "NOT_REACHED"
  }
}
```

The state may change to `UNBROKEN_CRYPTOGRAPHIC_ANCESTRY` only after the real
DAG document passes `i_lineage_dag_validator.py` and produces complete graph
and sink commitments.