§4 Analysis

4.1 What the realistic corpus approaches

Nothing. All five quantities sit far below their §7 budget, across every one of the 90 real records measured:

The record carrying the corpus's own maximum on (a), (b) and (c) simultaneously is l3-full-1-1.json — unsurprisingly, since it was adapted from the published standards/ver/1.1-draft/example-record-lineage.json (§3's two "16,323 / 985 / 3,072" rows are, in fact, the same record measured twice: once as a fixture, once as the published example). The richest record this project has ever assembled for its own conformance suite is still two to three orders of magnitude below every MUST NOT, and the entry-count SHOULD NOTs — the two quantities most exposed to a merely wide record rather than a heavy one — have the least headroom of the five and are still at under 5%.

4.2 What the synthesized worst-realistic cases show

The vector-matrix and pooled-raw-segment results (§3) test the hypothesis directly rather than by extrapolation. A 768-dimension fp32 inline vector — the largest single embedding any space this project ships can produce, carried the most expensively (vector_b64 rather than by-reference) — decodes to 3,072 bytes, exactly 3.0 KiB: 0.049% of quantity (c)'s budget. Pooling every distinct real preserved-metadata byte string this repository holds — every XMP packet, every ICC and C2PA stand-in, every IPTC-IIM fragment, across 90 fixtures and three published examples, plus all eight real EXIF blobs the determinism test suite generates — sums to 6,438 decoded bytes: 0.10% of quantity (b)'s budget, and that is the entire corpus's preserved-metadata inventory in one place, not one record's.

Combining both — the richest real fixture, its raw segments replaced by that entire pooled inventory, its embeddings extended with all ten vector-matrix cases — produces a record with 19 raw segments and 13 embeddings, deliberately more of both than any real fixture here carries by a wide margin. It still lands at 0.61% / 0.10% / 0.10% of (a) / (b) / (c). Building the largest record this repository's own real bytes can produce does not get within two orders of magnitude of any MUST NOT.

4.3 What would approach the limits, and why by-reference carriage is the pressure valve

Quantity (c). Reaching 6 MiB inline requires 786,433 components at the documented proxy rate — 1,536× the 512-dimension shipped space and 1,024× the 768-dimension one (§3, "Threshold arithmetic"). No space this project ships, and no space named in any fixture or published example, is within three orders of magnitude of that width. What would approach it is a substantially higher-dimensional space (a hypothetical multi-thousand- or million-component representation) or an exotic high-precision inline encoding — and that is precisely the case §7's own MUST already routes off the inline path: a Producer whose vector would exceed (c) MUST use vector_ref. The cap is not discouraging something that nearly happens on real shipped spaces; it is structurally excluding a class of embedding this project has never produced from ever validating inline.

Quantity (b). The realistic corpus's own raw segments are all small — the pooled inventory's 19 distinct segments average 339 decoded bytes, and reaching 6 MiB that way would need on the order of 18,568 of them in one record (§3), roughly 6,000× the 3 raw segments the busiest real fixture here carries. That is not how (b) gets approached in practice. A few large segments are the realistic pressure case: a full-resolution ICC profile commonly runs into the hundreds of kilobytes in the wild, and a rich C2PA manifest carrying an embedded thumbnail or a certificate chain can be larger still. This project's own ICC and C2PA bytes — 30 and 602 octets for ICC, 64 and 103 octets for C2PA — are deliberately small illustrative stand-ins (errata E26; the one larger, 3,144-octet ICC blob in l3-full-1-1.json is carried by reference, not inline, which is itself the pressure valve already in use). This repository does not contain a large real-world metadata blob to measure quantity (b)'s realistic pressure case, and that absence is itself a finding, stated plainly in §5.

Quantity (a). The document budget is the binding one precisely because it contains the other two (§7's own framing: "(a) is the binding constraint on the whole document"). Nothing built here — real or synthesized — came within two orders of magnitude of it, and reaching it deliberately would mean stacking large raw segments and large inline vectors simultaneously, which (b), (c) and the SHOULD NOT caps on (d) each push back on independently, before (a) itself would ever bind. metadata.raw[].bytes_ref and embeddings[].vector_ref are the same mechanism in both directions: already observed in 3 and 56 of the 90 realistic-corpus records respectively (§3, "Corpus composition"), and structurally mandatory — not merely available — once a Producer's payload would cross (b) or (c).