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

MechSuiteDescription MAY declare any obligations. The canonical names in §4.1 support reuse across Part G and admissibility-gated characterization stacks; they are not an exhaustive inventory.

SuiteObligations SHOULD be written as an explicit, duplicates-free clause set. Select applicable clauses from the canonical vocabulary in §4.1 and state any additional obligations explicitly. The requirements below remain applicable under their stated conditions.

Obligation meanings (normative).

1. bridge_only_crossings. For an actual semantic correspondence between distinct recovered local senses, recover the F.17 endpoints and an obtaining F.9 Bridge, then the bounded-use and reliance claims required for this use. A suite creates none of those facts. A changed entity, reference scheme, plane or notation alone establishes no semantic crossing under A.6.4.

   1.1. two_bridge_rule_for_described_entity_change.

   • When both an F.9 semantic correspondence and a C.3.3 kind correspondence are claimed, establish each under its direct rule. Any separately claimed plane relation keeps its own governor. Changing the EntityOfConcern alone creates neither relation. Retain the separate use conditions and applicable penalty policy; do not invent a second Bridge from the change label.

   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/admissibility-sensitive scoring cites the applicable CG-Spec (and relevant subrefs) as spec pins, rather than embedding equivalent local admissibility 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. Apply E.18 only for an independently selected TransformationFlowStructure and its actual governed crossing; apply A.21 for a current work-entry gate. An edition, entity or notation change alone supplies neither that crossing nor a semantic Bridge. 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.