A.6:4.1.1 - AssuranceLane skeleton (informative)

An MVPK AssuranceLane is a publication face that teaches a specific audience how to adjudicate E-* claims against the relevant evidence carriers, including those produced in Work. It cites the boundary’s evidence-interface declarations and explains them without changing their semantics.

Minimal content (suggested):

Scope: boundaryRef, version; viewRef and viewpointRef when view or viewpoint identity matters.
Carrier inventory: carrier-class and carrier-schema refs (A.7 Carrier) + where to obtain them.
E‑claim map: a table keyed by E-* ID with: measurement conditions, carrierRef(s), join and correlation keys, and a reference to the canonical E-* text that defines pass or fail criteria.
Operational policies: references to relevant D-* duties (retention, access control, exposure), without redefining them.
Limitations: sampling, redaction, missing signals, expected false negatives and false positives.

No new semantics reminder. An AssuranceLane may explain adjudication informatively, but any new boundary claim first enters its canonical source. A changed permission-looking claim cites its selected A6-AW-* row and subject pattern rather than being introduced inside the face.

Example (conceptual; uses view/viewpoint identity and the additional hypothetical header case in §4.2):

AssuranceLane:
  viewRef: <ViewId>
  viewpointRef: <ViewpointId>
  boundaryRef: <BoundaryId>
  version: <SemVer or revision>
  evidence:
    - E: E-OBS-1
      carrierRefs: [Carrier.AuthorizationRecord, Carrier.AuditLogEntry]
      measurement:
        conditions: "on every request lacking header X (A-AC-1)"
        vantage: "Operator and auditor pipeline"
        correlation: ["traceId", "requestId"]
      adjudication:
        check: "query audit stream for code=NotAdmissible and join to traceId"
        criteriaRef: "E-OBS-1 (pass or fail criteria live canonically in the E-claim)"
      references: [A-AC-1, D-RET-1, Mechanism.AuditObservability]

The absence condition also covers a request that was not rejected. A claim of complete coverage requires the relevant request population to be accounted for separately from individual query joins.

Default placements (quadrant → stack layer / section):

L → Signature.Laws (and, where appropriate, mechanism‑local semantic laws; never runtime gates)
A → Mechanism.AdmissibilityConditions
D → generic prescriptions, individual duties or commitments, recommendations-as-duty, prohibitions, and A6-AW-NORM-GRANT claims at their exact A.2.8 or A.2.8.PER subject pattern
E → actual occurrences, evaluated findings, and evidence claims, including A6-AW-EXERCISE, A6-AW-WEAK, A6-AW-CONFLICT, and A6-AW-SOURCE when those claims are current

Related subject rules (informative):

A.6.1 ↔ A‑quadrant: U.Mechanism.AdmissibilityConditions is the canonical claim layer for A-* gate and admissibility claims.
A.10 / B.3 ↔ E‑quadrant: for an E-* claim used for reliance, recover the A.10 evidence-provenance path and bounded use. A missing path narrows or blocks only the unsupported use. Open B.3 only for an actual named assurance claim about an exact target and assurance use.
A.2.3 and F.12 ↔ D/E separation: a U.PromiseContent promise is not evidence; promise acceptance is linked to Work evidence via F.12. A general duty remains normative content, while an obtaining individual duty is one A.2.8 U.Commitment borne by an actual System or other admitted party. Any system-role kind or assignment used to establish applicability stays separate. D-* claims reference A-* and E-* claims by ID or canonical location when needed.

A stack is useful because the intended direction of change is clear:

Lower layers (realizations, audit formats, transport mechanisms) are expected to change more frequently and can often evolve without forcing higher‑layer changes, provided higher‑layer commitments remain satisfied.
Changes to higher layers are boundary-claim evolution and typically require explicit compatibility reasoning (and therefore explicit versioning and communication).