#SCR/RSCR Harness for Unification

Pattern F.15 · Stable Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

“Prove locality and parsimony first; only then prove composition.” Status. Architectural pattern. Builds on: E.10.D1 Lexical Discipline for “Context” (D.CTX); F.0.1 Foundational Principles; F.1–F.14. Coordinates with. B.3 Trust & Assurance Calculus (for CL use on Bridges).

Intent. Provide a minimal, notation‑free harness of conceptual checks that tells you whether a unification slice is sound: Contexts are fixed and diverse (F.1), terms are harvested and clustered inside Contexts (F.2–F.3), Role Descriptions point to one SenseCell (F.4), names obey discipline (F.5), rows are reused instead of multiplied (F.7–F.8), bridges are explicit and penalised (F.9), statuses vary by windows not type proliferation (F.10), and cross‑line bindings (F.11–F.12) respect locality. Applicability. Use whenever you declare or revise any of: Context cards, Local‑Senses, SenseCells, Concept‑Set rows, Role Descriptions, Bridges, Status windows. Non‑goals. No registries, workflows, or storage formats. No team roles. No metrics dashboards. This is thinking discipline, not governance.

#Keywords

• static checks
• regression tests
• acceptance tests
• validation
• SenseCell testing.

#Relations

#Content

#Intent & applicability

Intent. Provide a minimal, notation‑free harness of conceptual checks that tells you whether a unification slice is sound: Contexts are fixed and diverse (F.1), terms are harvested and clustered inside Contexts (F.2–F.3), Role Descriptions point to one SenseCell (F.4), names obey discipline (F.5), rows are reused instead of multiplied (F.7–F.8), bridges are explicit and penalised (F.9), statuses vary by windows not type proliferation (F.10), and cross‑line bindings (F.11–F.12) respect locality. Applicability. Use whenever you declare or revise any of: Context cards, Local‑Senses, SenseCells, Concept‑Set rows, Role Descriptions, Bridges, Status windows. Non‑goals. No registries, workflows, or storage formats. No team roles. No metrics dashboards. This is thinking discipline, not governance.

#Problem frame

Without a unification harness:

1. Locality leaks. Cross‑context equivalence creeps in “by name”.
2. Row sprawl. Concept‑Set tables grow laterally with near‑duplicates.
3. Role/Status inflation. Adjectival or temporal variants become new types.
4. Silent rewrites. New editions overwrite old meanings without a trace.
5. Unstable bridges. Cross‑context relations harden into dogma without CL or loss statements.

#Forces

#Core idea (didactic)

The harness is a two‑tier net of assertions:

• SCR — Static Conformance Rules. context‑local and cross‑artefact checks that must hold now.
• RSCR — Regression & Stability Rules. Checks that must hold across changes (editions, rows, names).

Registry-reference note (normative). When an SCR/RSCR mentions BridgeId, policy identifiers, or edition identifiers, these are treated as registry references. They MUST be validated by registry presence/version checks, but MUST NOT be treated as symbols that have to appear in any provides list (e.g., SignatureManifest.provides) or be satisfied via imports closure, because they are not part of a signature’s exported vocabulary; they are external registry keys.

All checks are expressed as judgement schemas (premises ⊢ conclusion). They never prescribe artefact formats, roles, or workflows.

#Minimal vocabulary (this pattern only)

• Unification line (L). The thematic cut you are pursuing (e.g., Enactment + Sensing + Execution).
• Check. A content‑level assertion about Contexts, senses, rows, Role Descriptions, bridges, or windows.
• Witness. A thoughtful minimal example that makes a check concrete (e.g., one seed, one bridge pair).
• Slice. The small set of objects under scrutiny together (Contexts in view, the row you’re adding, the Role Description that uses it, and any bridge it needs).

#Objects under check

1. Contexts — U.BoundedContext cards (F.1).
2. Local‑Sense — clustered sense inside one context (F.3).
3. SenseCell — (Context × Local‑Sense) address (F.3/F.4).
4. Concept‑Set row — a cross‑projection hypothesis of “the same thing” (F.7).
5. Role Description — Role/Status definition pointing to one SenseCell (F.4).
6. Bridge — explicit Cross‑context relation with CL and loss notes (F.9).
7. Windows — temporal/scale views for a Status family (F.10).
8. Aliases — name continuity commitments (F.13).
9. Bundles & SoD — reuse levers that replace hybrid roles (F.14).

#Solution overview — the harness as a lattice of checks

