#Static and Regression Conformance Harness for Unification

F.15 · Stable · Pattern · Part F - The Unification Suite (U-Suite): Concept Sets, SenseCells, and System-Role Kinds and Assignments

#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.

Type: Pattern Status: Stable

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

Type: Architectural pattern. Status: Stable. Normativity: Normative. Builds on: F.17 for exact SchemeSenseCell, local-sense basis, and row epistemes; F.18 for naming-settlement NameCard epistemes and selected designation expressions; F.14 and F.8 for anti-explosion and mint-or-reuse decisions; F.13 for lineage; F.9 for actual cross-local Bridge occurrences and separate bounded-use claims; F.4 for system-role-kind-description epistemes; F.10 or the current pattern that defines the status values and windows; C.2.1 for exact claim and record epistemes; A.2.6 for ClaimScope; A.1.1 and A.22 only when a selected bounded-model-use Structure actually changes the checked use; and E.24.PUB for publication.

Coordinates with: A.6.1 for exact check-application bindings; A.13 for every precise performer's local core, A.15.1 for independent dated assessment-Work admission, and F.6 only for a current precise assignment-bound attribution; A.10 and B.3 for evidence reliance and assurance; G.11 for currentness; A.2, A.2.1, A.2.5, and A.2.7 for system-role kinds, assignments, assignment-state predicates and direct state relations, and relations among system-role kinds; E.17 and E.10.D2 for view, description, and source-use claims; A.6.5 for relation declaration; and the pattern that defines each non-naming object included in the selected slice.

Plain entry cues (informative). Static or regression check over a finite naming slice; selected-name regression; exact before/after naming continuity check.

Intent. Give one compact harness for checking whether a finite naming and unification slice is locally sound now and remains sound across exact changes. F.15 does not define schemes, local senses, cells, values, relation occurrences, descriptions, rows, system-role kinds or assignments, status families, aliases, names, evidence, or publication. Its application checks exact objects already recovered through their defining or testing rules and records result claims without duplicating F.18 naming settlement.

#Keywords

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

#Relations

#Content

#Intent and applicability

Intent. Give one compact harness for checking whether a finite naming and unification slice is locally sound now and remains sound across exact changes. F.15 does not define schemes, local senses, cells, values, relation occurrences, descriptions, rows, system-role kinds or assignments, status families, aliases, names, evidence, or publication. Its application checks exact objects already recovered through their defining or testing rules and records result claims without duplicating F.18 naming settlement.

Applicability. Use F.15 when one receiving use depends on several already recovered items: effective ReferenceSchemes, F.17 SchemeSenseCell values, F.18 NameCards and selected designations, F.17 rows, local system-role kinds or status values, actual F.9 Bridge occurrences, or exact prior and later editions. Include a selected bounded-model-use Structure and its description only when that structure's organization changes this check or receiving use.

Primary EntityOfConcern in plain terms. One exact finite slice version under a declared set of static or regression rules for one named receiving use. The checked scope is not evidence, a work process, result, registry, Bridge, system-role assignment, status value, publication, or universal context.

Admissible move in plain terms. Resolve the finite member refs and exact versions; apply only the triggered rules; identify the check application or assessment work when it occurs; constitute each result claim separately under C.2.1; cite witnesses and evidence relations separately; and use the defining or testing rule for every failed subject claim, with its PatternID retained only as a locator.

Primary working reader. A terminology steward, method author, architect, manager, or checker deciding whether selected current names, rows, senses, relations, and exact changes are safe for one stated reuse.

Use this when. Use F.15 when a slice feels "almost unified" but one or more questions remain:

1. Does each local expression resolve under its exact effective ReferenceScheme and local-sense claim?
2. Does each SystemRoleKindDescription still describe its exact local system-role kind without becoming the kind, assignment, or NameCard?
3. Does each F.17 row still pass its own entry and result gate, including the valid one-cell case?
4. Does every cited F.9 Bridge actually obtain between exact cells, with its description/Card and bounded-use claim kept separate?
5. Do exact earlier and later values, descriptions, rows, names, relations, and status windows support the stated continuity or change claim for this receiving use?

What goes wrong if missed. Shared spelling globalizes local senses; a table row or NameCard looks like value identity; a Bridge description replaces relation truth; record membership becomes evidence; a check record appears to perform work or emit its own result; and an edition label silently proves sameness or difference.

