#U.Signature — Universal, law‑governed declaration

A.6.0 · Stable · 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.

Status: Stable

Status. Architectural pattern, kernel‑level and universal. Placement. Part A (Kernel), before A.6.1 (“U.Mechanism”). Builds on. A.2.6 (USM: context slices and scopes), E.8 (pattern form and section order), E.10 LEX-BUNDLE (registers, naming, stratification), E.10.D1 D.CTX (Context discipline).

Coordinates with. A.6.1 (U.Mechanism), A.6.5 (U.RelationSlotDiscipline for n-ary arguments), E.5.3 (Unidirectional Dependency), E.10 (LEX-BUNDLE), and Part F (harnesses and cross-context transport; naming). Conformance keywords: RFC 2119.

Use this pattern when you need to publish or check a reusable U.Signature declaration for a theory, mechanism family, method family, discipline vocabulary, U.Signature(profile=FormalSubstrate), or PrincipleFrame, and the question under repair is: what subject kind is declared, over what ranged-over type, with which vocabulary, laws, and applicability?

#Keywords

• signature
• vocabulary
• laws
• applicability
• bounded context.

#Relations

#Content

#Use and boundary

Use this pattern when you need to publish or check a reusable U.Signature declaration for a theory, mechanism family, method family, discipline vocabulary, U.Signature(profile=FormalSubstrate), or PrincipleFrame, and the question under repair is: what subject kind is declared, over what ranged-over type, with which vocabulary, laws, and applicability?

Do not use this pattern when the claim being made is that some implementation runs, a handler realizes an effect, a method is authorized for work, a gate has passed, evidence proves a result, a measurement is comparable, or a bridge preserves enough structure across contexts. Those claims use A.6.1, A.15, gate, evidence, characterization, normalization, bridge, or decision patterns after the signature declaration is stable.

First useful move: write the four-row Signature Block before writing examples or realizations: SubjectBlock, Vocabulary, Laws, Applicability. Then add a SignatureManifest only when another signature imports this one or downstream text depends on its exported symbols.

What goes wrong if missed: a project may treat implementation detail, tutorial prose, bridge policy, measurement comparability, or handler behavior as if it were part of the public declaration. That makes reuse brittle because downstream work cannot tell what law is being reused and what later realization merely happened to satisfy it.

What this buys: the same declaration shape can be reused for mechanisms, methods, disciplines, U.Signature(profile=FormalSubstrate) declarations, and principle frames, while realizations, measurements, bridges, and work authorization stay in their own governing patterns.

#Problem frame

FPF already uses “signatures” to stabilise public promises of reusable extension vocabularies and, via A.6.1, of mechanisms. But declaration publishers also need stable, minimal declarations for theories, methods (operational families), and disciplines (regulated vocabularies). Without one universal notion of signature:

• similar constructs proliferate under incompatible names;
• practitioners cannot tell what is declared (EntityOfConcern kind and laws) versus what is realized or admitted for specification use;
• cross-context reuse lacks a canonical place to state applicability and declared admissible vocabularies.

E.8 demands one publication voice and section order; E.10 demands lexical discipline across strata. A.6.0 provides the common kernel shape these patterns presuppose.

#Problem

If each family (theories, mechanisms, methods, disciplines) invents its own “signature”:

1. Tight coupling. Private definitions leak as public standards, breaking substitutability.

2. Lexical drift. The same lexical label (e.g., scope, normalization) hides different laws.

3. Scope opacity. Applicability (where the words mean what) remains implicit, violating D.CTX.

#Forces

#Solution — Define U.Signature once, reuse everywhere

Definition. A U.Signature is a public, law-governed declaration for a named SubjectKind on a declared BaseType. The Signature SHALL expose an explicit SliceSet and ExtentRule; if quantification is context-independent, the declaration MUST use a trivial SliceSet (e.g., a singleton) and a constant ExtentRule rather than omitting these fields. A Signature (i) introduces a vocabulary (types, relations, operators), (ii) states laws (axioms and invariants; no operational admissions), and (iii) records applicability (where and under which contextual assumptions the declarations hold). Dependencies (imports) and exported names (provides) are declared in a SignatureManifest (see §4.4.1) and are not part of the four-row Signature Block. Discipline for argument-position typing is delegated to A.6.5 U.RelationSlotDiscipline: whenever the Vocabulary declares an n-ary relation or operator, SlotSpecs for its parameter positions SHALL be provided as in §4.1.1 and A.6.5.

