#A.6.7:4.2 SuiteObligations (canonical obligation vocabulary)

Preface node heading:a-6-7-4-2-suiteobligations-canonical-obligation-vocabulary:16516

#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

MechSuiteDescription MAY declare any obligations, but the following obligation vocabulary is canonical and is intended to be reused across the universalization of Part G and legality-gated characterization stacks.

SuiteObligations SHOULD be written as an explicit clause set, e.g.:

SuiteObligations := {
  bridge_only_crossings,
  two_bridge_rule_for_described_entity_change,
  transport_declarative_only,
  penalties_route_to_r_eff_only,
  guard_decision_tristate(pass|degrade|abstain),
  unknown_never_coerces_to_pass,
  gate_decision_separation,
  guard_lexeme_reservations,
  cg_spec_cite_required_for_numeric_ops,
  no_silent_scalarisation_of_partial_orders,
  no_silent_totalisation,
  no_thresholds_in_suite_core,
  crossing_visibility_required,
  planned_slot_filling_in_work_planning_only,
  finalize_launch_values_in_work_enactment_only,
  implementation_export_discipline_when_cited
}

Obligation meanings (normative).

1. bridge_only_crossings. Well-formedness constraint: cross-context and cross-plane reuse performed by any member mechanism is represented via that member’s published Transport as Bridge-only (no implicit crossings). A suite does not create transport exceptions.

1.1. two_bridge_rule_for_described_entity_change.

• If a suite member's admissible use requires changing the EntityOfConcern (kind or identity change, CL^k), the crossing MUST be explicit and MUST satisfy the two-bridge rule: plane transfer or context transfer and kind transfer are distinct, both are Bridge-mediated, and both remain penalty-routed to R/R_eff only.

1.2. transport_declarative_only.

• Well-formedness constraint: suite obligations do not introduce any additional graph edge kind beyond E.18 U.Transfer and do not embed CL/Φ/Ψ/Φ_plane tables. Any transport-related obligation is expressed only as referenced pins/anchors whose realization is mediated by E.18 / gate surfaces.

2. penalties_route_to_r_eff_only. Well-formedness constraint: CL/Φ/Ψ/Φ_plane penalties associated with crossing discipline route to R/R_eff only; suites do not define transport penalties that alter F/G.

3. guard_decision_tristate(pass|degrade|abstain) and unknown_never_coerces_to_pass. Well-formedness constraint: admissibility/eligibility outcomes use a tri-state guard result GuardDecision := {pass|degrade|abstain}. Unknown/insufficient evidence is not coerced to pass; it resolves to {degrade|abstain} under declared failure behavior (e.g., probe-only as a SoS‑LOG branch id, not as a new decision value).

4. gate_decision_separation. Well-formedness constraint: suites do not define or use GateDecision values (including block) as part of mechanism/suite semantics. Gate-level outcomes and DecisionLog remain on OperationalGate(profile).

5. guard_lexeme_reservations. Well-formedness constraint: USM.CompareGuard and USM.LaunchGuard denote gate-owned guard events/pins; member mechanisms and suite protocols use …Admissibility / …Eligibility for guard predicates, not the reserved gate lexemes.

6. cg_spec_cite_required_for_numeric_ops. Well-formedness constraint: any member operation that performs numeric comparison/aggregation/legality-sensitive scoring cites the applicable CG‑Spec (and relevant subrefs) as spec pins, rather than embedding equivalent “local legality” content.

7. no_silent_scalarisation_of_partial_orders and no_silent_totalisation. Well-formedness constraint: if a member mechanism induces a partial order, it preserves set-/relation-valued semantics; it does not silently reduce to a scalar/total order. Any totalization is explicit and policy-bound.

8. no_thresholds_in_suite_core. Well-formedness constraint: suite core does not publish acceptance thresholds (“passing scores” / hidden cutoffs). Thresholds belong to acceptance clauses / task signatures / gate profiles.

9. crossing_visibility_required. Well-formedness constraint: any GateCrossing relevant to suite use publishes a CrossingBundle (E.18) and can be cited as an audit anchor. GateCrossing includes (at minimum) cross-context, cross-plane, and cross-kind/EntityOfConcern changes, entry into U.WorkEnactment (LaunchGate), and any edition_key change of pinned editions{…} vectors. Suites may require CrossingBundleRef / UTS / Path pins and policy-id pins as anchors, and MUST NOT embed CL/Φ/Ψ/Φ_plane tables.

10. planned_slot_filling_in_work_planning_only. Well-formedness constraint: any planned slot filling used as a baseline for suite use is authored in WorkPlanning as a planned baseline (no run-time slot instances; no launch values).

11. finalize_launch_values_in_work_enactment_only. Well-formedness constraint: FinalizeLaunchValues (and any witness of actual launch values) occurs only in U.WorkEnactment; neither the suite nor any planned-baseline WorkPlanning plan item is a place for launch values.

Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)