#U.Signature - Reusable Law-Governed Declaration Episteme

A.6.0 · Stable · Architectural (A) · Normative unless marked informative · Part A - Kernel Architecture Cluster

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

Pattern kind. Ontic declaration pattern.

Builds on. A.7 for strict distinction, C.2.1 for episteme identity, C.3 for kinds, A.2.6 for claim scope, and A.6.5 for relation-slot discipline.

Coordinates with. A.6.REL for relation occurrences, A.6.1 for mechanisms, C.29 for mathematical-lens use, E.24.UK for durable U-kind admission, and E.24.PUB for publication.

An engineer has a vocabulary and a set of laws that need to remain stable across several dependent epistemes, such as model epistemes, method descriptions, and patterns. For example, a physical-modeling team needs one stable declaration of connector variables and conservation laws; a clinical team may need one stable definition of a dose-response predicate and its applicability without assuming that a dose-response relation kind has been admitted; and a formal-methods team needs one stable declaration of terms, inference forms, and invariants.

#Relations

#Content

#Problem frame

An engineer has a vocabulary and a set of laws that need to remain stable across several dependent epistemes, such as model epistemes, method descriptions, and patterns. For example, a physical-modeling team needs one stable declaration of connector variables and conservation laws; a clinical team may need one stable definition of a dose-response predicate and its applicability without assuming that a dose-response relation kind has been admitted; and a formal-methods team needs one stable declaration of terms, inference forms, and invariants.

Use this pattern only when the thing being written or reused is itself a reusable declaration. A description, rule, policy, work plan, or specification does not qualify merely because it contains terms or constraints that recur elsewhere.

Before opening declaration fields, ask:

What subject does this declaration cover? What values or results does it speak about? Which terms and laws may another use rely on? Where do those laws apply?

In FPF terms, the declaration is about one exact independently governed EntityOfConcern; SubjectKind and RangedValueKind name its declared subject and value range; ResultKind is added when a distinct result kind is current; and Vocabulary, Laws, and Applicability answer the remaining three questions. U.Signature is the episteme that carries this declaration. A relation kind opens the RelationSignature specialization; a mechanism family or formal calculus opens the corresponding A.6.1 or FormalSubstrate declaration; a method kind remains governed by A.3.1.

Primary working reader and concern. The reader is an engineer who authors or reuses a declaration and needs stable meaning, applicability, and typed reuse without authoring declaration or occurrence-identity apparatus beyond what the current use needs.

For the lightest useful declaration, name that subject through SubjectKind and RangedValueKind, add ResultKind when the result has another kind, and state Vocabulary, Laws, and Applicability. Add SliceSet and ExtentRule only when the same declared kind can have different members at different U.ContextSlice values and one named reuse needs that difference. Add A.6.5 SlotSpecs that declare the direct relation's participant meanings only inside a reusable RelationSignature; add operation argument and result declarations under A.6.1 when a mechanism declaration needs them. Add dependency declarations only when another signature relies on provided names or laws.

What goes wrong if this pattern is missed: content about later realization, evaluation, and publication accumulates inside the declaration. A later user cannot tell which names and laws are reusable, where they apply, or whether a changed implementation has changed the declaration.

What this buys: one identifiable declaration can be reused while later realizations and uses change under their own governing patterns.

Do not use this pattern merely to state that a direct relation obtains or that one work occurrence produced a result. State that claim directly. A maintenance work plan may reuse the words connector and conservation law while scheduling tasks; it remains a work plan unless its own claim content performs the reusable declaration job above. Construct a signature only when reusable declaration content is the current object.

#Problem

FPF uses a signature when the episteme itself performs the reusable declaration job above: it identifies the declared subject and value or result range, supplies terms and laws another use may rely on, and says where those laws apply. Current non-exhaustive declaration families include theory or A.3.3 U.Dynamics epistemes, mechanism or A.19.SelectorMechanism declarations, method-kind declarations, formal substrates, and direct relation-kind declarations; these examples create neither a shared subject kind nor a closed family of signature profiles. Without one precise ontic:

1. the signature is confused with the entity it describes;
2. a relation declaration is confused with an obtaining relation occurrence;
3. applicability is reduced to an unexplained context label;
4. every declaration is forced into one rigid table-shaped publication form, even when a readable sentence is enough;
5. imported names and exported names remain implicit, so dependent declarations cannot be replayed safely.

The central problem is not missing syntax. It is failure to keep the declaration episteme, its declared subject, the subject's occurrences, and later uses of the declaration as different objects.

#Forces

#Solution

Use U.Signature as the dependent durable U-kind for a reusable law-governed declaration episteme. Identify the episteme through its content, exact EntityOfConcernRef, and effective U.ReferenceScheme. Let the declaration state its vocabulary, laws, and applicability. Keep the declared subject and every later realization under their direct kinds and relations.

Local signature mantra. Name the subject of the reusable declaration and the range of values or results it covers. List the terms another user may reuse, the laws that user must preserve, and where those laws apply. Add relation-participant declarations, operation inputs or results, slice-and-membership rules, or dependencies only when one named reuse calls for them. Keep implementations, evaluations, work, and publication outside the declaration.

In FPF terms, the subject is the exact EntityOfConcernRef; SubjectKind, RangedValueKind, and optional ResultKind state the declared subject and range; and Vocabulary, Laws, and Applicability state the reusable terms, regularities, and use boundary. Add A.6.5 SlotSpecs only when a reusable RelationSignature must preserve the same participant meanings and types. Add A.6.1 operation arguments or results only for a current mechanism declaration. Add SliceSet and ExtentRule only when the same declared kind can have different members at selected context slices. Declare a dependency only when another signature actually relies on imported or provided names or laws. If the named reuse still works without an optional addition, leave that addition out. Implementations and realizations remain under A.6.1, evaluations under their direct evaluation patterns, work under A.15.1, and publication under E.24.PUB. The mantra is Plain recall wording. Its imperative grammar does not assert condition-governed continuation. When such executable continuation is current, its object is a Constraint-Governed Unfolding Structure (CGUS) governed by A.22.CGUS.