Where the Vocabulary introduces an n‑ary relation or morphism, the Signature SHALL, for each parameter position i, declare a SlotSpec_i = ⟨SlotKind_i, ValueKind_i, refMode_i⟩ as defined in A.6.5 U.RelationSlotDiscipline. SlotSpecs live inside the per‑relation parameter block of the Vocabulary row and MUST NOT introduce additional rows beyond the four‑row Signature Block.

Arrow form (typing for MVPK). Express a Signature as a morphism SigDecl : ⟨SubjectBlock⟩ → ⟨Vocabulary × Laws × Applicability⟩ where SubjectBlock = ⟨SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?⟩. This makes U.Signature directly consumable by E.17 MVPK (publication of morphisms) without adding semantics on faces (no new claims; pins for any numeric content).

Guard clarification (normative). Operational guard predicates (run‑time or admission guards) BELONG ONLY to A.6.1 Mechanisms. A Signature may express domain and type constraints as declaration-level constraints (e.g., restricting an operator’s domain) but SHALL NOT encode operational admissions.

Guidance for profile=FormalSubstrate signatures. Signatures that declare a formal-deductive profile (e.g., FormalSubstrate) MAY include, as vocabulary elements, an EffectDiscipline (algebraic, row, or graded effect signatures) and InferenceKind enumerations; handler semantics are out of scope for Signatures (see §4.3). The universal block remains conceptual and contains no run-time admissions or AdmissibilityConditions.

Naming discipline. The Subject MUST be a single‑sense noun phrase; avoid synonyms or aliases within the same Signature.

A U.Signature is conceptual: it contains no implementation, no packaging or CI metadata, and no Γ-builders. If a family wants to expose a Γ‑like builder or aggregator, publish it outside the Signature Block (typically as an A.6.1 Mechanism‑level operator) and namespace it under the Signature id; do not treat Γ as part of the canonical Vocabulary.

#The Signature Block (universal form)

The four conceptual rows (“SubjectBlock, Vocabulary, Laws, and Applicability”) give a repeatable, holon‑stable pattern across mathematics → physics → engineering:

• SubjectBlock = what it’s about + how quantified (axiomatics + domain of interpretation),
• Vocabulary and Laws = principles and laws (postulates and constraints),
• Applicability = where they hold in practice (bounded context and time).

Every U.Signature SHALL present a four‑row conceptual block (names are universal; family-specific projections are stated below):

1. SubjectBlock — ⟨SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?⟩. SubjectKind names the EntityOfConcern kind declared by the signature (C.3); BaseType is the U.Type the signature ranges over (CHR Spaces appear here as types, not as field names); SliceSet addresses the quantification domain (USM; e.g., ContextSliceSet); ExtentRule computes Extension(SubjectKind, slice) (C.3.2); ResultKind? (optional) is the output kind when outputs differ from the SubjectKind. Editorial split (allowed). Authors MAY render the SubjectBlock as two adjacent lines — Subject (SubjectKind, BaseType) and Quantification (SliceSet, ExtentRule, ResultKind?) — without changing semantics. Even when visually split, SubjectBlock counts as one conceptual row.

   Semantic functions of the SubjectBlock kinds (informative)

   • SubjectKind (EntityOfConcern kind). The EntityOfConcern kind declared by the signature (C.3.1), ordered by ⊑. It carries no Scope.
   • BaseType (ranged-over type). The U.Type over which values or entities are ranged. In CHR regimes this may be a U.CharacteristicSpace type; elsewhere it is a set‑typed U.Type.
   • SliceSet (addressability). The addressable set of U.ContextSlices (USM). It identifies where extent is computed; it is not a “space” unless CHR.
   • ExtentRule (extent). A rule yielding Extension(SubjectKind, slice) (C.3.2); this is the quantifier’s domain, computed per slice.
   • ResultKind? (outputs). Optional: the output kind for operations declared in Vocabulary (use when outputs differ in kind from the SubjectKind).

