#SCR/RSCR Harness for Unification

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

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable

"Prove locality and parsimony first; only then prove composition."

Type. Architectural pattern. Status. Stable. Normativity. Normative. Builds on: E.10.D1 for U.BoundedContext discipline; F.1 for context selection; F.2 and F.3 for term harvesting, Local-Sense, and SenseCell formation; F.4 for RoleDescription as description episteme for one local U.Role; F.5 for local naming discipline; F.7 and F.8 for Concept-Set rows and mint-or-reuse decisions; F.9 for Bridge Cards and CL; F.10 for status families, values, and windows; F.13 for aliases; F.14 for anti-explosion control; F.18 for durable naming.

Coordinates with: A.2, A.2.1, A.2.5, A.2.7, F.6, and A.15.1 for work-facing role, assignment, role state, role relation structure, and performed-work claims; A.10, B.3, E.17, and E.10.D2 for evidence, assurance, publication, source, and description-use claims; A.6.5 for relation-slot discipline.

Plain entry cues (informative). SCR and RSCR harness; unification slice check; context-bridge regression check.

Intent. Give one compact harness for checking whether a unification slice is locally sound now and remains sound across changes. F.15 does not define contexts, senses, rows, roles, status families, bridges, aliases, or names. It checks that the current slice uses those values under their direct patterns without collapsing them into one convenient table or one global meaning.

#Keywords

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

#Relations

#Content

#Intent and applicability

Intent. Give one compact harness for checking whether a unification slice is locally sound now and remains sound across changes. F.15 does not define contexts, senses, rows, roles, status families, bridges, aliases, or names. It checks that the current slice uses those values under their direct patterns without collapsing them into one convenient table or one global meaning.

Applicability. Use F.15 when a project declares or revises a slice that contains several of these moving parts: U.BoundedContext cards, Local-Senses, SenseCells, Concept-Set rows, RoleDescriptions, Bridge Cards, status families or windows, aliases, or durable names.

Primary EntityOfConcern in plain terms. One unification slice under static and regression conformance check. The EoC is not a registry, not a work process, not a role assignment, not a status value, and not a publication.

Admissible move in plain terms. Check the slice against static conformance rules for the current snapshot and regression conformance rules for the changed snapshot, then treat any failed claim under the direct governing pattern.

Primary working reader. A terminology steward, method author, architect, manager, or checker who needs to decide whether a proposed unification row, bridge, role-description label, status window, or rename is safe enough to reuse.

Use this when. Use F.15 when a slice feels "almost unified" but one of these questions is still open:

1. Do all local senses still stay inside their own bounded contexts?
2. Does each RoleDescription still describe one local U.Role through one SenseCell?
3. Does a row really relate at least two contexts, or is it a row-shaped local note?
4. Does a Bridge Card state kind, direction, CL, loss, and admitted use?
5. Did an edition change, row change, rename, bridge change, or status-window change preserve the earlier commitments?

What goes wrong if missed. Local meanings become global by shared labels, rows multiply without real distinctions, role descriptions quietly become status or evidence templates, bridges become equivalence by habit, and changed editions rewrite earlier claims without a visible continuity decision.

What this buys. A small safety harness for Part F: context-local meaning remains local, cross-context use stays bridge-bound, role and status claims leave through direct patterns, and changes can be checked without turning the harness into a new governance format.

Not this pattern when. Not F.15 when the only question is one word, one role value, one role assignment, one status family, one bridge, one public term, one source relation, or one publication-use claim. Use the direct pattern first. Return to F.15 only when the slice combines several moving parts and their joint conformance is live.

Recognition versus assurance note. The recognition block is the unification slice and the current or changed moving parts. The assurance block is the static and regression rule set, the record, witnesses, and worked cases. Assurance text must not turn F.15 into a registry format, publication authority, role ontology, or status ontology.

#Problem frame

Unification work fails when composition is claimed before locality and continuity have been checked:

1. Locality leak. A same-spelled label is treated as one meaning across contexts.
2. Row sprawl. Concept-Set rows grow laterally with near-duplicates.
3. Role or status inflation. Adjectival, temporal, or source-looking variants become new role or status types.
4. Silent rewrite. An edition or rename changes meaning while keeping the old row or name.
5. Bridge hardening. A weak Bridge is later used as equivalence without a new witness set.
6. Register split. Unified Tech and Plain labels drift apart and no longer refer to the same local sense.

F.15 catches these failures before the slice is used for cross-context reuse, naming, assurance, or downstream claims.

#Forces

#Core idea

The harness has two families of rules.

1. Static Conformance Rules (SCR). Check the current snapshot. Contexts, Local-Senses, SenseCells, rows, RoleDescriptions, bridges, windows, aliases, and names must satisfy their direct local rules now.
2. Regression and Stability Conformance Rules (RSCR). Check a changed snapshot against the earlier snapshot. The rule asks what stayed the same, what changed, what must be forked, what must be retired, and which bridge or name needs a fresh witness.

Both families are judgement schemas over content claims. They do not prescribe storage, implementation, team responsibility, or publication format.

#Minimal vocabulary

• Unification slice - the small set of contexts, senses, rows, RoleDescriptions, bridges, windows, aliases, and names being checked together.
• Static Conformance Rule (SCR) - a check that must hold in the current snapshot.
• Regression and Stability Conformance Rule (RSCR) - a check that compares an earlier and later snapshot.
• Check claim - one content assertion such as "this row spans two contexts" or "this RoleDescription refers to one SenseCell".
• Witness - one small example, counterexample, invariant, or edition note that makes the check inspectable.
• Moving part - any context, local sense, row, role-description label, bridge, status window, alias, or public name whose change could affect the slice.
• Failed conformance - a check result that makes the claim governed by the direct pattern before reuse.

#Objects under check

F.15 may check these values together, but does not redefine them:

1. U.BoundedContext cards from F.1.
2. Local-Senses from F.2 and F.3.
3. SenseCells, meaning (Context, Local-Sense).
4. Concept-Set rows from F.7.
5. RoleDescriptions from F.4, each describing one local U.Role through one SenseCell.
6. Bridge Cards from F.9.
7. Status families, values, confidence, and windows from F.10 or the direct status pattern.
8. Aliases from F.13.
9. Candidate names and durable names from F.5, F.8, F.14, F.17, and F.18.

If the slice contains role assignments, performed work, evidence use, source use, publication use, assurance, gate, decision, method, capability, or policy claims, F.15 records that those claims leave the harness for direct governing patterns. It does not absorb them.

#Unification conformance record

Use this record when several moving parts are being checked together.

UnificationConformanceRecord:
  SliceRef:
  BoundedContextRefs:
  ContextEditionRefs:
  SenseCellRefs:
  ConceptSetRowRefs:
  RoleDescriptionRefs:
  BridgeCardRefs:
  StatusFamilyOrWindowRefs:
  AliasRefs:
  CandidateNameOrRowDecisions:
  StaticRuleResults:
  RegressionRuleResults:
  Witnesses:
  NonAdmittedUses:
  DirectGoverningPatternRefs:
  ReopenTrigger:

StaticRuleResults and RegressionRuleResults name only the checks that matter for the current slice. NonAdmittedUses names the tempting claim that the slice does not permit, such as direct role assignment, performed-work attribution, evidence use, source authority, publication authority, status transfer, or bridge-based equivalence.

#Static conformance rules for local material

All local rules stay inside one U.BoundedContext.

SCR-F15-S1 (Context in view). Seed sigma has context C -> C is among the slice contexts. Every harvested seed lives in a bounded context that is deliberately in view for this slice.

SCR-F15-S2 (Attestation currentness). Occurrence omega attests seed sigma -> omega states edition and locus. A Local-Sense can be reconstructed from attestations rather than from memory or a fashionable label.

SCR-F15-S3 (In-context clustering). Local-Sense lambda clusters seeds sigma_i -> every sigma_i belongs to context(lambda). No cross-context items are hidden inside one Local-Sense.

SCR-F15-S4 (Two registers). Local-Sense lambda -> Unified Tech label and Plain label both refer to lambda. The two labels differ in register, not in kind or sense.