#Admit and identify U.Signature

U.Signature is a same-individual dependent durable U-kind under U.Episteme. C.2.1 first identifies one episteme through one EpistemeConstitutionRelation by its complete claim content, exact independently governed EntityOfConcern, and effective U.ReferenceScheme. The claim graph and reference scheme are epistemic constituents; the EntityOfConcern is not. A.6.0 adds a stable membership condition and practitioner-facing declaration use to that already identified individual. It adds no second constitution relation, identity discriminator, assembly, composition rule, or holon test.

An already identified episteme is a U.Signature exactly when, under its effective U.ReferenceScheme, its complete identity-bearing claim content carries a reusable law-governed declaration about its exact EntityOfConcern and includes all of the following with substantive meaning:

• direct SubjectKind and RangedValueKind declarations that identify the declared subject and value range;
• Vocabulary that supplies the designators needed to reuse the declaration;
• Laws that state the reusable predicates, equations, invariants, closure conditions, or other declared regularities;
• Applicability that bounds where those claims are used;
• ResultKind, SliceSet, ExtentRule, and dependency, import, or provided-name declarations only when those distinctions are current for the declaration.

Judge the complete claim content, not a selected subset or the presence of field names. A minimal directly authored signature may carry the declaration content required by the A.6.0 membership predicate in one claim graph without citing any smaller episteme. A signature may instead cite separately identified source or dependency epistemes, provided its own claim graph names the dependency relation and the declaration meaning thereby reused. Those source epistemes remain separate individuals connected through their governing dependency, source-use, edition, or other direct relations; they are not components assembled into the signature, and their citation alone does not establish signature membership.

E.24.UK governs the one-time public admission of the dependent kind. In project work, authoring a new declaration candidate, or revising a declaration so that its claim content, exact EntityOfConcern, or effective U.ReferenceScheme changes, yields a resulting C.2.1 discriminator triple. When the one EpistemeConstitutionRelation for that triple obtains, C.2.1 identifies the resulting episteme; A.6.0 then judges whether that already identified individual satisfies the U.Signature membership predicate, without adding a second constitution occurrence or identity discriminator. An optional separately reviewable membership judgment is another classification-assertion episteme whose exact EntityOfConcern is the candidate; that assertion neither creates the candidate nor admits the public kind. Citing, comparing, or reusing an unchanged episteme, or judging its membership without changing a C.2.1 discriminator, creates neither another episteme nor another constitution occurrence.

The signature keeps the C.2.1 identity of the same episteme. Two designations resolve to that same individual only while the complete claim content, exact EntityOfConcern, and effective U.ReferenceScheme are unchanged. Changing any discriminator identifies another U.Episteme; call that new individual a U.Signature only if it independently satisfies the membership predicate above. State an edition, refinement, or supersession relation only when its own direct predicate obtains.

The declared subject remains the independently governed EntityOfConcern, not the signature. A realization of the declaration remains under its direct pattern. A description whose EntityOfConcern is the signature is another episteme. Publication occurrence, publication form, U.PresentationCarrier, and C.29 representation remain separate objects and relations; publication or visible form establishes neither identity nor membership. G.11 currentness and every later work or use likewise remain neighboring judgments and relations rather than signature identity components.

#Write the minimum declaration content

The four content groups are semantic components, not a mandatory visual table. A publication form may present them as paragraphs, a table, formal declarations, or another representation. A publication occurrence makes a selected episteme edition available through that form without changing its content.

SubjectKind and RangedValueKind are declaration-content components. They do not create a second hierarchy beside C.3 or E.24.UK. A.2.6 supplies addressable U.ContextSlice values; C.3.2 governs the membership judgment and any optional materialized KindExtension representation. SliceSet is not a generic space, time interval, numeric or result range, or changing dataset. ExtentRule is not an arbitrary change function: it tells how the declared kind's members are determined at one named slice. A time selector may be part of a U.ContextSlice; a value or result range stays in RangedValueKind or ResultKind; changing data stays with its direct owner; and a claim-bearing mathematical set representation opens C.29 separately. Leave both fields out unless membership of the same declared kind can differ across the named slices.

Applicability and meaning remain distinct. The effective U.ReferenceScheme is part of episteme identity. The exact U.ClaimScope delimits use; when current for the declaration, a relevant time interval, selected CHR:ReferencePlane, or selected BoundedModelUseStructure : U.Structure further delimits or organizes applicability. None replaces the reference scheme or claim scope.

#Use RelationSignature for reusable relation declaration

RelationSignature is the relation-facing use of one U.Signature. It is not a second U-kind.

Its EntityOfConcernRef identifies one exact already admitted direct relation kind. If A.6.RCD settles a derived relation kind, that kind counts here only after its direct subject settlement states the participant meanings, exact base-definition and named-substrate dependencies, obtaining and applicability laws, and a direct occurrence-identity rule. The derivation or predicate definition may be cited as a dependency, but a predicate-definition episteme whose EntityOfConcern is the reusable predicate definition rather than the admitted relation kind is not a RelationSignature. Its content declares:

• the relation-kind designator;
• one SlotSpec for each world-side participant meaning that needs reusable typed declaration;
• the direct pattern's obtaining predicate and declared laws, restated for reuse without claiming that the predicate is satisfied;
• applicability of those claims;
• the occurrence-identity rule supplied by the direct relation pattern, restated for reuse without applying it to any occurrence;
• for an admitted derived relation kind, the exact base relation definitions, named substrate and authorized derivation operation, and applicability dependencies already established by the direct subject settlement.