What this buys. A finite, replayable safety harness: selected names remain tied to exact governed values, cross-local use stays relation- and claim-bound, non-naming claims remain governed by their defining or testing rules, and regression closure says exactly which versions, rules, evidence, losses, and receiving use were checked.

Not this pattern when. Not F.15 for choosing a name, minting a NameCard, admitting a row, establishing a Bridge, performing a check, publishing a record, or deciding one system-role-kind, assignment, status, or evidence claim. Use F.18, F.17, F.9, A.15.1/A.6.1, E.24.PUB, or the pattern that defines the exact object or relation. Use F.15 only when their already-defined outputs must be checked together.

Recognition versus assurance note. Recognition identifies the exact finite scope, versions, triggered rules, and receiving use. Assurance, when needed, concerns reliance on separately constituted result claims through exact A.10 or B.3 paths. Neither a filled record nor scope membership supplies assurance.

#Problem frame

Unification work fails when composition is claimed before local meaning, exact object recovery, and continuity are checked:

1. Locality leak. Same spelling is treated as one meaning without comparing exact <ReferenceScheme, LocalSenseClaim> projections.
2. Row sprawl. F.17 rows or F.18 NameCards multiply although an existing governed value and admitted naming use already suffice.
3. System-role or status inflation. Adjectival, temporal, or source-label variants become new system-role kinds or status values without recovery through the pattern that defines them.
4. Silent rewrite. An edition or rename changes claim content while a stable id is treated as continuity proof.
5. Bridge hardening. A description, Card, CL, or earlier relation claim is later used as equivalence or use authority without a current obtaining occurrence and separate bounded-use claim.
6. Check collapse. Scope, rule, application/work, result claim, witness/evidence path, record episteme, publication, and currentness are treated as one object.
7. Register split. Tech and Plain designation expressions drift away from the exact current F.18 NameCard, governed value, or local sense.

F.15 catches these failures before the finite slice is used for naming reuse, cross-local comparison, assurance input, or another downstream claim.

#Problem

A slice can look stable because labels, cards, rows, descriptions, relation records, aliases, and version ids are arranged in one table. Yet the table establishes none of its listed subject relations, checks, results, evidence uses, continuity claims, or publication occurrences. F.15 makes the exact static and before-and-after questions inspectable without defining or establishing the neighbouring naming, ontology, checking, evidence-use, or publication claims itself.

#Forces

#Solution

The harness has two rule families:

1. Static Conformance Rules (SCR). Check exact current object and relation refs in one finite slice version. A rule result is a separately constituted claim, not a field value that becomes true because a record is filled.
2. Regression and Stability Conformance Rules (RSCR). Compare exact earlier and later refs for the changed member only. State the governed continuity or change claim, admitted losses, evidence, and receiving use; changed spelling or edition alone proves neither sameness nor difference.

Both families are F.15-local check declarations over already defined objects. A practitioner may apply their questions and obtain a local result without naming the checking activity as Tech U.Work. An exact rule application, when its identity is needed, uses A.6.1.

If a replayable result or example asserts dated assessment U.Work, recover each actual performer's A.13 core and independently admit the Work under A.15.1. Add F.6 afterward only when the result also needs precise assignment-bound attribution. A short record may omit an assignment identifier unused by its receiving claim only when every relation it consumes remains recoverable. Name the A.6.1 application and bindings when that application is also asserted.

C.2.1 separately constitutes the result claims and optional conformance-record episteme. A.10 and B.3 supply evidence-reliance and assurance rules; E.24.PUB supplies publication rules; G.11 supplies currentness rules.

#Minimal vocabulary

• Finite harness scope - an F.15-local by-value selection of exact current refs, versions, triggered rules, and one receiving use; not a U-kind, relation, evidence set, or selected Structure by default.
• Static Conformance Rule (SCR) - an F.15-local declared predicate over exact current inputs.
• Regression and Stability Conformance Rule (RSCR) - an F.15-local declared predicate over exact earlier/later inputs plus the continuity or change claim and receiving use.
• Check application - an actual A.6.1 operation application with exact rule and object bindings, when current.
• Dated assessment Work - a specific U.Work occurrence used only for a replayable performance claim. Each performer must already have the A.13 core and the Work must already be independently admitted under A.15.1. F.6 is additionally required only when the receiving claim needs precise assignment-bound attribution.
• Result claim - one C.2.1 episteme asserting pass, fail, or undetermined for one exact rule application, scope version, and use; not a general status value.
• Witness - an exact example, counterexample, invariant, trace, or edition note cited by the result claim; its presence is not the result or an evidence-use relation.
• Conformance record - an optional C.2.1 episteme that packages refs to the scope, applications/work, result claims, witnesses/evidence paths, non-admitted uses, and reopen conditions; it performs no check.
• Changed member - one exact prior/later pair whose governed identity, relation truth, description, designation, status use, or publication availability may affect the receiving use.

