# Merkle claim ledger

| Claim | Classification | Evidence or boundary |
|---|---|---|
| Empty/leaf/internal prefix construction and split rule | Primary technical source | RFC 9162 sections 2.1.1/2.1.3 |
| Path direction derives from exact index/tree size | Primary algorithm plus authored implementation | RFC proof definitions and143 literal independent outputs |
| Three full G entries produce34ad17...3192 | Independent authored calculation | Shared pre-core framing vectors, pinned unchanged |
| Correction pair remains one atomic leaf | Shared D30 contract choice | Complete group G framing; three leaves contain four journals |
| Current core accepts opaque bytes | Explicit implementation boundary | No source/framing parser; even invalid financial byte strings can have valid inclusion |
| Lowercase hex/string counts/16KiB/4096 limits | Portable implementation choice | Exact data contract and boundary tests |
| Native hash runtime behavior | Official runtime documentation | Python 3.11 hashlib and Node 22.22 WebCrypto |
| Missing trust is indeterminate | Verification policy choice | Root must be independently supplied; no embedded self-trust |
| A pass is byte inclusion only | Trust boundary | Financial validity, completeness, freshness, non-equivocation, signature and anchor separate |
| All Cedar records are synthetic | Teaching input | No real customer records or production keys |
| Named historical case not useful | Documented decision | Reusable complete byte/root chronology not supplied |