SCR-F15-S5 (Minimal gloss). gloss(lambda) -> states only the needed local meaning. The gloss does not smuggle behavior, permission, evidence, source authority, publication status, or global sameness.

SCR-F15-S6 (Context-local normal form). normalize_C(sourceExpression) = n -> n is used only inside C unless F.9 or F.17 admits wider use. Normalization inside one context does not create a global name.

#Static conformance rules for cross-context material

Cross-context rules connect local material without collapsing locality.

SCR-F15-S7 (Single-cell RoleDescription). RoleDescription tau -> refersTo(tau, one SenseCell) and describes(tau, one local U.Role). A RoleDescription is not a status template, evidence template, source template, publication template, or role assignment.

SCR-F15-S8 (Name discipline). RoleDescription tau or NameCard n -> name obeys F.5, F.8, F.14, and F.18 as applicable. Naming follows kind recovery before durable naming.

SCR-F15-S9 (Row spans contexts). Row rho lists cells cell_i -> at least two distinct contexts occur. A row of one context is not cross-context unification.

SCR-F15-S10 (Row purity). Row rho -> each listed item is one SenseCell. No cell is a pre-merged bundle, hidden bridge, or global meaning.

SCR-F15-S11 (Reuse before minting). Proposed row rho2 overlaps intended use of row rho -> reuse rho or record the F.8 mint decision. New rows need a visible difference, not merely a new label.

SCR-F15-S12 (Bridge explicitness). C1 != C2 and relation asserted between cells -> BridgeCard states cells, kind, direction, CL, loss, witness, and admitted use. A cross-context relation appears as a Bridge Card before it is consumed by rows, names, assurance, or downstream claims.

SCR-F15-S13 (Bridge locality). BridgeCard beta -> beta relates cells from different contexts. Within one context, use clustering or local relation discipline rather than a bridge.

SCR-F15-S14 (Status window honesty). Status family Sigma varies by time, scale, phase, confidence, or use -> F.10 names value or window; no new status family by adjective alone. Temporal and scale variation does not create status ontology by suffix.

SCR-F15-S15 (Role-relation preservation). role bundle or incompatibility expression is live -> A.2.7 states it; no fused RoleDescription is minted by convenience. Role-relation expressions are not role assignments and do not prove performed work.

SCR-F15-S16 (Direct-pattern boundary for non-unification claims). Slice contains assignment, work, evidence, source, publication, assurance, gate, decision, method, capability, or policy claim -> cite the direct governing pattern. F.15 checks whether the slice is safe to compose; it does not decide those claims.

SCR-F15-S17 (Public or cross-context naming admission). Name is public, cross-context, or term-sheet-facing -> F.17 and F.18 admit it after kind recovery. Public reuse is not created by repeated local labels.

#Twin-register checks

Use these checks when a Unified Tech label and Plain label are both present.

SCR-F15-T1 (Same local sense). TechLabel t and PlainLabel p -> both resolve to the same SenseCell or NameCard target.

SCR-F15-T2 (Same kind). TechLabel t names kind K -> PlainLabel p does not suggest another kind.

SCR-F15-T3 (Ambiguous head guarded). PlainLabel p has a high-risk head -> first use includes a kind head or short gloss.

SCR-F15-T4 (No normative displacement). PlainLabel p is reader-facing -> it does not replace the Unified Tech label in normative Core claims.

SCR-F15-T5 (Bridge before copying). PlainLabel p is reused in another context -> F.9 Bridge Card or F.17 public term-sheet row exists first.

#Regression and stability rules

The RSCR family compares an earlier snapshot @t0 and a later snapshot @t1.

#Contexts and editions

RSCR-F15-E1 (No silent replacement). Context C@t0 edition e0, Context C@t1 edition e1, e1 != e0 -> new context or explicit recency decision. A new edition becomes a new context when sense changes; otherwise the recency decision is visible.

RSCR-F15-E2 (Known confusion check). C@t1 derives from C@t0 -> known confusion cases from C@t0 are rechecked or explicitly retired. Old traps do not disappear merely because an edition changed.