The harness arranges checks in three clusters:

• S‑Local. context‑local sanity (anchoring, clustering, two‑register labels).
• S-Cross. Cross-artefact coherence (row reuse, single-cell Role Description, bridge discipline, window honesty).
• R‑Evo. Evolution continuity (no silent rewrites, no vocabulary creep, bridge re‑validation).

#SCR — Static conformance rules (S‑Local)

All S‑Local rules are Context‑internal and derive only from F.1–F.5.

SCR‑F15‑S1 (Anchored term). Seed σ has context C ⊢ C ∈ Contexts(L) Reading: Every harvested seed lives in a Context that is deliberately in view for your line (F.1, F.2).

SCR‑F15‑S2 (Edition trace). Occurrence ω supports σ ⊢ ω carries edition+location Reading: A Local‑Sense can be mentally reconstructed from attestations (F.2).

SCR‑F15‑S3 (Intra‑Context clustering). Local‑Sense λ clusters {σᵢ} ⊢ ∀i: context(σᵢ)=context(λ) Reading: No Cross‑context items inside a Local‑Sense (F.3).

SCR‑F15‑S4 (Two registers). Local‑Sense λ ⊢ label(λ)=⟨tech,plain, symbol?⟩ ∧ plain≠∅ ∧ tech≠∅ Reading: Both engineering and plain labels exist; symbol (if any) is purely informative (F.2/F.3/F.5).

SCR‑F15‑S5 (Minimal gloss). gloss(λ) framed at minimal necessary generality Reading: The gloss neither smuggles behaviour/deontics nor globalises the sense (F.2/F.5).

SCR‑F15‑S6 (Context‑local normal form). normalize_C(surface)=n ⊢ n used only within C Reading: No global normal form at this stage (F.2).

#SCR — Static conformance rules (S‑Cross)

S‑Cross rules tie Contexts, rows, Role Descriptions, bridges, and windows together without breaking locality.

SCR-F15-S7 (Single-cell Role Description). Role Description τ ⊢ anchor(τ)=one SenseCell ⟨C,λ⟩ Reading: Every Role Description points to exactly one SenseCell; no mixed semantics (F.4).

SCR-F15-S8 (Name discipline). Role Description τ ⊢ name(τ) obeys F.5 Reading: Labels follow the agreed morphology, register pairing, and minimal generality (F.5).

SCR‑F15‑S9 (Row sufficiency). Row ρ lists cells {⟨Cᵢ,λᵢ⟩} ⊢ |distinct(Cᵢ)| ≥ 2 Reading: A row is meaningful only if it spans at least two Contexts (F.7).

SCR‑F15‑S10 (Row purity). Row ρ ⊢ no cell contains Cross‑context clustering Reading: Each cell is a single SenseCell, not a pre‑merged bundle (F.7).

SCR‑F15‑S11 (Reuse before mint). Proposed row ρ' overlaps intent(ρ) ⊢ prefer reuse(ρ) ∨ document F.8 decision Reading: Rows are reused by default; new rows require a mint‑or‑reuse rationale (F.7–F.8).

SCR‑F15‑S12 (Bridge is explicit). C₁≠C₂ ∧ relation asserted between λ₁,λ₂ ⊢ Bridge β: ⟨⟨C₁,λ₁⟩ ↔ ⟨C₂,λ₂⟩, kind, CL, loss⟩ Reading: Cross‑context relations appear only as Bridges with declared kind (≡, ⊑, ⊒, ⟂), Congruence Level, and loss notes (F.9; B.3 for CL semantics).

SCR‑F15‑S13 (Bridge locality). Bridge β ⊢ cells belong to different Contexts Reading: You never bridge within a Context; that’s clustering (F.3/F.9).

SCR‑F15‑S14 (Window honesty). Status family Σ varies by time/scale ⊢ windows(Σ) define variation; no new Status types introduced Reading: Temporal and scale variation appears as windows, not as new types (F.10).

SCR-F15-S15 (SoD preservation). Bundle B = {τ₁,τ₂,…} with SoD(τᵢ ⟂ τⱼ) ⊢ no single **Role Description** fuses τᵢ,τⱼ Reading: Separation‑of‑Duties is a normative constraint, not a label tweak (F.14).

SCR‑F15‑S16 (Binding coherence). Service‑Acceptance binding references Status Σ and Execution E ⊢ Σ anchored; E anchored; comparison defined via Bridge(s) if Cross‑context Reading: Acceptance compares anchored executions and statuses, with any Cross‑context step made explicit (F.12 + F.9).