The direct relation pattern remains authoritative for when the relation obtains and how an individuated occurrence keeps identity. The signature declares those rules for reuse; it does not make the predicate true and does not create an occurrence.

A direct relation may obtain before anyone writes a signature. Ordinary prose may therefore stop at:

During Shift-17, Robot-7 holds InspectorRole as interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A.

This is an A.2.1 assignment assertion about the already admitted U.RoleAssignment relation kind. A.2.1 defines the direct assignment predicate and occurrence-identity rule; the actual assignment history for Robot-7 and Shift-17 determines whether the predicate is satisfied. When several patterns need to reuse the four participant meanings, predicate, and identity rule, the A.2.1 RelationSignature becomes useful: its A.6.5 SlotSpecs declare those meanings for typed assertion and F.6 work-attribution reuse. When another claim needs to refer to this particular assignment episode, A.6.REL governs explicit individuation.

#Declare participant meanings and operation parameters under different specializations

For each world-side participant meaning whose reusable declaration is current, a RelationSignature declares one A.6.5 SlotSpec. The following code sketch is a compact representation of that declaration, not the world-side relation or its participants:

SlotSpec := <SlotKind, ValueKind, refMode>
refMode := ByValue | RefKind

A.6.5 governs these declarations of participant meanings. Use the exact A.2.1 SlotKind names for this admitted example: HolderSystemSlot, RoleValueSlot, RoleTaxonomyEpistemeSlot, and EffectiveReferenceSchemeSlot. They expose the four participant distinctions without making the assignment interval, a selected model-use structure, or performed work into another participant. Do not force SlotSpecs into a one-off assertion that has no receiving typed use.

A formal or mechanism declaration may instead need named operation arguments and a result. A.6.1 governs that OperationAlgebra; C.29 governs any mathematical operand order, product, function, or tuple used to represent it. Those operation parameters do not become RelationSignature SlotSpecs or SlotKinds merely because the same notation uses angle brackets or numbered arguments. When a relation claim consumes a mathematical representation, state an explicit correspondence between the representation's operands and the independently declared SlotSpecs.

#Expose real declaration dependencies

Open a SignatureManifest only after this test. Add an import when removing one named provider would leave this declaration unable to interpret a required non-local term or unable to replay one of its stated laws; name the provider and the exact required term or law. Add a provide entry when this declaration introduces a named term or law and one named dependent declaration relies on it. A background citation, similar vocabulary, shared publication, list membership, or convenient replay order is not a dependency.

The compatible heading is retained for dependent patterns; it names neither another U-kind nor one uniform ontic object. It co-locates entries with three roles: id is an identity-neutral display designator; signatureRef and its optional .edition pin form a governed reference to an already recoverable signature episteme; and imports and provides may carry or represent dependency and name-or-law introduction claims in the signature's exact U.ClaimGraph. Co-location makes neither every entry identity-bearing claim content nor any entry a relation occurrence.

The compatible section may carry entries with these roles:

A change confined to the spelling of id or the serialization of signatureRef preserves episteme identity only when the reference still resolves to the same episteme and its exact claim content, exact EntityOfConcern, and effective U.ReferenceScheme remain unchanged. Changing signatureRef.edition selects another already recoverable edition; it does not by itself establish an edition relation, historical continuity, or U.Signature membership for the referent. If a C.2.1 identity discriminator changes, A.6.0:4.10 governs the resulting identity.

Use these dependency-manifest predicates:

• SM-1 Term-and-law resolution. Every required non-local term or exact law claim resolves under the effective reference scheme to the one named provider declaration that supplies it.
• SM-2 No redeclaration and legal direction. A provided term or law is not also supplied by a transitive import under the same effective reference scheme, and the claimed provider-to-consumer direction matches the predicate of the exact dependency or source-use relation rather than a drawn arrow or list order.
• SM-3 Replay order and cycles. A selected one-pass provider-to-consumer replay method requires an acyclic ordering of the recovered dependency designations. A cycle means that this replay method cannot run; it does not by itself prove that every semantic dependency in the cycle is prohibited. Apply each exact dependency governor to its edge. If no current governor decides whether the semantic cycle is legal, return an exact missing-governor blocker instead of deleting an edge or inventing an order. Any graph, cycle check, or ordering notation remains a C.29 representation.
• SM-4 Export boundary. A dependent declaration relies on provided names and cited laws, not on private publication layout or implementation detail.

The remove-the-provider test above identifies a candidate dependency; it does not make a relation obtain. State the exact dependency or source-use relation only after its direct predicate is satisfied for the named provider, consumer, term or law, and use. A citation, manifest entry, list membership, or replay result can support an assertion about that relation but does not create the relation occurrence. A provider or provider-edition change may require resolution, replay, or currentness review; it changes the consumer signature's identity only when the consumer's own claim content, exact EntityOfConcern, or effective reference scheme changes.

A governed reference to a separately identified object is not an exported vocabulary name merely because that reference appears in the signature.

#Specialize declaration use without minting another root kind

A signature profile is a constrained use of the same U.Signature kind. The profile states which content is current and which neighboring patterns govern later use.

profile = FormalSubstrate. Declare vocabulary and terms, inference kinds, formal laws, applicability, and the actual declaration dependencies carried in the signature's claim content. A.6.1 separately governs OperationAlgebra, operation designators, typed argument and result positions, admission conditions, application, and realization. An A.6.1 declaration may cite the FormalSubstrate signature; that citation does not make the operation part of this signature. When a mathematical object is selected as a lens for another entity, C.29 governs the lens-use claim; usefulness does not make the mathematical object a signature.