#Local-Senses and SenseCells

RSCR-F15-E3 (Reconstructible Local-Sense). Local-Sense lambda@t0 changes attestations -> lambda@t1 remains reconstructible from attestations@t1.

RSCR-F15-E4 (SenseCell context stability). SenseCell (C, lambda)@t0 -> (C2, lambda2)@t1 -> same cell only if C2 = C and lambda2 preserves local sense. A SenseCell does not migrate across contexts through edits.

#Concept-Set rows

RSCR-F15-E5 (Row identity). Row rho@t0 with cells cell_i -> row rho@t1 is same row only if each cell preserves its local sense. If a cell changes sense, mint a new row and retire the old row.

RSCR-F15-E6 (Add or retire before silent mutation). Row rho loses or gains a cell because an edition split occurred -> preserve old row and add or retire rows explicitly.

#RoleDescriptions

RSCR-F15-E7 (Single-cell continuity). RoleDescription tau@t0 -> tau@t1 -> refersTo(tau@t1, one SenseCell) and same cell or justified switch.

RSCR-F15-E8 (Alias for rename, new RoleDescription for meaning change). name(tau@t0) -> name(tau@t1) -> alias if only label changed; new RoleDescription if described role or local sense changed.

#Bridges

RSCR-F15-E9 (Recheck Bridge on endpoint movement). Bridge beta@t0 and either endpoint cell changes -> beta is rechecked; CL, loss, admitted use, and witness may change.

RSCR-F15-E10 (No drift to equivalence). Bridge beta kind is not equivalence at t0 and equivalence is claimed at t1 -> new witness set is required. Equivalence is rare and cannot arrive by gradual wording drift.

#Status windows and role relation structure

RSCR-F15-E11 (Window stability). Status family windows@t0 -> windows@t1 -> changed only when variance of meaning or use is shown.

RSCR-F15-E12 (Role-relation stability). role incompatibility, bundle, qualification, or role-requirement substitution@t0 -> @t1 -> preserved, retired, or restated before assignment or naming use. No later RoleDescription fuses roles that were kept distinct by A.2.7.

#Public naming

RSCR-F15-E13 (Public name continuity). Public or term-sheet-facing name changes -> F.17 or F.18 records lineage, alias, split, merge, or retirement. Local rename is not enough when the name already faces other contexts.

#Reasoning primitives

staticSliceOK(slice)
  only if all triggered SCR rows hold for the current moving parts.

Interpretation: F.15 checks only triggered rows. It does not require every possible object slot to be present.

changedSliceOK(slice@t0, slice@t1)
  only if every changed moving part has an RSCR result.

Interpretation: a change that matters to context, sense, row, RoleDescription, Bridge, status window, alias, or name must be stated.

failedRule(rule, claim)
  -> direct governing pattern must govern the claim before reuse.

Interpretation: a failed Bridge rule is governed by F.9; a failed RoleDescription rule is governed by F.4; a failed status-window rule is governed by F.10; a failed naming rule is governed by F.8, F.17, or F.18.

bridgeAdmitsUse(beta, use)
  -> downstream claim may use beta only at that admitted use.

Interpretation: a Bridge may admit naming, explanation, or type-structure use. It does not admit role assignment, work attribution, or evidence use by itself.

#Worked cases

#Activity and task in two run contexts

Contexts: PROV-O run context and IEC 61131-3 run context.

Local senses: activity in the first context and task in the second.

F.15 result:

• SCR-F15-S9 passes only if a Concept-Set row lists both SenseCells.
• SCR-F15-S12 requires a Bridge Card. The admitted use may be comparison or explanation, not direct substitution.
• A RoleDescription named ExecutionRole may use one local SenseCell only. It does not describe both senses at once.
• If a later edition makes the task sense cyclic while the activity sense remains non-periodic, RSCR-F15-E9 rechecks the Bridge and may lower CL.

#Service availability row across service and observation contexts

Contexts: ITIL service-management context and SOSA observation context.

Row: ServiceAvailability with one SLO SenseCell and one uptime-observation SenseCell.