2. Vocabulary — names and sorts of the public types, relations, and operators this signature commits to (no handler semantics; no AdmissibilityConditions). For each n‑ary relation or morphism in the Vocabulary, parameters SHALL be declared via SlotSpecs SlotSpec_i = ⟨SlotKind, ValueKind, refMode⟩ per A.6.5 U.RelationSlotDiscipline. SlotKinds and RefKinds MUST follow the …Slot and …Ref lexical discipline in A.6.5 and E.10 (LEX‑BUNDLE); ValueKinds MUST remain free of these suffixes. (No additional rows beyond the four‑row Signature Block.)

3. Laws (Axioms and Invariants) — equations and order and closure laws that are context‑local truths under the stated Applicability (no proofs here). Operational guard predicates belong to Mechanisms (A.6.1), not to Signatures.

4. Applicability (Scope and Context) — conditions under which the laws are valid (bounded context, plane, stance, time notions). Applicability MUST bind a U.BoundedContext (D.CTX). Applicability here is the context of meaning for the Signature’s vocabulary and laws; it MUST NOT be used to encode claim‑level applicability, which remains a Scope on claims (USM and C.3.2). Cross‑context use MUST NOT be implicit; if intended, name the Bridge (conceptual reference only). When numeric comparability is implied, bind legality to CG‑Spec and MM‑CHR (normalize‑then‑compare; lawful scales and units).

Mapping to existing families (normative projection correspondences). — A.6.1 (Mechanism). SubjectBlock ↔ SubjectKind, BaseType, and the remaining SubjectBlock fields; Vocabulary ↔ OperationAlgebra; Laws ↔ LawSet; Applicability remains contextual; AdmissibilityConditions — separate field of mechanism (not in the U.Signature). — Task, Problem, and Discipline signatures (C.22, G-cluster). These SHALL be introduced as species of U.Signature that reuse the same four-row Block (SubjectBlock, Vocabulary, Laws, and Applicability); any extra per-family views are projections only (no new conceptual rows).

Optional projection views (normative). Publications MAY include additional projection views (e.g., a Dependency View listing imports and provides, or an Assurance View listing audit and evidence hooks), but such views:

1. MUST be mechanically derivable from SignatureManifest + the four‑row Block (and referenced ClaimIds where used), and
2. MUST NOT introduce new semantics, obligations, or “extra rows”.

#SlotSpec for argument positions (normative; see A.6.5)

For every n‑ary relation or operator declared in the Vocabulary row, the Signature SHALL assign, to each argument position, a SlotSpec triple:

SlotSpec_i := ⟨SlotKind_i, ValueKind_i, refMode_i⟩

where:

• SlotKind_i is a named position in the relation or operator (Tech name with …Slot suffix) whose semantics are documented (see A.6.5).
• ValueKind_i is the FPF type (U.Kind or kernel‑level type) of admissible values at that position.
• refMode_i is either ByValue or a RefKind (e.g., U.EntityRef, U.HolonRef), indicating whether the episteme stores values directly or references or identifiers.

Full discipline and lexical rules for SlotKind, ValueKind, and RefKind are given in A.6.5 U.RelationSlotDiscipline and E.10 (§8.1). A.6.0 requires that every vocabulary‑level relation or operator that takes arguments declare these SlotSpecs; downstream patterns MAY provide templates for common shapes (e.g., episteme slots in C.2.1).

Mini‑example (informative). For an episteme kind ModelEvaluationResultKind, a simplified episteme might expose:

• entityOfConcernRef : U.MethodRef
• datasetRef : U.EntityRef
• metricRef : U.CharacteristicRef
• groundingHolonRef : U.HolonRef
• claimGraph : U.ClaimGraph

A SlotSpec table then states:

This example illustrates the intended interpretation: parameters are typed twice—once by their ValueKind (what sort of value fills the position) and once by refMode (by‑value or which RefKind). SlotKinds (with …Slot suffix) give stable names for substitution laws and EntityOfConcern statements across patterns.

#Profile specialisations (normative; structure‑preserving)

To enable first‑principles signature specializations without minting new Kernel kinds, apply profiles to U.Signature:

• profile = FormalSubstrate — formal‑deductive specialization Vocabulary: TermRegister (ref-only), InferenceKinds (ref-only), EffectDiscipline (operation and effect signatures). Laws: equational and structural axioms of the calculus; no handler semantics. Applicability: binds a U.BoundedContext for conceptual declaration use; no units, ReferencePlane, or Transport on faces. MVPK pins: No‑Realization pin (mandatory) on PlainView and TechCard asserting that handler semantics live only in A.6.1 U.Mechanism::U.EffectRealization. Faces: On MVPK faces, InferenceKindsAllowed MAY present a ref‑only subset of the enumerated InferenceKinds; Signatures do not add handler semantics.

• profile = PrincipleFrame — postulates + measurability intent (CHR‑binding) Vocabulary: PostulateSet (in the calculus imported), CHR-Binding presence (ref-only to characteristic or observation profiles), Ontology references (ref-only to ontology types or morphisms used to name subject-matter entities). Laws: timeless and order-free invariants; no operational admissions. Applicability: binds a U.BoundedContext; Signatures SHALL NOT publish units, ReferencePlane, ComparatorSet, or Transport (first mention is in UNM). MVPK pins: NoReferencePlaneOnSignature and UNM-priority (units, planes, comparators, and Transport are declared only by U.ContextNormalization and cited by edition or ref-id where needed). Do not mint profile-local pin synonyms.

Profile morphism discipline. See §4.6 for the structure‑preserving morphism requirements for profile application.

#Effect-discipline and handler-semantics split (normative)

If a Signature’s Vocabulary includes an EffectDiscipline (operation and effect signatures), the Signature SHALL NOT declare handler semantics or any EffectRealization. Such realizations are declared only under A.6.1 U.Mechanism and cited by ref-id on faces where needed. This mirrors the modern algebraic-effects separation between operation signatures and handlers while keeping A.6.0 purely conceptual.

#Declaration Rules (strict-distinction-aware; lexically disciplined)

• EntityOfConcern, Description, and specification-use separation. A signature states the subject kind and laws; Realizations (if any) carry specification-use constraints. Do not mix tutorial text or operational recipes into the Block. Do not include AdmissibilityConditions or run‑time admissions here.

• Context discipline. Bind Applicability to a U.BoundedContext. If cross‑context use is intended, name the crossing and reference the Bridge (Part F and B.3); A.6.0 does not prescribe compatibility and loss tables (CL, including CL^plane) or penalty formulas.

• Stratification. Use LEX‑BUNDLE registers and strata; do not redefine Kernel names in lower strata (no cross‑bleed).

• Signature manifest. If the signature is intended to be imported or reused, publish a SignatureManifest immediately above the Block with explicit id, imports, and provides lists (§4.4.1). Keep the universal four‑row Block free of dependency and export metadata.

• Realization discipline (normative extension point). If a family publishes any Realization of a U.Signature, each Realization MUST (i) declare which SignatureId it implements, (ii) satisfy the Signature’s Laws (and imported laws) and MAY tighten them but MUST NOT relax them, and (iii) treat imported Signatures as opaque—it MUST NOT depend on their internal structure beyond what is exported via provides and cited via ClaimIds. Realization-specific build, tooling, and test metadata belongs to the Realization record or publication, not to the U.Signature Block.

#SignatureManifest (imports and provides; normative)

A U.Signature MAY be prefixed with a lightweight manifest that makes boundary dependencies explicit without introducing a separate “module system”.

SignatureManifest fields (conceptual; concrete syntax is editorial):

• id : SignatureId — stable identifier for cross-references.
• version : SemVer (optional; required when the signature is imported or reused).
• publicationState : {draft | candidate | stable | deprecated} (optional).
• imports : [SignatureId] — other signatures whose provides are referenced by this signature (directed edges; possibly empty).
• provides : [SymbolId] — the only new public symbols minted by this signature that downstream text may depend on (types, relations, operators, SlotKinds, RefKinds).

Norms (boundary hygiene):