profile = PrincipleFrame. Write the postulates and invariants, then name the observable distinction each one requires: what must be observed or compared to tell whether the frame's claim holds. Cite the separately identified characteristic or measurement declaration that makes that distinction checkable; units, scales, CHR:ReferencePlane values, comparators, and normalizations remain under A.17, A.18, C.16, CHR, A.19.CPM, and A.19.UNM. If the text decides whether a proposed operation application, run, or gate may proceed, move that decision to A.6.1 or the direct evaluation and gate pattern, including A.21/C.11 where applicable. A PrincipleFrame may state what a decision must respect, but it is not that admission decision. When its claim crosses a context or effective reference scheme, use the exact F.9 bridge and state what is preserved and lost. Cited declarations remain independently identified objects, not extra PrincipleFrame identity components.

State a relation between two signatures directly as refinement, conservative extension, equivalence, or another independently governed relation only when that relation's own predicate obtains. Before using the refinement label, compare all three reusable content duties: Vocabulary, Laws, and Applicability. Name the terms preserved, added, or removed; the laws preserved, strengthened, or changed; and whether the population, time, CHR:ReferencePlane, and claim scope stay the same, narrow, or widen. An unexplained applicability widening fails the refinement claim; use another direct relation whose predicate explicitly permits the widening instead of hiding it under refinement. Use a C.29 morphism only when a mathematical structure-preservation claim is actually current.

#Keep declaration, realization, and use under their direct patterns

The rows name the direct patterns that govern these common adjacent objects and claims. Their co-location is only a compact representation and does not change any governing pattern's scope.

#Add explicit objects only for a named receiving use

Make three decisions by naming the next sentence, comparison, tool, or declaration that must work:

1. State the direct relation and stop. Use this branch when the task only asks whether the A.2.1 assignment predicate holds for the named holder, role, taxonomy episteme, and reference scheme during the named episode. For example, During Shift-17, Robot-7 holds InspectorRole as interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A is a complete current assignment assertion. State an affirmative or negative claim under A.2.1, or an exact governed modal claim when that family is current. The A.2.1 predicate defines the test; the actual assignment history decides the case. Add an A.10 or receiving-evaluation reliance judgment only when the task separately asks whether to rely on the assertion.
2. Share one declaration. Reuse or author a signature when at least two named claims or consumers must use the same participant meanings, vocabulary, laws, or applicability. For example, a staffing assertion and an F.6 work-attribution consumer that must interpret HolderSystemSlot, RoleValueSlot, RoleTaxonomyEpistemeSlot, EffectiveReferenceSchemeSlot, and the same A.2.1 assignment predicate can cite one RelationSignature. One sentence that merely repeats the word assigned does not open this branch. When a declaration is authored, C.2.1 identifies the episteme from its own claim content, exact EntityOfConcern, and effective reference scheme; A.6.0 then judges U.Signature membership.
3. Distinguish one occurrence. Open occurrence identity only when a later claim must refer to that same occurrence, compare or qualify it, track its beginning, continuation, cessation, or change, or use it as a participant of another relation. For example, F.6 work attribution must cite the exact covering assignment episode, and a staffing history that compares Shift-17 with a later reassignment must apply A.2.1's uninterrupted-obtaining same-versus-new-occurrence rule. A roster-row identifier that merely designates an assertion identifies neither the assignment occurrence nor a new occurrence; use F.18 only after A.2.1 has distinguished the occurrence to which a reference should resolve.

These are the receiving-use thresholds. They concern three different objects and are not stages that construct a relation or episteme from need. The stop is observable: the target direct assertion, shared declaration for the named consumers, or occurrence-referencing claim can be written without another unresolved object. Authoring, selecting, reusing, or explicitly individuating is motivated by that target but supplies no identity criterion and creates neither the episteme nor the relation occurrence. Selecting or reusing an unchanged episteme leaves its identity unchanged; neither a reference nor a log entry creates its referent. A claim about condition-dependent entries, branches, returns, or stops is a CGUS claim governed by A.22.CGUS.

#Recover formal-substrate and PrincipleFrame uses by direct governing relation

The same independently identified formal object or episteme can participate in these different uses while retaining its own identity and kind. Its identity does not decide which declaration, dependency, operation, lens, or carry-through relation is current.

For a PrincipleFrame, write one postulate or invariant together with the observable difference that would count for or against it. Cite a characteristic, measurement, unit, scale, reference plane, comparator, or normalization declaration only when that declaration is needed to state or check that difference; an informative citation is not a dependency. Do not put an operation-admission, run-acceptance, or gate-passage verdict into the frame. If the frame's claim is carried into another context or reference scheme, name the F.9 bridge occurrence and its preservation and loss before using the claim there. A cited declaration may be superseded, or an independently obtaining dependency relation may cease or be replaced, without retroactively changing the PrincipleFrame's identity. Changing the PrincipleFrame's own citation or dependency claim changes its claim content and therefore identifies another episteme; the same follows when its exact EntityOfConcern or effective reference scheme changes. Any edition, refinement, or supersession relation between the two epistemes must independently obtain and must pass the Vocabulary-Laws-Applicability comparison above.

#Change the exact object that changed

Apply C.2.1 first. Every U.Episteme is identified by exact claim content carried by one exact U.ClaimGraph, one exact EntityOfConcern, and one effective U.ReferenceScheme. Changing any member of this mandatory triple identifies another episteme. That episteme is a U.Signature only when it independently satisfies A.6.0 membership. A changed discriminator, SignatureId, or signatureRef.edition value does not by itself establish signature membership or historical continuity.

A change to imports or provides changes the consumer signature's identity only when it changes that signature's own claim content. A changed provider or provider edition can instead leave the consumer episteme unchanged while requiring the named dependency or source-use assertion, resolution result, replay result, or currentness judgment to be reconsidered.