SCR/RSCR “Twin Harness” tests

SCR‑TWIN‑01 - Head term check. Plain twin preserves/declares the head per CC‑TWIN‑3.
SCR‑TWIN‑02 - Kind check. Plain twin maps to the same Kind as the Tech name (C.3).
SCR‑TWIN‑03 - SenseCell check. Twin and Tech resolve to the same SenseCell; record counter‑example(s).
SCR‑TWIN‑04 - Stop‑list check. If the base noun is in the Ambiguity stop‑list, require bracketed head + gloss or fail.
SCR‑TWIN‑05 - Normative surface check. No plain twins in CC blocks, signatures, or acceptance clauses.
RSCR‑TWIN‑06 - Drift audit. On Context or glossary edits, re‑run twin harness; degrade or deprecate if SenseFidelity falls.
RSCR‑TWIN‑07 - Bridge audit. If a twin is copied across Contexts, ensure a Bridge exists; record CL and loss notes.

Examples & Anti‑examples

Good (role with head):

• Tech: TransformerRole → Plain: “Transformer (role)” — passes Head & Kind checks.
• Tech: IncidentCommanderRole → Plain: “Incident commander (role)”.

Good (episteme status with head):

• Tech: U.EvidenceRole → Plain: “Evidence (status)” — first mention includes head.

Borderline (allowed with gloss):

• Tech: U.Episteme → Plain: “Tradition (episteme)” — only with first‑use gloss, e.g., “Tradition (episteme) [U.Episteme] — a body of knowledge within IAU_2006”. (Without the head/gloss this is forbidden due to ambiguity.)

Forbidden:

• Tech: U.Episteme → Plain: “Tradition” (bare) — fails CC‑TWIN‑4/5.
• Tech: U.PromiseContent → Plain: “API” — fails Kind and head checks (API is an access method, not the promise).
• Tech: U.RoleAssignment → Plain: “Appointment” — banned term; conflates governance speech‑act with the binding object.

Migration guidance (lightweight)

1. Inventory. List current plain twins per Context.
2. Score. Assign SenseFidelity (0–3) and add counter‑examples; demote or deprecate any with score <2.
3. Head & gloss. Add bracketed heads and first‑use glosses for all surviving twins.
4. Register. Create/update entries in E.10.P; link a DRR for each change.
5. Lint. Enable the Twin Harness in CI to block new ambiguous twins.

#Judgement schemas (core moves)

Representative mental moves; each “fires” one cluster of SCRs.

1. Anchoring Seed σ : context C, C ∈ Contexts(L) ⊢ anchored(σ) (S1)

2. Local clustering ∀σ∈Σ: context(σ)=C ⊢ cluster_C(Σ) = Local‑Sense λ (S3)

3. Role-Description anchoring Role Description τ names ⟨C,λ⟩ ⊢ singleCell(τ) (S7)

4. Row reuse intent(ρ') ≈ intent(ρ) ⊢ reuse(ρ) ∨ justify_mint(ρ') (S11)

5. Bridge assertion C₁≠C₂ ∧ compare(⟨C₁,λ₁⟩,⟨C₂,λ₂⟩) ⊢ Bridge(CL,kind,loss) (S12–S13)

6. Windowing Status Σ exhibits temporal/scale variance ⊢ define windows(Σ); forbid Σ‑splitting (S14)

7. SoD guard SoD(τᵢ ⟂ τⱼ) ⊢ ¬exists Role Description υ that conflates {τᵢ,τⱼ} (S15)

#Micro‑witnesses (illustrative)

11.1 Activity vs Task (PROV‑O ↔ IEC 61131‑3). Contexts: PROV‑O (run), IEC 61131‑3 (run). Local‑Senses: activity(prov), task(iec). Fire: S7 (Role Description “Execution” points to one SenseCell), S12 (Bridge: overlap, CL=2, loss: IEC task may be cyclic; PROV activity need not be periodic), S13 (Contexts differ), S14 (Status windows for compliance later, not new types).

11.2 Service Acceptance (ITIL 4 ↔ SOSA/SSN). Contexts: ITIL 4 (design), SOSA/SSN (run). Row: Service‑Availability with cells ⟨ITIL:SLO availability⟩, ⟨SOSA:observation of uptime⟩. Fire: S9 (row spans ≥2 Contexts), S12 (Bridge kind: measure-for-target, CL=3, loss: sampling bias), S16 (binding coherence), S-RoleDesc-SingleCell.

