#10 - Review & integration guidance

Preface node heading:10-review-integration-guidance:32501

#Content

#Reviewer’s 8‑point checklist

1. Named describedEntity. Does the claim state what it quantifies over (U.Kind)?
2. Scope explicit. Is G declared (no “domain” placeholders, no implicit “latest”)?
3. Typed compatibility. For compositions, do we have ⊑ (same Context) or a KindBridge?
4. RoleMasks. If used, are they registered, deterministic, and not masquerading as kinds?
5. Two‑bridge rule. For Cross‑context use, do we have both Scope Bridge (CL) and KindBridge (CL^k)?
6. Penalties. Are Φ(CL) and Ψ(CL^k) applied to R, not smuggled into F/G?
7. Freshness. Are validation/monitoring windows separate from Scope coverage?
8. Evidence fit. For class‑level claims, does the test plan cover subkinds/variants?

#Integrator’s composition playbook (typed first, then scope)

• Step 1: Check k_A ⊑ k_B (or KindBridge).
• Step 2: Compute Scope_serial = Scope(A) ∩ Scope(B) (USM).
• Step 3: If parallel supports exist, SpanUnion them (only where independent).
• Step 4: Apply Φ/Ψ penalties to R; enforce freshness.
• Step 5: If a mask is repeatedly required, consider promoting it to a subkind.

#Assurance lead: wiring penalties and windows

• Identify channels used: Scope bridge? KindBridge?
• Apply Φ(CL) and Ψ(CL^k) to R (monotone; higher congruence ⇒ smaller penalty).
• Verify freshness windows for all bound evidence (independent of bridges).
• Publish a one‑box summary: bridges, levels, loss notes, any narrowing/adapters, net impact on R.

#Red flags (stop‑the‑line)

• “We widened G because we reworded the type.” → Reject; redo as subkind/bridge or revise Scope honestly.
• “Mask equals kind.” → Refactor; register mask properly or promote to subkind.
• “Cross‑context without KindBridge.” → Block; demand mapping and CL^k.
• “No Γ_time.” → Block; add explicit time policy (point/window/rolling).