A changed later use does not change the signature unless the change alters one of its C.2.1 identity discriminators. For example, a new mechanism realization remains a new realization, and a new publication layout remains a new publication form.

Connect two different epistemes by EpistemeEditionRelation, refinement, supersession, or another independently governed continuity relation only when that relation's own predicate obtains under its direct governor. Revision work, shared title, changed identifier, citation, or sequence alone establishes no such occurrence.

When a once-current signature becomes stale while its identity remains recoverable, G.11 governs currentness and selection among recoverable editions. G.11 creates neither a later episteme nor an edition, refinement, or supersession relation.

Reopen declaration authoring when a proposed change affects the signature's exact claim content, EntityOfConcern, effective reference scheme, declared dependency, Vocabulary, Laws, Applicability, or the boundary of a FormalSubstrate, PrincipleFrame, or other admitted profile. The revised claim-bearing candidate is another C.2.1 episteme; A.6.0 judges its signature membership again, and any edition, refinement, or supersession relation remains a separate claim under its direct governor. Also reopen the affected declaration element when current problem-owning-domain or formal-method SoTA changes the term, inference form, law shape, applicability condition, or realization boundary being declared.

When a governed kind name, SubjectKind, RangedValueKind, SlotKind, RefKind, or exported term is renamed, rerun E.10 and F.18. Accept the rename only when a cold reader can still recover the same FPF kind, declaration use, and practical action; otherwise keep the old name or return the naming defect. Do not revise the signature merely because a realization, work occurrence, measurement, Bridge use, evidence-use relation, publication, provider currentness, or G.11 selection changed. Update that neighboring object under its direct owner, and reopen the signature only if its own claim or dependency content must change.

#Archetypal Grounding

#Physical modeling: connector-equation FormalSubstrate

A multi-domain modeling team repeatedly uses one connector-and-equation calculus. Its U.Signature(profile=FormalSubstrate) has that calculus—not a connection relation kind—as its exact EntityOfConcernRef. SubjectKind names the modeled connector declarations governed by the calculus, and RangedValueKind names its well-formed terms and equations. Vocabulary names the potential and flow variables. Its inference and equation laws say how a selected connection assertion yields potential equality and the zero-sum flow equation. Applicability states the modeling assumptions and selected CHR:ReferencePlane. If those terms or laws cannot be interpreted or replayed without a named quantity declaration, the manifest names that provider and the exact imported term or law; otherwise a background citation stays outside the dependency manifest.

The sentence ModeledPort_A is connected to ModeledPort_B is a separate model-side connection assertion. This FormalSubstrate neither supplies that relation kind nor makes the assertion true. If repeated typed connection claims require a RelationSignature, first recover or admit the exact modeled-connection relation kind, its two connectable-port participant meanings, direct predicate, qualifier laws, Applicability, and occurrence-identity rule; only then may that relation declaration cite this FormalSubstrate when the dependency test passes. A generated equation set and a connector diagram are later result and representation epistemes, not either declaration; deeper operation, work, representation, and publication questions return to A.6.1, A.15.1, C.29, and E.24.PUB.

Practical payoff: engineers can compare the connector vocabulary and equation laws across tools without treating the calculus as a connection relation, a concrete connection assertion, a generated equation set, or a diagram.

#Clinical work: dose-response claim before relation-kind admission

A clinician needs the ordinary claim: During PatientEpisode_8472, Intervention_5mg was associated with OutcomeChange_BPminus10 over ObservationWindow_Days0to28 under the stated dosing and population conditions. No current direct pattern in this corpus governs a DoseResponseRelationKind. For this use, A.6.RCD therefore keeps the sentence as a local compound claim in one C.2.1 episteme; repeated clinical uses may justify a reusable predicate-definition episteme, but neither result is a RelationSignature or a relation occurrence.

The local predicate treats the named patient episode, intervention, outcome change, and observation window as its exact inputs. ObservationWindow_Days0to28 answers how long this patient's outcome change is aggregated for this assertion. The claim's or reusable definition's Applicability instead states the population, dosing protocol and conditions, and the time and claim scope in which the rule is used. Do not repeat the patient window as Applicability unless a separate applicability claim genuinely uses that same interval. Before any RelationSignature can be published, the missing-governor result must name the candidate relation kind, these participant meanings, the direct predicate, Applicability, occurrence-identity rule, and a standalone clinical domain governor; E.24/E.24.UK must admit the result. Until then, no plausible SlotKind names or mention of a response creates that settlement.

A selected assay-result episteme may support or refute reliance on the compound assertion through A.2.4/A.10, but it does not make the clinical predicate true. A changed assay result changes that support or leaves it unresolved; it does not change the reusable predicate definition. A changed outcome meaning, population, dosing condition, or declared applicability changes the definition's claim content and C.2.1 identity, while still admitting no relation kind by itself.

Practical payoff: clinicians and analysts can write and compare the bounded claim now, reuse a settled predicate definition when repetition warrants it, and keep patient episodes, evidence epistemes, and evidence-use claims distinct without pretending that a clinical relation signature already has a governor.

#Learning: criterion declaration and evidence use

During AssessmentInterval_2026Q2, learner Learner_17 correctly diagnoses cavitation in PumpCase_A and PumpCase_B and selects the stated corrective action. A separate observation episteme, PerformanceObservation_17A, states what was observed. After applying the reusable declaration Criterion_PumpCavitationDiagnosis_v3, assessor Assessor_4 makes the separate competence-assertion episteme CompetenceAssertion_17_Q2: Learner_17 met Criterion_PumpCavitationDiagnosis_v3 for diagnosing cavitation and selecting the stated corrective action in PumpCase_A and PumpCase_B during AssessmentInterval_2026Q2.

