BAP-10 requirement-to-conformance map

This is the BAP-10 acceptance artifact: the traceability map from every normative requirement identifier (per ADR 0007, REQ1-<SURFACE>-<tag> for the normative profile and REQ1-EVO-* for the evolution contract) to the conformance corpus cells that prove it.

The BAP-10 acceptance bar (ADR 0006 §3; docs/ROADMAP.md BAP-10): every MUST maps to at least one conformance applicability cell (surface × class) or a named falsifiable gap, with the mapping published. A cell satisfies §3 only when it is populated (the (surface, class) pair has at least one executed case in priv/conformance/v1/corpus/index.json). n/a and gap rows do not satisfy §3 on their own; they are recorded with a falsifiable reason and are reviewed at closeout against the ADR 0005 n_a criterion (an input-algebra impossibility, not a process/deployment constraint — a process-constraint reason is the self-contradiction ADR 0005 warns about and is a blocking finding).

Schema

Corpus revision for every row: bounded-authority-protocol-v1-conformance-corpus-index. A successor-corpus slice that changes the applicability matrix MUST re-walk this map; the revision qualifier makes a stale mapping a detectable drift rather than a silent false claim. See § Maintenance.

CORE — profile-level invariants

JSON — decoder algebra (json.decode, jcs.encode)

B64 — base64url (base64url.decode)

HEADER — protected headers (decode_grant, decode_proof, verify_grant, jwk surfaces)

CLAIM — grant/proof claims (verify_grant, check_envelope)

SELECTOR — selector algebra (verify_grant, check_envelope)

URI — URI normalization (uri.normalize, proof_signing_input)

SIGNING — signing and digest inputs (grant_signing_input, proof_signing_input, request_digest)

VERIFY — public verification contract (verify_grant, check_envelope)

BOUNDS — hard maxima (bounds.new)

LOCATOR — untrusted key locator (untrusted_key_locator)

CHAIN / EXPORT — consumption chain and anchored export (check_chain, verify_*, encode_*)

EVO — evolution contract (standards-track.md)

These requirements govern the evolution mechanism, which lives above the wire format — they are not exercised by the v1 conformance corpus (the corpus verifies the current closed profile, not successor-major behavior, which does not yet exist). Each is recorded as a gap with a falsifiable input-algebra reason (per the gap gate, ADR 0005 n_a criterion): the current corpus's input algebra cannot express a successor contract-major, a deprecation window, or an erratum, because none of those artifacts exist yet in v1. They become mappable when a successor-major corpus ships; the corpus-revision qualifier + re-walk obligation (§ Maintenance) makes that the successor slice's job.

What a populated cell does and does not prove (reading guide)

A populated mapping row certifies that the named conformance cell directly exercises the requirement's named trigger — i.e., the cell's defect IS the requirement's violation (or, for a closed-set requirement, one class of it). This section exists because several requirements are exercised only partially by the current v1 corpus, and the map must not overstate that as full proof. Three categories a standards reader must distinguish:

1. Direct proof — the cell's defect is exactly the requirement's violation (e.g. REQ1-CLAIM-v ← verify_grant.invalid_claim=1, where the case mutates the v claim). The cell directly proves the requirement. A populated row certifies this where it can.
2. Partial coverage — the cell exercises ONE dimension of a multi-dimension requirement, but not every trigger the requirement names (e.g. REQ1-B64-* ← base64url.decode.invalid_encoding=2: the two cases exercise padding and alphabet rejection, but NOT length-mod-4-equals-1, whitespace, non-zero pad bits, or alternate canonical encodings — so the four B64 requirements are only partially proven by the current corpus). Where a requirement is only partially covered, the row is populated (the cell exists and rejects the inputs it names) but the partial coverage is disclosed in the evidence column; full coverage of every named trigger is a corpus-growth obligation, not a BAP-10 deliverable (BAP-10 cannot add corpus cases — that is a verdict change).
3. Family proof — a closed-set requirement (e.g. REQ1-HEADER-closed-set) is proven by the union of that surface's rejection cells (invalid_algorithm, invalid_encoding, invalid_claim, ...), each of which rejects one class of unlisted member. No single cell is "the" closed-set proof; the union is.

This reading guide does NOT lower the populated bar. A row is populated only when a real corpus cell exists and rejects a real input exercising the requirement's subject; it is gap when no cell exercises the requirement on any surface. The category-2 disclosure ("partial coverage") is honesty about the breadth of the existing corpus's coverage of a multi-trigger requirement, not an acceptance of non-proving evidence — the named cells DO prove what they exercise, and what they do not exercise is disclosed so a successor-corpus slice can close it. Gaps (rows where no cell exercises the requirement on any surface) are recorded as gap with their input-algebra reason, never silently overstated as populated.

Coverage summary

• 86 requirement ids total: 76 REQ1-* (protocol-v1.md) + 10 REQ1-EVO-* (standards-track.md).
• MUST/MUST NOT requirements mapped to populated cells: all protocol-v1.md REQ1-* map to ≥1 populated conformance cell. One profile-level invariant (REQ1-CORE-reject-unlisted) is recorded as a gap with its input-algebra reason (it is the rationale for the per-surface closed-set MUSTs, each of which maps to populated rejection cells — the rule is proven by that union).
• Evolution-contract REQ1-EVO-* gaps: 8 of 10 are gap (governance/process invariants the v1 corpus cannot express); 2 are populated (mirror CORE rows on check_envelope). Every gap carries a falsifiable input-algebra reason per the gap gate.
• Corpus revision: bounded-authority-protocol-v1-conformance-corpus-index (283 cases, 28 surfaces, 16 classes).

Maintenance

This map is a living artifact. It was validated against the corpus revision named above. Obligations:

• A successor-corpus slice that adds surfaces or classes, or changes a cell from n/a to populated (or vice versa), MUST re-walk this map and update the affected rows + the corpus-revision qualifier.
• A gap row may become populated when a future corpus (e.g., a successor-major corpus) can express the requirement; that promotion is the owning slice's job.
• The corpus-revision qualifier on each row is the drift detector: a row whose qualifier no longer matches index.json's format field is stale and must be re-validated before the map is cited.