#Objects under check

A practitioner applying F.15 may check these exact objects together but redefines none:

1. effective U.ReferenceScheme values and exact prior/later editions;
2. independently governed local-sense claims and F.17 SchemeSenseCell coordinates;
3. exact governed values and relation occurrences together with the rules that identify each value or say when each relation obtains, and the PatternIDs that locate those rules;
4. F.4 SystemRoleKindDescription epistemes and their exact local system-role kinds;
5. F.18 NameCard epistemes, selected Tech/Plain designations, aliases, and lineage;
6. F.17 UnifiedTermRow epistemes and exact row editions, including admissible one-cell rows;
7. actual F.9 Bridge occurrences, with Bridge descriptions or Cards referenced separately when current;
8. status families, values, targets, scopes, windows, source conditions, and uses recovered through F.10 or another applicable status rule;
9. selected bounded-model-use Structures and their separate descriptions only when structural organization changes the checked use;
10. exact source, evidence, currentness, and publication relation occurrences needed by the result's receiving use.

A description, Card, row, label, shared table, stable id, selected scope, or earlier pass makes none of these subject relations obtain and grants no continuity, equivalence, conformance, authority, system-role kind or assignment, status, or evidence use.

#Finite scope and conformance record

Declare the finite scope before applying a rule:

FiniteHarnessScope:
  ScopeDesignator:
  ReceivingUse:
  EffectiveReferenceSchemeValues[]:
  ExactCurrentObjectOrOccurrenceRefs[]:
  ExactDescriptionOrRecordRefs[]:
  ExactVersionRefs[]:
  PriorLaterPairs[]?:
  SelectedStructureRefs[]?:
  SelectedStructureDescriptionRefs[]?:
  TriggeredRuleRefs[]:
  ExcludedClaimsAndNearestNonUses[]:

SelectedStructureRefs is empty unless an independently selected A.1.1/A.22 structure changes interpretation for the receiving use. A Structure description never replaces the Structure, its obtaining membership relations, or another scope member.

Use an optional record only to package already identified neighbors:

UnificationConformanceRecord:
  EntityOfConcern: exact checked slice/version selected by FiniteHarnessScope
  EffectiveReferenceScheme: scheme interpreting this record's ClaimGraph
  ClaimGraph: exact claims designated by the fields below
  FiniteHarnessScopeRef:
  CheckApplicationRefs[]?:
  AssessmentWorkRefs[]?:
  ResultClaimRefs[]:
  WitnessRefs[]?:
  EvidenceProvenancePathRefs[]?:
  BridgeOccurrenceRefs[]?:
  BridgeDescriptionOrCardRefs[]?:
  PublicationOccurrenceRefs[]?:
  PublicationFormRefs[]?:
  PresentationCarrierRefs[]?:
  CurrentnessRelationRefs[]?:
  NonAdmittedUses[]:
  ReopenTrigger:

The checked scope, rule declaration, ordinary checking action or admitted dated assessment Work, exact application, result claim, witness, A.10 evidence-provenance path, conformance-record episteme, E.24.PUB occurrence, publication form, carrier, and G.11 currentness relation remain distinct. A result ref is included only after its C.2.1 claim exists. The optional record may cite an already admitted Work ref; it does not restate the Work's performer, Method, assignment, time, or containing System. Publication and currentness refs are neighbouring claims, not record identity shortcuts.

#Static conformance rules for local material

SCR-F15-S1 (Finite exact scope). Every selected member resolves to one exact governed value, occurrence, episteme, or by-value scheme at one exact version; the receiving use and triggered rule refs are explicit. Scope membership is selection, not evidence or conformance.