#Relations (with other patterns)

Builds on: E.10.D1 (Context semantics), F.1–F.14. Constrains: Any addition to F.1–F.14 is publish‑ready only if all relevant SCR here evaluate true on its slice. Feed: B.3 may use Bridge CL and loss notes to adjust assurance.

#RSCR — Regression & Stability Rules (R‑Evo)

These rules speak about changes over time. They are expressed as judgement schemas that compare two conceptual snapshots: @t0 and @t1. No storage, no workflows—just content assertions.

Notation. X@t0 — object X before change • X@t1 — after change • Δ(X)=⟨…⟩ — described difference • same(…) / new(…) / retired(…) — conceptual status.

#Contexts & editions

RSCR‑F15‑E1 (No silent replacement). Context C@t0 : edition e0, C@t1 : edition e1, e1≠e0 ⊢ either newContext(C,e1) ∨ explicitRecency(C,e1) Reading: A new edition becomes a new Context if sense shifts; otherwise keep one context and mark recency. Never overwrite meaning.

RSCR‑F15‑E2 (Trip‑wire carry‑over). C@t1 derives from C@t0 ⊢ tripWires(C@t1) ⊇ review(tripWires(C@t0)) Reading: Known confusions are re‑checked and re‑stated (or explicitly dropped with a sentence why).

#Local‑Senses & SenseCells

RSCR‑F15‑E3 (Reconstitutable seeds). Local‑Sense λ@t0, Δ(occurrences) → λ@t1 ⊢ λ@t1 still reconstructible from attestations@t1 Reading: After changes in attestations, the Local‑Sense remains auditably rebuildable.

RSCR‑F15‑E4 (No Cross‑context creep). SenseCell ⟨C,λ⟩@t0 → @t1 ⊢ context(λ@t1)=C Reading: A SenseCell never migrates across Contexts through edits.

#Concept‑Set rows

RSCR‑F15‑E5 (Row identity). Row ρ@t0 with cells {⟨Cᵢ,λᵢ⟩} → ρ@t1 with {⟨Cᵢ,λᵢ'⟩} ⊢ ρ “same” iff intent(λᵢ')≈intent(λᵢ) ∀i Reading: A row is the same row only if each cell still means the same thing in its Context. Otherwise, mint a new row and retire the old (F.7–F.8).

RSCR‑F15‑E6 (Row shrink‑before‑split). ρ@t1 loses a cell due to edition split ⊢ prefer keep ρ@t0 + add new row ρ' rather than mutating ρ silently Reading: When a Context splits meaning, preserve history: add instead of rewriting.

#Role Descriptions (Role/Status)

RSCR-F15-E7 (Single-cell continuity). Role Description τ@t0 → τ@t1 ⊢ anchor(τ@t1)=one SenseCell ∧ (sameCell ∨ justifiedSwitch) Reading: A Role Description keeps pointing to one SenseCell; switching cells requires a one-sentence rationale tied to the row you reuse (F.4, F.8).

RSCR-F15-E8 (Alias-then-rename). name(τ@t0) → name(τ@t1) ⊢ create alias(name@t0→name@t1) unless semantics changed Reading: If only the name improves, create an Alias (F.13). If semantics change, mint a new Role Description instead.

#Bridges

RSCR‑F15‑E9 (Re‑validate on movement). Bridge β: ⟨⟨C₁,λ₁⟩ ↔ ⟨C₂,λ₂⟩, CL, loss⟩ @t0; any λᵢ mutates @t1 ⊢ β re‑examined; CL may drop; loss updated Reading: Any end‑cell change forces a fresh look; default is more caution (CL non‑increasing unless newly justified).

RSCR‑F15‑E10 (No bridge drift to identity). series of edits turns β(kind≠≡) → β(kind=≡) ⊢ require new witness set Reading: Equivalence (≡) is special: it needs a fresh witness; you cannot slide into ≡ by minor edits.

#Status windows & SoD

RSCR‑F15‑E11 (Window stability). Status family Σ windows@t0 → @t1 ⊢ window set changes only if variance‑of‑meaning is shown Reading: Add or remove windows only when meaning genuinely varies across time/scale—never for convenience (F.10).

RSCR‑F15‑E12 (SoD invariance). SoD(τᵢ ⟂ τⱼ) @t0 → @t1 ⊢ SoD preserved; no new Role Description conflates τᵢ,τⱼ Reading: Separation‑of‑Duties remains in force through changes (F.14).