Criterion_PumpCavitationDiagnosis_v3 is the reusable declaration governed here. Its EntityOfConcernRef identifies the pump-cavitation diagnosis criterion; SubjectKind names assessed pump-cavitation diagnostic performances and RangedValueKind names the results meets and does not meet. Vocabulary defines the cases, diagnosis, and corrective action; Laws say which observable response earns either result; Applicability limits the equipment family, task form, and assessment method. The observed performance, its observation episteme, the criterion, and the assessment interval are not relation SlotSpecs merely because the competence claim mentions them. No current direct pattern supplies DemonstratedCompetenceRelationKind, so this case asserts neither that relation signature nor a world-side demonstrated-competence occurrence.

For this bounded assessment use, the direct A.2.4/A.10 evidence-use relation names PerformanceObservation_17A as EvidenceEpisteme, the quoted competence claim as EvidenceTargetClaim, the two specified cases as EvidenceClaimScope, supports as EvidencePolarity, and AssessmentInterval_2026Q2 as EvidenceRelevanceWindow. Its A.10 evidence-provenance path identifies the observation work, method, carrier, and assessor's relying context. That relation supports reliance on this exact competence claim; it does not make the claim true or authorize course progression. A self-report without that observation path, a performance on another task, or a performance outside the named interval does not support this bounded claim.

Changing the publication form or making another publication occurrence for the unchanged criterion or competence assertion changes neither episteme. Changing the criterion's Vocabulary, Laws, or Applicability changes its claim content and identifies another declaration episteme; any edition or continuity relation must separately obtain. A new performance observation or assessor claim likewise identifies separate evidence or claim content rather than changing the criterion declaration.

Practical payoff: two assessors or curriculum tools can reuse the same declared criterion and its performance-and-result meanings while making separately identified competence claims about separately observed performances.

#Formal work: length-indexed zero-vector operation

An engineer declares the reusable operation zeroVector(n) in ordinary language: give it a natural number n; it returns a vector of n real-valued entries, every one zero. In the A.6.1 OperationDeclaration, argument lengthIndex means the requested component count and has ValueKind NaturalNumber. Result zeroVectorResult means the returned zero vector and has the indexed result family FiniteVector(RealScalar, n). The application predicate says that one application binds one n and returns that vector. The dependency law states length(zeroVector(n)) = n, and the zero law states that every indexed entry equals scalar zero. Applicability limits this declaration to finite vectors over the declared RealScalar field.

The declaration imports the exact type-former FiniteVector(RealScalar, n) and its length-index law from FormalSubstrate signature FiniteVectorSubstrate_v2. Remove that provider and neither the result declaration can be interpreted nor the length law replayed, so this is a declaration dependency rather than a background citation. The operation argument and result remain A.6.1 declarations; they are not A.6.5 relation SlotSpecs.

A Lean representation may write the result as Vector Real n. A proof-carrying record representation may write entries: List Real together with lengthProof: entries.length = n. Because both represent the same operation declaration and no mathematical lens changes the next comparison action, A.6.3.RT alone governs this representation-scheme transition. It preserves the result-length index and the all-zero law. Lean binder order, implicit elaboration, record field order, and the location of the length proof are representation-local and need not survive. Stop here: neither notation's operand or field order becomes operation meaning or world-side relation ontology, and no C.29 result is needed. If a later comparison uses a named free-module lens to decide algebraic reuse, that changed lens use opens C.29 and must separately state the preserved addition and scalar action, the lost coordinate or layout detail, and the inference that the lens does not license.

Practical payoff: formal-methods engineers can fill and inspect the dependent A.6.1 declaration, test its actual FormalSubstrate dependency, and compare representations without inventing a neighboring relation signature.

#PrincipleFrame: heat-flow balance

A thermal-modeling team writes a PrincipleFrame stating that net heat flow across a selected system boundary must balance the change in stored energy. The frame names the observable distinction between inward and outward heat flow at that boundary. It cites separately governed heat-flow characteristics, units, the selected CHR:ReferencePlane, and the measurement declaration needed to check that distinction; its Applicability names the modeled systems and conditions for which the balance claim is made.

A residual below a chosen tolerance does not by itself belong to the PrincipleFrame and does not admit a simulation run. The comparator and tolerance remain under their direct comparison and measurement owners; operation admission remains under A.6.1, and a gate-passage verdict remains under A.21/C.11. If a laboratory measurement scheme is used in a plant-model scheme, F.9 must name the bridge and the preservation or loss of sign convention, unit, and boundary interpretation.

Practical payoff: the physical principle remains reusable while the measurement setup, comparator, run decision, and cross-scheme transport can change or fail independently.

#Reduced ordinary-use case

The sentence During Shift-17, Robot-7 holds InspectorRole as interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A is enough for a task that only reports whether the A.2.1 assignment predicate holds for those participants during that episode. Stop there. If a staffing assertion and an F.6 work-attribution consumer must reuse the same four participant meanings and assignment laws, cite the existing A.2.1 RelationSignature. If later work attribution or history must refer to this assignment and distinguish it from a later reassignment, apply A.2.1's direct occurrence-identity rule and refer to the distinguished episode. A roster-row id that merely points to the assertion opens neither branch. Each result is complete for its stated task; the shorter result is not an incomplete signature.

#Bias-Annotation

Scope declaration: Universal across FPF-governed domains.