SCR-F15-S2 (Local-sense basis currentness). Each relied-on local-sense claim names its effective ReferenceScheme and exact expression. If a LocalSenseBasisRelation is cited, its exact occurrence and separate description resolve under F.17; a source title, carrier, NameCard, or row does not replace it.

SCR-F15-S3 (SchemeSenseCell identity). Each cell is the exact F.17 value <ReferenceScheme by value, LocalExpression, LocalSenseClaim>. No cross-local items, description fields, source labels, or selected Structures are merged into one cell.

SCR-F15-S4 (Two selected registers). When Tech and Plain designations are current, both are the exact expressions selected by the same current F.18 NameCard for the same governed value and admitted use. Register difference does not create another value or sense.

SCR-F15-S5 (Minimal gloss). A local gloss states only the needed sense and blocked use. It does not smuggle behavior, permission, evidence, source authority, publication status, global sameness, or a check result.

SCR-F15-S6 (Local reuse before Bridge). Another expression under the same <ReferenceScheme, LocalSenseClaim> projection is a designation or alias question. Different projections open the F.9 question only when a named semantic-correspondence use is current; scheme difference alone proves no Bridge.

#Static conformance rules for composed material

SCR-F15-S7 (SystemRoleKindDescription boundary). An F.4 SystemRoleKindDescription is one C.2.1 episteme about one exact local system-role kind under one effective ReferenceScheme. It makes the C.3 candidate domain, operative membership condition, intended member/non-member boundary, continuity rule, and current KindSignature recoverable. Practice or source provenance may locate the definition but does not identify the kind. The description is not the kind, NameCard, SchemeSenseCell, assignment, status, evidence template, method, or work; a cell is cited only when the naming use needs one.

SCR-F15-S8 (Name discipline without F.18 duplication). Every candidate or selected name cites the recovered governed value and the pattern containing its defining or constraining rule. Apply the F.14 and F.8 criteria to decide whether naming work continues; use F.18 to form the NameCard and choose designations; use F.17 to constitute an admitted row. In an F.15 check, verify those exact references; do not choose a name.

SCR-F15-S9 (F.17 row truth). Each cited row is one exact F.17 UnifiedTermRow episteme that records one value, its direct kind, the locator where that kind or value is defined, its NameCard, selected designations, effective scheme, one or more exact SchemeSenseCell refs, admitted and blocked uses, and reopen condition. One cell is valid when the row use is not cross-local; a row-shaped local note or table position is not a row episteme.

SCR-F15-S10 (Cell and neighbor purity). Each row cell remains an exact SchemeSenseCell. NameCard, local-sense basis relation, Bridge, Bridge description/Card, selected Structure, source publication, row id, and carrier remain separate refs and substitute for no cell component.

SCR-F15-S11 (Reuse before minting). When an existing NameCard or row supports the same governed value and admitted use, reuse it or record the exact F.8 decision that justifies another naming settlement. A new label, table, project, or edition is not a visible value difference.

SCR-F15-S12 (Actual Bridge before Bridge use). A cited F.9 Bridge has two exact endpoint cells, one exact relation-semantic profile, a currently true kind-defined predicate, and all required dependencies. Its assertion/description episteme and optional Card remain separate. A separate C.2.1 claim states whether that occurrence suits the exact direction, rule, loss tolerance, polarity, and use; A.10 or B.3 separately governs reliance.

SCR-F15-S13 (Cross-local locality). Use F.9 only for different <ReferenceScheme, LocalSenseClaim> projections and one named current correspondence use. Same-projection expression reuse stays with designation; different projections do not themselves establish a relation; when no current correspondence use exists, add no Bridge or bounded-use claim.

SCR-F15-S14 (Status honesty). A status-shaped item resolves through F.10 or another applicable status rule to the exact family and value definitions, target, scope, window, source condition, and intended use. Adjective, time, scale, phase, confidence, row presence, or display label creates no status family, value, assurance, gate decision, or evidence use.

SCR-F15-S15 (System-role-kind relation preservation). Every exact incompatibility, monotonic kind order, residual qualification, bundle, requirement, or selected SystemRoleKindRelationStructure remains an independently identified relation occurrence or selected structure. A description or convenient fused name creates neither another system-role kind nor an assignment or performed Work.

SCR-F15-S16 (Rule and locator boundary for non-naming claims). Assignment, work, result, evidence, source, publication, currentness, assurance, gate, decision, method, capability, policy, structure, and subject-relation claims cite the rule that defines or tests each exact claim and the PatternID that locates it. When a rule fails, re-evaluate that subject claim under the rule; an F.15 result neither decides nor absorbs the claim.