#Anti‑patterns the harness catches (and the fix)

#Worked “dry‑runs” (composite slices)

Each dry‑run shows how the checks fire when something evolves. These are thinking rehearsals, not procedures.

#New edition of ITIL (services) arrives

Slice. Contexts: ITIL 4(2020)@t0 → ITIL 4(2024)@t1; Row: Service-Availability; Role Description: AvailabilityStatus; Bridges: to SOSA/SSN observations.

Fire. E1 (no silent replacement): decide new Context ITIL 4(2024) because SLO definitions narrowed. E5 (row identity): row Service‑Availability@t1 new (cells now ⟨ITIL2024:SLO⟩ + ⟨SOSA:obs⟩). Retire old row with note. E9 (bridge re‑validate): sampling assumptions changed → lower CL by one and update loss note (new calc window). E7 (single-cell Role Description): AvailabilityStatus still points to exactly one cell (ITIL2024:SLO). Name unchanged → no alias needed.

Pay‑off. History is preserved; reuse remains safe; acceptance bindings (F.12) still compare anchored things.

#Rename a Role Description without changing meaning

Slice. Role Description IncidentStatus@t0 → ServiceIncidentStatus@t1; same SenseCell.

Fire. E8 (alias‑then‑rename): create Alias IncidentStatus → ServiceIncidentStatus (F.13). S8 (name discipline): new name fits the suffix rules (F.5).

Pay‑off. Readers find both names; semantics untouched.

#Tighten a Bridge (weak overlap → equivalence)

Slice. Bridge β between ⟨OWL:subclass⟩ and ⟨FCA:order‑edge⟩ was overlap, CL=2. New formal result proves equivalence in the covered fragment.

Fire. E10 (no drift to identity): to move from overlap→≡, present a new witness set (fragment constraints). S12 (bridge explicit): update β(kind=≡, CL=3) with precise scope/loss (“only within acyclic concept lattices with…”)

Pay‑off. Equivalence is scoped and auditable, not hand‑waved.

#Window misuse detected

Slice. Team proposes PeakHoursAvailabilityStatus as a new Status type.

Fire. S14/E11 (window honesty): reject new type; define a window for peak hours on AvailabilityStatus.

Pay‑off. No type explosion; the evaluation logic in F.12 stays uniform.

#Migration cues (conceptual)

1. When in doubt, fork—not overwrite. New edition? Add a Context unless you can argue sense identity in one sentence.
2. Name pain → aliases, not merges. If a label confuses, rename with an alias; if meaning changed, mint new.
3. Rows age gracefully. Never retrofit a row; retire and re‑row when any cell’s sense shifts.
4. Bridges get colder over time. Prefer to lower CL when editions drift; raising CL needs fresh witnesses.
5. Windows absorb variation. Resist splitting Status types; window by time/scale/phase.
6. Guard SoD early. When binding composite responsibilities (F.14), check SoD before naming.
7. Teach the delta. When things evolve, write one‑breath deltas (“what changed, why it matters”) as part of the example narrative—no registries implied.

#Acceptance summary (“Harness green”)

A unification slice is publish‑ready when:

1. All SCR (S‑Local & S‑Cross) hold for the current snapshot (Contexts, Local‑Senses, SenseCells, rows, Role Descriptions, Bridges, windows).
2. All RSCR (R‑Evo) hold against the previous snapshot: no silent replacements; rows either unchanged or retired+reborn; Bridges re‑validated with CL non‑inflated without witnesses; windows adjusted only for real variance; SoD intact.
3. One micro‑witness per moving part exists in the text (tiny example showing the check in action).
4. Memory rule still holds: the active Context set for the line fits in a careful mind without external aids (F.1).

#Didactic distillation (90‑second teaching script)

“Use the harness to think like a safety net. First, the SCR threads: everything is local to a Context; Role Descriptions point to one SenseCell; rows actually cross Contexts; Bridges are explicit with CL and a loss note; windows capture variation without spawning new types. Then, the RSCR knots: never overwrite an edition—fork the Context or mark recency; keep rows stable by retiring and re-rowing; Bridges get re-validated (CL goes down unless you bring proof); renames become aliases unless meaning changes; windows absorb time/scale shifts; SoD stays intact. If you can pass these thoughts on a small slice—and explain each pass in one breath—your unification is green. No tooling, no roles, no dashboards. Just clean Contexts, honest rows, cautious bridges, and names that help minds meet.”

#F.15:End