• Gov. Favors making the direct governor of declaration membership, declared content, and neighboring claims inspectable, together with explicit dependencies. Counter-risk: declaration administration can grow beyond reuse value. Mitigation: add SignatureManifest only for actual dependency.
• Arch. Favors a small declaration core with direct neighboring patterns. Counter-risk: the signature becomes a central container. Mitigation: keep realization, work, evaluation, and publication with their direct patterns.
• Onto-Epist. Favors strict separation of declaration episteme, declared subject, obtaining occurrence, assertion, and representation. Counter-risk: excessive explicitness. Mitigation: stop at the direct assertion unless two named consumers share declaration content or one later claim must distinguish the occurrence.
• Prag. Favors reusable named SlotSpecs and laws. Counter-risk: one-off work becomes formal paperwork. Mitigation: ordinary direct sentences remain sufficient.
• Did. Favors the four content groups and local mantra. Counter-risk: readers mistake the mnemonic order for executable work. Mitigation: A.22.CGUS governs any claimed executable conditional continuation.
• Context transport. A signature's claims mean only what their stated scope and effective reference scheme make them mean. Counter-risk: the same label in another context is treated as equivalent or safely substitutable. Mitigation: before cross-context or cross-scheme reuse, apply F.9 to name the local senses, Bridge kind and direction, declared loss, and admitted use; without that result, do not transport the claim by label alone.
• Comparability. Two declarations do not become comparable because both expose numbers. Counter-risk: numeric appearance hides incompatible characteristics, measurement procedures, units, scales, comparators, or normalization. Mitigation: apply the current A.17/A.18/C.16 characteristic, measurement, unit-and-scale owners and A.19.CPM/A.19.UNM comparison and normalization owners as the case requires, then state the resulting comparison boundary; keep their detailed legality and result-shape rules with those owners.
• Register. Begin each technical declaration block and worked case with, or immediately supply, an ordinary sentence naming what the practitioner asserts or does and what visible result follows; then map that sentence to the exact FPF terms. Counter-risk: a technically correct block remains unusable without private decoding. Mitigation: use E.10's Plain-intent step, scan the recovered wording, and rescan every replacement; keep the repair only when the same governed object, owner, admissible use, and practical action remain clear.

The examples deliberately span physical modeling, medicine, learning, and formal work. Each worked declaration has its own C.2.1 identity, which remains independent of its publication form; the examples do not share one declaration individual.

#Conformance Checklist

1. Exact declaration object. The text identifies one U.Signature episteme and one exact EntityOfConcernRef.
2. Identity. Content, EntityOfConcern, and effective U.ReferenceScheme remain recoverable.
3. Minimum content. SubjectKind and RangedValueKind, together with Vocabulary, Laws, and Applicability, carry semantic content rather than empty publication rows. ResultKind, SliceSet, and ExtentRule appear only when their declared distinctions are current.
4. Optional slice-dependent membership. SliceSet names the addressable U.ContextSlice values to inspect and ExtentRule determines Extension(SubjectKind, slice) only when the same declared kind can have different members across those slices; neither field stands for a generic interval, range, changing dataset, or set representation.
5. Vocabulary boundary. A declared token is not treated as durable U-kind admission without E.24.UK and its direct pattern.
6. Relation declaration. A RelationSignature identifies one exact already admitted direct relation kind. An admitted derived relation kind has direct subject settlement for participant meanings, base-definition and named-substrate dependencies, obtaining, applicability, and occurrence identity. A predicate-definition episteme is not treated as that RelationSignature, and the declaration does not assert or create an occurrence. Every worked case that uses a RelationSignature also names the already admitted relation kind, direct governor and predicate, participant meanings, Applicability, occurrence-identity rule, and one ordinary affirmative or negative assertion. A hypothetical domain-local relation kind is labelled and fully settled before the example uses it.
7. Direct relation-pattern governance. The direct relation pattern governs obtaining and occurrence identity.
8. Typed-declaration boundary. Reused participant meanings are declared inside a RelationSignature by A.6.5 SlotSpecs with exact SlotKind, ValueKind, and refMode. Operation arguments and results remain A.6.1 declaration content. Mathematical operands and field order remain representation-side under A.6.3.RT; C.29 opens only when a named mathematical lens changes the declared lens use or next comparison action. An operand-to-participant correspondence is stated only for an already governed relation claim.
9. Semantic locality. Meaning uses the effective reference scheme; applicability uses the exact claim scope and only qualifiers current for the declaration, such as a relevant time interval, selected CHR:ReferencePlane, or genuinely current model-use structure.
10. Dependency truth. Every import names the provider and exact term or law without which interpretation or law replay fails; every provide entry names a dependent declaration that relies on the introduced term or law. Citations and list order do not qualify. SM-1 through SM-4 hold, and a replay cycle is distinguished from a semantic-prohibition verdict.
11. Realization boundary. Mechanism behavior and admission conditions remain with A.6.1.
12. Progressive elaboration. A direct assertion is enough when the task only asks whether the predicate holds; a signature opens when at least two named consumers share declaration content; occurrence identity opens only for a later same-occurrence reference, comparison, qualification, history/change claim, or relation participation. A log or assertion identifier alone opens none of them.
13. CGUS boundary. Mnemonic imperatives are not called an executable sequence; any condition-governed unfolding claim uses A.22.CGUS.
14. Profile boundary. FormalSubstrate and PrincipleFrame remain profiles of U.Signature rather than new root kinds. A PrincipleFrame names its postulates and the observable distinctions needed to check them, leaves operation and gate admission with their direct owners, and uses F.9 before carrying its claim across a context or reference scheme.
15. Changed object. Changed exact claim content carried by the U.ClaimGraph, exact EntityOfConcern, or effective reference scheme identifies another episteme. Judge A.6.0 membership for that episteme independently, and assert edition, refinement, supersession, or another continuity relation only when its own predicate obtains. A changed use, identifier, publication form, carrier, provider currentness, or G.11 refresh state does none of those things by itself.
16. E.10 self-application and reader use. Every materially changed technical declaration, mantra, checklist instruction, and worked case begins with, or immediately supplies, one ordinary claim, the practitioner action, and the visible result, then maps them to the exact FPF terms. Apply E.10 by value: unpack the decisive FPF terms locally, rescan the replacement candidate, run the value-substitution and cold-reader closure checks, and state one nearby non-use or alien case. A Plain label without those reader-visible results does not pass.
17. Case-level witness. Each worked case names its exact EntityOfConcern, the direct pattern that governs the claim being made, what the practitioner can now write, decide, or inspect, and the nearest category error it rejects. A domain label or the presence of several case headings is not evidence of cross-domain fit.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits.