SCR-F15-S17 (Public naming and publication separation). Public or Core-facing naming cites an exact F.17 row only after its current gate passed. Row currentness is not availability: E.24.PUB separately governs any publication occurrence, form, carrier, audience, and bounded use, and rendering/upload work remains separate.

#Twin-register checks

Use these checks when the F.18 naming result records both a Tech and a Plain designation.

SCR-F15-T1 (Same exact settlement). Both expressions resolve through the same current NameCard to the same governed value, effective scheme, local-sense claim, and admitted naming use. The NameCard, expressions, value, and any F.17 cell remain distinct.

SCR-F15-T2 (Same governed kind). The Plain expression does not suggest a different kind, relation truth, system-role kind or assignment, status, work, evidence, or permission from the Tech expression's exact governed object.

SCR-F15-T3 (Ambiguous head guarded). A high-risk Plain head receives a kind head or short recognition gloss at first use without turning the gloss into a second selected designation.

SCR-F15-T4 (No normative displacement). Reader-facing Plain wording does not silently replace the selected Tech designation in normative Core claims; both remain expressions, not the governed value.

SCR-F15-T5 (Projection-aware reuse). Same-projection reuse is a designation/alias question. A named reuse between different <ReferenceScheme, LocalSenseClaim> projections cites an obtaining F.9 Bridge, a separate affirmative bounded-use claim, and current A.10 or B.3 reliance. A public row, copied label, Card, or earlier pass supplies none of those premises.

#Regression and stability rules

The RSCR family compares exact earlier and later refs for each changed member. Every result names the continuity or change proposition, admitted losses, receiving use, and evidence path. It does not infer identity or difference from spelling, path, stable id, table position, timestamp, or edition label.

#Schemes, versions, and known confusions

RSCR-F15-E1 (Exact before/after and no silent replacement). For each changed member, resolve exact @t0 and @t1 refs and versions. A changed effective ReferenceScheme changes interpretation-bearing content; an unchanged label or shared designator does not prove continuity. State the exact identity, continuity, split, retirement, or replacement claim and cite the rule that defines or tests it.

RSCR-F15-E2 (Known confusion check). Recheck or explicitly retire every prior confusion, blocked use, and nearest counterexample affected by the change. A new edition does not erase an old trap.

#Local senses and SchemeSenseCells

RSCR-F15-E3 (Reconstructible local sense). When the basis episteme, source unit, or attestation changes, the @t1 local-sense claim remains recoverable from exact current basis relations and descriptions. Changed witnesses or source publication do not silently rewrite the sense claim.

RSCR-F15-E4 (SchemeSenseCell value identity). The exact F.17 cell value is <ReferenceScheme by value, LocalExpression, LocalSenseClaim>. Changing any component yields another coordinate value; keeping a label or id does not preserve it. Same sense under a renamed expression is handled through designation/lineage rather than cell identity by wish.

#UnifiedTermRows

RSCR-F15-E5 (Row episteme identity and edition). Compare the exact C.2.1 row epistemes and their ClaimGraphs, EntityOfConcern values, and effective schemes. Changed governed value, NameCard, selected designation, cell, Bridge ref, admitted use, or rationale creates the corresponding later row claim content; an edition id cannot hide it.

RSCR-F15-E6 (Explicit add, split, merge, or retire). When a changed value, sense, or use alters row support, preserve the exact earlier row and state the later add, split, merge, retirement, admitted losses, and receiving use under F.13/F.17. Do not mutate a shared table cell as continuity proof.

#SystemRoleKindDescriptions and names

RSCR-F15-E7 (SystemRoleKindDescription continuity). Compare exact F.4 description epistemes and the described kinds' candidate domains, operative membership conditions, intended member/non-member boundaries, continuity rules, current KindSignature editions, effective schemes, and claim content. Source or practice provenance is a cue to compare those definitions, not an identity key. A label-only change cannot prove that the described kind or description episteme stayed the same.

RSCR-F15-E8 (Alias for expression change; direct recovery for meaning change). If only a selected expression changes while the exact value, scheme, sense, and use are preserved, F.13 and F.18 may record an alias or rename. A changed described kind, candidate domain, operative membership distinction, member/non-member boundary, continuity rule, scheme, local sense, or description claim requires the corresponding new object or episteme and a fresh naming settlement. A practice or source change by itself triggers comparison; it proves neither continuity nor a split.