• Acyclicity. The directed graph induced by imports MUST be acyclic.
• Stratum dependency. imports MUST respect E.5.3 (Unidirectional Dependency) and E.10 strata and token-class discipline; do not import from a lower stratum or across a forbidden dependency direction.
• No redeclare. provides(S) MUST NOT re‑declare any symbol already provided by any transitive import of S.
• No ghost dependencies (vocabulary symbols). Any non-Kernel SymbolId referenced in the SubjectBlock or Vocabulary rows (including BaseType, ResultKind?, operator names, SlotKinds, ValueKinds, RefKinds) that is not provided by this signature MUST be provided by some imported signature. ClaimIds, BridgeIds, policy-ids, and EditionIds are exempt because they identify claims, bridges, policies, or editions rather than vocabulary symbols exported by this Signature.
• Law reference. When downstream text depends on laws or constraints from an imported signature, it SHOULD cite the corresponding ClaimId (A.6.B), not paraphrase prose.

The A.6.0 four-row Block remains the canonical meaning locus for Vocabulary, Laws, and Applicability. The manifest only declares dependency edges and exported names.

• Token hygiene. Do not mint new U.* tokens inside a Signature without an accepted FPF naming and kind decision; prefer referencing existing Kernel or Extension U.Types.

MVPK publication discipline for Signatures (normative). When publishing a U.Signature via MVPK (E.17), faces SHALL be typed projections that add no new claims; any numeric or comparable statement MUST pin unit, scale, reference-plane, and EditionId to CG-Spec and MM-CHR where applicable. For profile=FormalSubstrate signatures, faces MUST carry a No-Realization pin (handlers and realizers absent). For Principle-level signatures, faces MUST NOT introduce units, ReferencePlane, or Transport (first mention occurs in UNM).

#Specialisation knobs (for downstream patterns)

A.6.0 exposes three conceptual knobs; downstream patterns (A.6.1, method or discipline specifications) may tighten them:

1. Builder policy. The Block MUST NOT export Γ-builders. If a family publishes a Γ-like builder or aggregator, it MUST be outside the Block (typically as an A.6.1 Mechanism-level operator), explicitly marked optional, and namespaced under the Signature id.

2. Transport clause. If cross-context or cross-plane use is part of the design, the signature may declare a conceptual Transport clause; A.6.1 gives a concrete schema (Bridge, CL, CL^k, and CL^plane; Bridges per F.9, penalties per B.3, CL^plane per C.2.1), but A.6.0 remains agnostic about penalty shapes.

3. Morphisms. Families may define SigMorph (refinement, conservative extension, equivalence, quotient, product) to relate signatures; A.6.1 instantiates this for mechanisms. Where such morphisms, or downstream substitution and retargeting laws (e.g., A.6.2–A.6.4), act on n‑ary relations or morphisms, they SHALL express their access, update, and retargeting discipline in terms of SlotSpecs (SlotKind, ValueKind, RefKind) rather than unnamed parameter indices, using A.6.5 U.RelationSlotDiscipline as the normative slot calculus.

#Profile‑specialisation as a structure‑preserving morphism (normative)

Profile application ι_profile : U.Signature → U.Signature(profile=…) SHALL be a structure‑preserving morphism: — SubjectBlock is preserved up to α‑renaming (SubjectKind and BaseType unchanged; ResultKind? only added when it exists in the universal intent). — Vocabulary is monotone (adds or refines names and sorts without contradicting existing ones). — Laws are monotone (add or strengthen axioms; never weaken). — Applicability is restrictive (binds or tightens U.BoundedContext; never widens implicitly). — No AdmissibilityConditions, operational guards, or handler semantics are introduced by the profile (those live under A.6.1). This makes profile=FormalSubstrate and profile=PrincipleFrame morphisms in the sense of kernel specialisation and enables SigMorph reasoning (refinement or conservative extension).

#Archetypal Grounding (Tell–Show–Show)

Why these two? E.8 requires pairs from U.System and U.Episteme to demonstrate trans‑disciplinary universality.

#Near-miss and anti-cases

Near-miss: handler hidden in a U.Signature(profile=FormalSubstrate) declaration. A U.Signature(profile=FormalSubstrate) declaration for an algebraic-effects calculus may list operation symbols, inference kinds, and equational laws. If the same block says how a database handler commits transactions, the text has crossed into A.6.1 U.Mechanism: keep the operation and effect signature in A.6.0, and publish the handler realization as a mechanism that cites this signature.