• Reusable declarations receive one stable episteme identity.
• RelationSignature epistemes can expose named typed SlotSpecs without forcing every relation occurrence into a record.
• Meaning becomes inspectable through the exact reference scheme; applicability becomes inspectable through the exact claim scope plus any current time interval, selected CHR:ReferencePlane, or selected model-use structure.
• In physical-modeling practice, an author can reuse one connector-equation FormalSubstrate while keeping a modeled connection assertion, generated equations, and a diagram separate from that declaration.
• In clinical practice, an author can write the bounded patient-episode, intervention, and outcome assertion now, relate an assay-result episteme to that claim through A.2.4/A.10, and defer a RelationSignature until a direct clinical relation governor exists.
• A changed realization, observation, evidence-use relation, or publication can be repaired independently when the declaration's own claim content, EntityOfConcern, and effective reference scheme remain unchanged.

Costs and trade-offs.

• Before choosing a form, the author answers three concrete questions: does the task only ask whether one predicate holds; do at least two named consumers need the same declaration content; or does a later claim need to refer to the same occurrence, compare it with another, qualify it, record its history, or use it as a participant in another relation? Those answers select a direct assertion, reusable declaration, or occurrence identity.
• Authors must recover the exact declared subject and effective reference scheme; a familiar label is not enough.
• A RelationSignature case also requires an already admitted relation kind, direct governor and predicate, participant meanings, Applicability, occurrence-identity rule, and an ordinary assertion. Without that settlement, the author keeps a local claim, predicate definition, or exact missing-governor blocker instead of inventing SlotSpecs.
• Typed reuse adds authoring effort for A.6.5 relation SlotSpecs or A.6.1 operation declarations, plus A.6.0 dependency declarations only when another signature actually relies on named terms or laws.
• A change to exact claim content, EntityOfConcern, or effective reference scheme identifies another episteme even when the publication looks identical; authors must separately judge U.Signature membership and any claimed edition, refinement, or supersession relation.

#Rationale

The ontic is needed because the same reusable declaration is cited across work occurrences, publication occurrences, and representations. Treating it as only a table-shaped publication form loses identity; treating it as the declared world-side object collapses episteme and EntityOfConcern.

The declaration components answer four different engineering questions. SubjectKind, RangedValueKind, and optional ResultKind identify the declared subject and value or result range. When slice-dependent membership is current, SliceSet names the addressable context slices and ExtentRule says how the members of the same declared kind are determined at one slice. Vocabulary supplies reusable names and, for a RelationSignature, named participant SlotSpecs; A.6.1 supplies operation arguments and results for a mechanism declaration. Laws state the reusable regularities. Applicability states where those regularities are used. Their conceptual separation is stable even when publication layout changes.

RelationSignature is a use of U.Signature because it has the same episteme identity and content duties. Introducing a second root kind would duplicate those duties while leaving obtaining and occurrence identity with direct relation patterns anyway.

Progressive elaboration protects didactic primacy. A practitioner can begin with a readable relation sentence and add formal declaration only when reuse creates value. Exactness is increased for a named claim or operation, not for ceremony.

#SoTA-Echoing

Sources:

• Modelica Association, Connectors and Connections.
• Lean project, Inductive Types and Structures.
• TypeDB, relates statement.
• W3C, SHACL 1.2 Core.
• Almeida, Guizzardi, Sales, and Fonseca, gUFO: A Gentle Foundational Ontology for Semantic Web Knowledge Graphs.

These sources test the separation among declaration, represented structure, realization, and use. FPF's constructive ontology, C.2.1 episteme identity, A.6.5 relation-slot discipline, A.6.1 operation declaration, and direct relation patterns remain authoritative for the solution.

#Relations

• Builds on: A.7, C.2.1, C.3, A.2.6, and A.6.5.
• Governs: reusable U.Signature declaration epistemes, including RelationSignature use and the FormalSubstrate and PrincipleFrame profiles.
• Constrained by: E.10 for the register and usability of materially changed technical declaration blocks, the mantra, checklist instructions, and worked cases. The local result must expose the ordinary claim or action and the decisive governed terms to a cold reader; E.10 owns the trigger scan and wording-repair method.
• Coordinates with: A.6.REL for relation occurrence, A.6.RCD for needed-claim derivation and relation-kind settlement before declaration, A.6.1 for mechanism declaration and realization, A.3.1 for methods, A.15.1 for work, F.9 for explicit bridge use, A.17, A.18, C.16, A.19.CPM, and A.19.UNM for characteristic, scale, comparison, and normalization questions, C.29 for mathematical-lens use, and E.24.UK for durable U-kind admission.
• Described and published through: C.2.1, E.17, and E.24.PUB.
• Evolves with: G.11 for currentness and explicit direct relations between signature editions.
• Used by: C.22 task signatures for A.6.0 declaration identity and content; a changed C.22 discriminator identifies another episteme and establishes an edition only when the direct continuity predicate obtains. Also used by A.19.CPM comparison declarations, A.19.SelectorMechanism selection declarations, C.29 and E.18.1 when their current claim requires a FormalSubstrate declaration, and any pattern that needs reusable vocabulary, laws, applicability, or relation SlotSpecs. Specialized operation declarations remain under A.6.1 rather than A.6.0.

#A.6.0:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)