#Bridges and bounded uses

RSCR-F15-E9 (Exact Bridge change). Compare exact prior/later endpoint cells and relation-semantic profiles. A changed endpoint or profile concerns another Bridge candidate and obtaining test; changed assertion, description, Card, evidence, reliance, or bounded-use claim does not by itself reidentify or negate a fixed obtaining occurrence.

RSCR-F15-E10 (No drift to equivalence or use authority). A later equivalence claim requires an exact Equivalence profile, true predicate, required dependencies, and a separately identified obtaining occurrence. A new witness set, high CL, polished Card, or earlier partial relation is insufficient. Any later substitution still needs its own bounded-use claim and reliance.

#Status and system-role-kind relation structure

RSCR-F15-E11 (Status-window and status-use stability). Compare the exact status family and value definitions, target, scope, window, source condition, and intended use at @t0 and @t1. Changed time, scale, confidence, or edition does not create a new family or preserve an old result automatically.

RSCR-F15-E12 (System-role-kind relation stability). Preserve, retire, or restate each exact incompatibility, monotonic kind order, residual qualification, bundle, requirement, or selected SystemRoleKindRelationStructure before using it in a naming, assignment, or Work claim. No later description or fused label substitutes for the relation occurrence.

#Public naming, publication, and currentness

RSCR-F15-E13 (Public name continuity). F.13/F.18 record the exact selected-expression lineage and NameCard change; F.17 separately records the later row episteme and admitted use. E.24.PUB publication occurrence/form/carrier and G.11 currentness are rechecked only when their exact refs or receiving use changed. A local rename, row edition, or upload does not prove public-name continuity or publication.

#Reasoning primitives

triggeredStaticResults(scopeVersion, receivingUse)
  = exact C.2.1 result-claim refs for every SCR triggered by that finite scope.

staticSliceOK(...) may be asserted only as a C.2.1 summary claim over those exact positive results. Scope membership, a filled record, or an absent failure row does not establish it.

changedMemberResult(priorRef, laterRef, rscrRef, continuityOrChangeClaim, losses, receivingUse)
  = one exact C.2.1 result claim after the rule application and its evidence are recoverable.

changedSliceOK(...) may summarize only the exact changed-member results. Unchanged members reuse prior results after a direct contradiction check; one changed member does not trigger a full-slice rerun unless its dependencies invalidate the other results.

failedRule(ruleRef, subjectClaimRef)
  -> use the defining or testing rule for subjectClaimRef before the receiving use.

An F.15 result may report the failed check. Writing another record field neither repairs nor decides the subject claim.

bridgeSuitableForUse(bridgeOccurrenceRef, useClaimRef)
  only if the Bridge obtains, the separate C.2.1 claim is affirmative for exact <use,direction,rule,tolerance>,
  and current A.10 or B.3 reliance supports that claim for the same use.

The Bridge, use claim, evidence/reliance, authorization, and any receiving occurrence remain separate. CL, a Card, or record membership is not a use result.

#Archetypal Grounding - worked cases

#Activity and task under two run schemes

The slice resolves activity under PROVORunScheme-2026 and task under IEC61131RunScheme-2026 as two exact F.17 SchemeSenseCells. A named comparison use is current.

F.15 result:

• SCR-F15-S3 checks each exact triple; shared run-language does not merge them.
• SCR-F15-S12 requires an obtaining F.9 occurrence before the comparison uses a semantic relation. Its Card is optional and its bounded-use claim is separate.
• Any F.17 row must pass its own gate. It may contain the exact cells needed by the row use; table shape does not create the row.
• An ExecutionSystemRoleKindDescription remains an F.4 episteme about one exact local ExecutionSystemRole under one scheme; it does not describe both cells, assign a system, or prove work.
• If a later task sense becomes cyclic while the activity sense remains non-periodic, RSCR-F15-E4 and E9 compare exact later cells and Bridge candidates; evidence may change the use claim or reliance without silently rewriting the prior Bridge.