Near-miss: measurement comparison hidden in a principle frame. A PrincipleFrame may state that a physical model preserves a heat-flow invariant and that observability must be recoverable through CHR. It must not declare units, reference planes, comparator legality, or transport loss as if they were signature laws. Those belong to CHR, UNM, bridge, comparator, and measurement patterns that cite the principle frame.

Anti-case: implementation manual called a signature. A document that names build steps, CI checks, tool vendors, or work authorization before it states SubjectBlock, Vocabulary, Laws, and Applicability is not a conformant U.Signature. Rewrite the declaration first; then place realization, work, evidence, or tooling claims in their governing patterns.

#Bias-Annotation (lenses and defaults)

• Local‑first meaning. Laws are local to the named Context; cross‑context use must be explicit (Bridge), never implicit.

• No illicit scalarisation. If numbers appear, legal comparability follows CG-Spec and MM-CHR; no ordinal means, partial orders return sets; unit and scale alignment is explicit.

• Register hygiene. Keep Tech vs Plain register pairs; avoid tooling or vendor talk in Kernel prose (E.10).

#Conformance Checklist (normative)

#Consequences

• Uniform kernel shape. Practitioners can define theory, mechanism, method, discipline, or other family signatures without inventing new templates.

• Hard decoupling. Boundary interfaces stay stable: the A.6.0 Block defines the signature and laws, while mechanisms and realizations can evolve behind it (with monotone strengthening and explicit guard boundaries).

Didactic cohesion. Readers see the same four conceptual rows across the spec, satisfying E.8’s comparability goal.

#Rationale

Why “SubjectBlock”? A.6.1 showed that making the ranged-over type explicit (here: BaseType) avoids category mistakes when moving between domains (e.g., set‑algebra on context slices vs equivalence‑classes of normalisations). A.6.0 lifts this to the kernel so every signature can declare what it is about before saying what it provides. Why one universal Block? Experience with extension and mechanism signatures shows the value of a single canonical shape for Vocabulary, Laws, Applicability, and Alignment; A.6.0 factors that universal core so other families can add headers and views without fragmenting the Kernel.

Informative echoes (post‑2015 SoTA). — Algebraic effects and handlers (OCaml 5, Koka, Effekt, Links): operation signatures and handler laws mirror Vocabulary and Laws while keeping implementations separate. — Session and behavioural types (2016–2024): protocol and admissibility laws parallel the Laws row (at mechanism level). — Graded and row-polymorphic effects (Granule, row-effects): inform the EffectDiscipline vocabulary and equational laws.

Profiles rationale (informative). — profile=FormalSubstrate signature profile. Captures mathematical language, inference kinds, and effect signatures in the conceptual declaration context, ensuring the calculus stays independent from handler and realization choices; consuming mechanisms (A.6.1) provide EffectRealization only by reference. — PrincipleFrame. Captures postulates and invariants plus measurability intent (CHR binding) without committing to units, planes, or Transport, which are declared centrally in UNM so that comparisons remain lawful and edition‑pinned.

#Relations

• Specialises and is specialised by: A.6.1 (adds OperationAlgebra, LawSet, AdmissibilityConditions, and Transport for mechanisms) and any domain‑profiled signature publications that preserve the four‑row Block.

• Constrained by: E.10 LEX-BUNDLE (registers, strata); D.CTX for Context binding; Part F (Bridges and cross-context transport; naming).

• Consumed by (profiles): U.Signature(profile=FormalSubstrate) and U.Signature(profile=PrincipleFrame) specializations in the first-principles use case; UNM (Context Normalization) remains the canonical edition source for CG‑Spec, ComparatorSet, and Transport editions that Signature consumers pin on faces.

• Enables: uniform declaration and comparison of signatures across Part C families, methods, and discipline glossaries (Part F).

#P2W U.Signature(profile=FormalSubstrate) Use Relation

When E.18.1 uses a first-principles or mathematical cue to select, declare, or cite a U.Signature(profile=FormalSubstrate) declaration, this pattern governs only that declaration: SubjectBlock, Vocabulary, Laws, Applicability, effect discipline, inference kinds, imported-symbol dependencies, and the no-realization pin. E.18.1 may carry the cue and select the next admissible relation. C.29 governs whether a mathematical-lens use is admissible for the stated use.

#profile=FormalSubstrate signature, mathematical object, and lens-use slot discipline

