E.18:5.8 - S8 - Guard aggregation assignment and handling (USM §1.2)

• USM.CompareGuard and USM.LaunchGuard publish the guard-gate aggregation assignment field GuardOwnerGateId. The legacy field name is read here as a gate-reference assignment, not as an owner relation. Guard failures are events aggregated by the declared gate (not GateChecks).
• Aggregation-assignment rules: (i) USM.LaunchGuard.aggregationGate = LaunchGateId(workEntryClaimRef), where the ref resolves to the exact prospective claim consumed by the gate and never to a not-yet-existing Work occurrence; (ii) inside a Subflow, USM.CompareGuard.aggregationGate = OperationalGate(InSentinel); join loci cannot be assigned as guard-pin aggregation gates.

Profile-application boundary (cross-reference). A.21 distinguishes a GateProfile description from the exact current fact that applies it to one gate, subject, action, scope, and window. E.18 cites that application only where a current gate or crossing needs it; a profile name, matrix, branch, or PathSlice supplies no application or authority by itself.

Scope-translation guards (cross-reference). A.2.6 defines and tests exact slice and scope membership and any actual translated-scope application. When that translation relies on different local senses, it additionally requires an obtaining F.9 Bridge, a separate affirmative C.2.1 bounded-use claim, and current A.10 or B.3 reliance. Use A.21 for gate aggregation; no CL value or Bridge Card decides the guard.

Error, timeout, or unknown (profile-bound). Keep each source error, timeout, unknown, and notRun result explicit. The exact current profile application cites the rule and edition that maps that result to abstain, pass, degrade, or block; a profile name alone supplies no fixed fold, and no missing or unrun required result maps to pass or neutral abstain. The GateDecisionResult retains the mapping and rationale.