F.15 result:

• SCR-F15-S9 passes because two contexts are present.
• SCR-F15-S12 requires Bridge kind, direction, CL, loss, and admitted use.
• SCR-F15-S16 treats evidence and assurance claims under A.10 and B.3; the row itself does not make the observation adequate evidence.
• SCR-F15-S14 treats time-window and confidence variation under F.10.

#Rename a RoleDescription without changing meaning

Slice: IncidentStatusRoleDescription is renamed to ServiceIncidentRoleDescription, while the described local U.Role and SenseCell stay the same.

F.15 result:

• RSCR-F15-E7 checks single-cell continuity.
• RSCR-F15-E8 admits an alias because only the label changed.
• F.18 updates durable naming if the name is reusable outside the local context.
• If the described role changed, F.15 rejects alias-only treatment; F.4, F.8, and F.18 govern the repaired claim.

#Weak bridge later claimed as equivalence

Slice: a Bridge between an OWL subclass sense and an FCA order-edge sense was partial overlap at CL = 2. A later formal result claims equivalence inside one constrained fragment.

F.15 result:

• RSCR-F15-E10 requires a new witness set for equivalence.
• SCR-F15-S12 updates kind, direction, loss, and admitted use.
• C.29 may govern the mathematical-lens claim; F.15 only checks that the changed Bridge is not silently strengthened.

#Peak-hours status proposal

Slice: a team proposes PeakHoursAvailabilityStatus as a new status family.

F.15 result:

• SCR-F15-S14 fails if the only difference is a time window.
• F.10 governs the status-family and window claim.
• F.14 and F.18 block a new durable name unless a new recovered status family is present.

#Anti-patterns and repairs

#Closure conditions

A unification slice is locally admissible for reuse when:

1. every triggered static conformance rule holds for the current snapshot;
2. every changed moving part has a regression result;
3. each failed rule names the direct governing pattern before reuse;
4. at least one witness exists for each live Bridge, row, RoleDescription rename, status-window change, or public naming change;
5. the record names tempting non-admitted uses such as role assignment, performed-work attribution, source authority, publication authority, status transfer, and evidence use.

Closure is local to the slice and current use. A later context edition, row change, Bridge endpoint change, RoleDescription change, public-name change, or status-window change reopens the relevant RSCR rows.

#Relations

• F.1, F.2, F.3. Provide contexts, terms, Local-Senses, and SenseCells checked by SCR-F15-S1 through S6.
• F.4, A.2, A.2.1, F.6, A.15.1. Govern RoleDescription, role assignment, and performed-work claims that F.15 must not absorb.
• F.7 and F.8. Govern rows and mint-or-reuse decisions checked by SCR-F15-S9 through S11 and RSCR-F15-E5 through E6.
• F.9 and B.3. Govern Bridge Cards, CL, loss, and assurance penalties.
• F.10. Governs status family, value, confidence, and window claims.
• F.13, F.17, F.18. Govern aliases, public term sheets, and durable names.
• F.14. Governs anti-explosion before names are minted for role-like and status-like families.
• A.10, E.17, E.10.D2. Govern evidence, publication, source, and description-use claims when they appear inside a slice.

#SoTA-Echoing

Currentness rule: treat the current Part F and role-method-work patterns named in Builds on and Coordinates with as the source of governing interpretation. If F.4, F.9, F.10, F.17, F.18, A.2.1, F.6, A.15.1, A.10, B.3, E.17, or E.10.D2 changes a governed value, relation, admitted use, or boundary, recheck only the affected SCR or RSCR rows and the worked case that exercises the changed boundary.

#Didactic distillation

Use F.15 as a small check over a slice, not as a new vocabulary machine. First, check locality: contexts are named, local senses are inside their contexts, rows really cross contexts, RoleDescriptions describe one local role, bridges state kind and loss, and status variation stays with status windows. Then check change: editions, rows, bridges, role descriptions, aliases, names, and status windows either preserve their earlier meaning or state the change. When a check fails, do not patch the label. Treat the claim under the direct governing pattern and repair the value.

#F.15:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)