Do not decide whether source wording names a U.Signature(profile=FormalSubstrate) declaration, a general U.Signature declaration, or a mathematical-lens use by lexical replacement. Decide which relation position is live. The same mathematical object, formalism, or family may fill more than one relation position, but the position changes the admissible claim.

Old or source-local wording such as SubstrateFormalization recovers as a move to author, select, or cite a U.Signature(profile=FormalSubstrate) unless the claim being made is actually a C.29 mathematical-lens use, an A.6.1 mechanism relation, or another neighboring relation. In slot terms, the mathematical object can fill a CandidateMathObject position in C.29, a vocabulary or law position in a U.Signature(profile=FormalSubstrate) declaration, or an imported-signature position in a mechanism. Those are relation positions, not separate object kinds and not U.Roles.

The Rodin-style lesson used here is constructive rather than slogan-like: formal languages, axioms, rules, and mathematical objects help model a world-facing or episteme-facing EntityOfConcern only when their representational and operational limits are declared. A.6.0 therefore stores the formal-deductive declaration. C.29 stores the declared use of a mathematical lens. A.6.1, bridge, measurement, evidence, work, gate, and decision patterns store the later relations that apply, test, authorize, or use that declaration.

#P2W PrincipleFrame Input Order

When E.18.1 carries ontology, UTS, kind-relation, identity, context, boundary, characteristic, measurement, scale, comparator, or result-measurement wording toward a PrincipleFrame, write the input order explicitly. PrincipleFrame publishes postulates plus CHR observability in a bounded context; ontology editions, UTS rows, CHR editions, UNM, comparator, transport, normalization, bridge, and measurement relations stay with their own governing patterns.

#PrincipleFrame And CHR Observability Relation

For P2W use, PrincipleFrame may cite CHR observability only after the relevant characteristic, observation, measurement, scale, comparator, normalization, or bridge relation is recoverable. Numeric comparability, characterization admission, parity, selected-set relation, and refresh continue under the current characterization, normalization, comparator, selected-set, parity, or refresh pattern.

#PrincipleFrame Name And Profile Boundary For P2W

For P2W use, the durable object name is PrincipleFrame. Plain wording about principle framing may describe writing, selecting, or citing that object, but it does not create U.PrincipleFraming or a second profile.

#P2W Boundary Summary For U.Signature(profile=FormalSubstrate) And PrincipleFrame

For P2W references to U.Signature(profile=FormalSubstrate) and PrincipleFrame, first apply the slot discipline in A.6.0:10a.1. The signature profile carries only its declaration relation. If a source phrase also claims empirical realization, handler semantics, mechanism operation, work authorization, gate passage, evidence, assurance, result certification, units, reference planes, transport comparison, or downstream work use, recover that additional relation through its governing pattern before relying on the signature reference.

A CHR edition change, ontology edition change, or UNM change does not republish the PrincipleFrame by default. Republish, refresh, or changed downstream use requires a relation named by value that states whether the change affects postulates, observability binding, normalization, comparator, transport, measurement, bridge, work, gate, evidence, assurance, or result use.

#Lowering, repair, and refresh conditions

A U.Signature remains usable while the four-row Block is stable and all downstream use can recover the same SubjectBlock, Vocabulary, Laws, Applicability, and imported-symbol dependencies.

Repair the signature, or mint a new signature when monotone repair is impossible, if any of these conditions holds:

• a realization, handler, work authorization, evidence proof, bridge policy, or measurement comparison has been written into the Signature Block;
• a downstream use depends on a symbol, law, policy, or edition not exported by this signature or by an imported signature;
• a profile application weakens a law, widens Applicability, or adds operational admission;
• a current SoTA change in algebraic effects, session types, typed effect systems, profile=FormalSubstrate signatures, or context normalization changes the declared operation vocabulary, inference kinds, law shape, or no-realization boundary;
• a renamed SubjectKind, BaseType, SlotKind, RefKind, or exported SymbolId no longer recovers the same FPF kind under E.10 and F.18.

Do not repair the signature merely because a later realization, work plan, measurement run, bridge, or evidence record changed. Repair the object governed by that later relation unless the change alters the signature declaration itself or the exact dependency relation by which the later object cites the signature.

#A.6.0:End

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