#A.6.7:4.5 SuiteAuditObligations

Preface node heading:a-6-7-4-5-suiteauditobligations:15967

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

A suite MAY require that downstream use provide certain audit anchors. These are requirements, not run-time values. A suite audit obligation MAY include:

• required UTS + Path pins,
• required crossing-surface visibility pins for any crossing relevant to suite use,
• required presence of USM.CompareGuard and/or USM.LaunchGuard pins (not gate checks),
• required declaration of guard ownership (e.g., a GuardOwnerGateSlot anchor),
• required expression of guard violations as GuardFail events aggregated by the guard-owning gate (per GuardOwnerGateSlot), not as extra mechanism/suite states,
• required policy-id pins for any degrade/sandbox/probe-only branches (SoS‑LOG branch id anchors).
• required parity/selection-grade pins when applicable (e.g., when suite use claims parity-grade comparison/selection surfaces downstream).

Norm. A suite must never publish a DecisionLog or GateDecision. If the suite requires guard pins, it requires their presence as anchors so that the gate-level owner can aggregate GuardFails and decide degrade|block per gate profile.

---

Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)