Suppose CheckRun-17 is dated assessment U.Work, CheckMethod-17 is its semantic U.Method, CheckInterval-17 is the Work interval, and HarnessSystem-17 is the containing System. Evaluator-17 is the admitted U.System that performs the Work using that Method during CheckInterval-17. First recover Evaluator-17's A.13 core for this action, including declared assignment species EvaluatorAssignmentSpecies-17 and one obtaining occurrence EvaluatorAssignment-17 with every required participant value, Evaluator-17 as holder, and interval coverage. A.15.1 then independently admits CheckRun-17 from its performance history, enacted Method, interval, and containing-System relation. Because this example also claims performance under EvaluatorAssignment-17, F.6 afterward links the already admitted Work to that same assignment.

ApplySCR-S12-17 is the exact A.6.1 rule application and bindings. BridgeRuleResult-17 is a separate C.2.1 result claim; WitnessTrace-17 and its A.10 path are separate again. UnificationConformanceRecord-17 merely cites those admitted refs. Publishing the record requires its own E.24.PUB occurrence, form, and carrier.

#Service availability across service and observation schemes

The slice contains one service-management status value/use and one uptime-observation claim under different effective schemes, plus exact cells only for the naming use that addresses them.

F.15 result:

• SCR-F15-S14 requires F.10 for the status family/value, target, scope, window, source condition, and intended use, or the exact defining or testing rule for the current status claim.
• A named cross-local comparison must pass SCR-F15-S12 and S13; the row or shared availability label does not create the Bridge.
• Observation evidence and A.10 reliance are not the status value, comparison result, assurance claim, or F.15 result.
• Use B.3 only when its assurance claim or material-reliance threshold is current; the slice establishes no assurance by inclusion.

#Rename a SystemRoleKindDescription without changing the described kind

IncidentReviewerSystemRoleKindDescription@t0 and ServiceIncidentReviewerSystemRoleKindDescription@t1 describe the same exact IncidentReviewerSystemRole only if F.4's candidate domain, operative membership condition, intended member/non-member boundary, continuity rule, current KindSignature, effective scheme, and description claims support that continuity. A changed source, practice, or name alone decides neither sameness nor difference.

F.15 result:

• RSCR-F15-E7 compares the two exact description epistemes and the described local system-role kind.
• RSCR-F15-E8 permits F.13/F.18 alias or rename treatment only for expression change with value, scheme, sense, and use preserved.
• F.18 updates the NameCard; F.17 updates a public row only if that row use is current and its gate passes.
• If the described system-role kind or description claim changed, F.4 and the naming patterns create the corresponding new objects; F.15 does not declare continuity.

#Partial Bridge later claimed as equivalence

An exact Partial-overlap Bridge once obtained between an OWL subclass sense and an FCA order-edge sense. A later formal result claims equivalence inside one constrained fragment.

F.15 result:

• RSCR-F15-E9 keeps the prior occurrence fixed and identifies the exact later endpoint/profile candidate.
• RSCR-F15-E10 requires the Equivalence predicate and dependencies to be true for a separately identified occurrence; new witnesses or CL do not suffice.
• The constrained-fragment substitution is a separate bounded-use claim with its own rule, tolerance, polarity, and reliance.
• C.29 governs the mathematical-lens claim; F.15 checks that no description, Card, or result label silently strengthens the relation.

#Peak-hours status proposal

A team proposes PeakHoursAvailabilityStatus as a new family because one existing status is used in another time window.

F.15 result:

• SCR-F15-S14 fails if F.10 or the applicable status rule shows only a changed window or use.
• RSCR-F15-E11 compares the exact family/value, target, scope, window, source condition, and use rather than the suffix.
• Use F.10 or the applicable status pattern for the status claim; F.14/F.8/F.18 block a new durable name until a distinct governed value is independently recovered.

#Bias-Annotation

F.15 blocks unification bias: shared spelling, table membership, a stable id, an earlier pass, a Bridge description, or a NameCard is not common meaning or continuity proof. It also blocks harness-authority bias: the record does not perform the check, create a result, turn witnesses into evidence use, publish itself, or absorb a failed system-role-kind, assignment, status, relation, work, evidence, assurance, or naming claim.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Closure conditions

A finite slice is locally admissible for its named receiving use only when:

1. every scope member and exact version resolves under its identity rule and PatternID locator;
2. every triggered static rule has one exact current C.2.1 result claim;
3. every changed member has an exact prior/later pair and RSCR result naming continuity/change, losses, evidence, and use;
4. every failed subject claim is re-evaluated under its defining or testing rule before reuse;
5. witness refs and any relied-on A.10/B.3 path are current for the exact result and use, without becoming the result;
6. the optional record cites, but does not replace, applications/work, result claims, evidence, Bridge occurrences, descriptions, publication, or currentness;
7. tempting non-admitted uses—system-role assignment, performed work, source or publication authority, status transfer, evidence use, equivalence, assurance, gate passage, and authorization—are explicit; and
8. the closure statement names the exact slice versions, rule set, currentness basis, and receiving use.

Closure is local. A later change reopens only the affected rule results and their dependents after contradiction checks. It does not authorize a full rerun by habit or a global claim that all names, rows, relations, evidence, and publications conform.

#Consequences

Benefits. F.15 makes interpretation locality, exact naming settlement, Bridge truth, check execution, result identity, and edition continuity visible before reuse. The applicable patterns retain their definitions while the finite slice gains one replayable check surface.

Costs. A slice that looks unified by spelling or table shape may remain open until exact object refs, rule applications, result claims, evidence paths, and prior/later continuity claims are recoverable. The harness limits this cost by triggering only relevant rules and reusing unaffected results after contradiction checks.

Failure avoided. F.15 prevents row-, card-, or record-shaped notes, alias-only rewrites, Bridge optimism, system-role and status inflation, evidence collapse, and publication or currentness labels from becoming hidden global meanings or conformance authority.

#Rationale

Cross-local reuse is useful only after exact locality and relation truth are preserved; regression is useful only when it compares real earlier/later objects for a named use. F.15 therefore checks a finite joint slice without defining another ontology or naming protocol, performing assessment Work, establishing evidence relations, publishing content, or creating a global status system.

#SoTA-Echoing

Currentness rule: when the defining or testing rule for a value—or F.17/F.18, F.9, C.2.1, A.10/B.3, A.15.1/A.6.1, G.11, or E.24.PUB—changes an exact input, relation, result, evidence, or receiving-use boundary, reopen only affected SCR/RSCR results and their dependents. A label, carrier, record layout, or unrelated edition change does not reopen the whole slice.

#Relations

• F.17 and F.18. Supply exact scheme-based cells, basis relations/descriptions, NameCards, selected designations, rows, and editions. In an F.15 check, verify those values without selecting or publishing a name.
• F.14, F.8, and F.13. Govern anti-explosion, mint-or-reuse decisions, and lineage before F.15 checks the resulting exact refs.
• F.4 and exact system-role patterns. Define system-role-kind-description epistemes, local system-role kinds, relations among them, assignments, and work claims that the harness cannot absorb.
• F.9, C.2.1, A.10, and B.3. Govern actual Bridge occurrences, separate bounded-use claims, evidence reliance, and assurance. Descriptions, Cards, CL, and witnesses are not relation truth or use authority.
• F.10 or the applicable status pattern. Use it for status family, value, target, scope, window, source, and use claims.
• A.1.1 and A.22. Supply an optional independently selected bounded-model-use Structure only when its organization changes the checked use; description and membership remain separate.
• A.13, A.15.1, F.6, and A.6.1. A.13 recovers each exact actual performer and A.15.1 independently admits dated Work; F.6 adds only an expressly consumed precise assignment-bound attribution through the same obtaining A.13 assignment, and A.6.1 governs exact rule application. Ordinary checking need not be admitted as U.Work, and missing or failed F.6 leaves any independently admitted Work intact.
• E.24.PUB and G.11. Govern publication occurrence/form/carrier and currentness separately from the checked record.
• C.34. Supplies architecture-specific preservation or equivalence adequacy when exact selected architecture structures and losses are the live subject; F.15 carries only the finite regression check and result refs.

#Didactic distillation

Use F.15 as a small check over exact already-governed objects. First pin the finite scope, versions, rules, and receiving use. Then check locality and naming: schemes and cells are exact, the F.18 result records the selected names, an F.17 result records any admitted row, and actual Bridges remain separate from Cards and use claims. Next check execution and result: an application or dated Work is not its C.2.1 result, witnesses are not evidence use, and a record does not perform or publish anything. For change, compare exact prior/later refs and state continuity, loss, and use. When a rule fails, re-evaluate that subject claim under its defining or testing rule; do not patch the label or record field.

#F.15:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)