#U.Signature — Universal, law‑governed declaration

Pattern A.6.0 · Stable Part A - Kernel Architecture Cluster

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 & scopes), E.8 (authoring 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 & cross-context transport; naming). Conformance keywords: RFC 2119.

FPF already uses “signatures” to stabilise public promises of reusable extension vocabularies and, via A.6.1, of mechanisms. But authors 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;
• readers cannot tell what is declared (intension & laws) versus what is implemented (specification);
• cross‑context reuse lacks a canonical place to state applicability and lawful vocabularies.

#Keywords

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

#Relations

#Content

#Problem frame

FPF already uses “signatures” to stabilise public promises of reusable extension vocabularies and, via A.6.1, of mechanisms. But authors 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;
• readers cannot tell what is declared (intension & laws) versus what is implemented (specification);
• cross‑context reuse lacks a canonical place to state applicability and lawful vocabularies.

E.8 demands a single authoring 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 surface 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, authors 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/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). Author 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/type constraints intensionally (e.g., restricting an operator’s domain) but SHALL NOT encode operational admissions.

Guidance for deductive substrates. Signatures that declare a formal deductive substrate (e.g., FormalSubstrate) MAY include, as vocabulary elements, an EffectDiscipline (algebraic/row/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/aliases within the same Signature.

A U.Signature is conceptual: it contains no implementation, no packaging/CI metadata, and no Γ-builders. If a family wants to expose a Γ‑like builder/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 / Applicability”) give a repeatable, holon‑stable pattern across mathematics → physics → engineering:

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

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

1. SubjectBlock — ⟨SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?⟩.
   SubjectKind names the intensional subject (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 intensional kind of outputs.
   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 roles of the SubjectBlock kinds (informative)

   • SubjectKind (intent). The intensional “describedEntity” of the signature (C.3.1), ordered by ⊑. It carries no Scope.
   • BaseType (carrier). The U.Type over which values/objects 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 intensional kind of the outputs of the operations declared in Vocabulary (use when outputs differ in kind from the SubjectKind).

2. Vocabulary — names and sorts of the public types / relations / 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 / …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/Invariants) — equations and order/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 & 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/laws; it MUST NOT be used to encode claim‑level applicability, which remains a Scope on claims (USM / 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/MM‑CHR (normalize‑then‑compare; lawful scales/units).

Mapping to existing families (normative aliases).
— A.6.1 (Mechanism). SubjectBlock ↔ SubjectKind/BaseType/…; Vocabulary ↔ OperationAlgebra; Laws ↔ LawSet; Applicability remains contextual; AdmissibilityConditions — separate field of mechanism (not in the U.Signature).
— Task/Problem/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 / 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/provides, or an Assurance View listing audit/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/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 occupants 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/identifiers.

Full discipline and lexical rules for SlotKind/ValueKind/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:

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

An authorial SlotSpec table then reads:

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

#Profile specialisations (normative; structure‑preserving)

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

• profile = FormalSubstrate — formal‑deductive layer
  Vocabulary: TermRegister (ref‑only), InferenceKinds (ref‑only), EffectDiscipline (operation/effect signatures).
  Laws: equational/structural axioms of the calculus; no handler semantics.
  Applicability: binds a U.BoundedContext at the concept‑plane; no units/ReferencePlane/Transport on faces.
  MVPK pins: No‑Realization pin (mandatory) on PlainView/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 characteristics/observation profiles), Ontology anchors (ref‑only to substrate types/morphisms used to name subject‑matter entities).
  Laws: timeless/order‑free invariants; no operational admissions.
  Applicability: binds a U.BoundedContext; Signatures SHALL NOT publish units/ReferencePlane/ComparatorSet/Transport (first mention is in UNM). MVPK pins: NoReferencePlaneOnSignature (alias: NoReferencePlaneOnPF) and UNM‑priority (units/planes/comparators/Transport are declared only by U.ContextNormalization and cited by edition/ref‑id where needed).

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

#Effect‑discipline vs handler semantics (normative split)

If a Signature’s Vocabulary includes an EffectDiscipline (operation/effect signatures), the Signature SHALL NOT declare handler semantics or any EffectRealization. Such realizations are authored 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.

#Authoring rules (I/D/S‑aware; lexically disciplined)

• I/D/S separation. A signature states intension and laws; Realizations (if any) carry specifications. 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/B); A.6.0 does not prescribe compatibility/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/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/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/test metadata belongs to the Realization artifact, not to the U.Signature Block.

#SignatureManifest (imports/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/reused).
• status : {draft | review | 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.
• Layering. imports MUST respect E.5.3 (Unidirectional Dependency) and E.10 strata/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. References that are not vocabulary symbols—e.g., ClaimIds, BridgeIds, policy‑ids, or EditionIds—are exempt.
• Law anchoring. When downstream text depends on laws/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 source of truth for meaning (Vocabulary/Laws/Applicability). The manifest only declares dependency edges and exported names.

• Token hygiene. Do not mint new U.* tokens inside a Signature without a DRR; prefer referencing existing Kernel/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/comparable statement MUST pin unit/scale/reference‑plane/EditionId to CG‑Spec/MM‑CHR where applicable. For deductive substrates, faces MUST carry a No‑Realization pin (handlers/realizers absent). For Principle‑level signatures, faces MUST NOT introduce units/ReferencePlane/Transport (first mention occurs in UNM).

#Specialisation knobs (for downstream patterns)

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

1. Builder policy. The Block MUST NOT export Γ‑builders. If a family publishes a Γ‑like builder/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/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/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 / retargeting laws (e.g., A.6.2–A.6.4), act on n‑ary relations or morphisms, they SHALL express their read/write/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/BaseType unchanged; ResultKind? only added when it exists in the universal intent).
— Vocabulary is monotone (adds or refines names/sorts without contradicting existing ones).
— Laws are monotone (add/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 supports SigMorph reasoning (refinement/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.

#Bias‑Annotation (lenses & 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/MM‑CHR; no ordinal means, partial orders return sets; unit/scale alignment is explicit.

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

#Conformance Checklist (normative)

#Consequences

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

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

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 carrier explicit (here: BaseType — the carrier type) 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/mechanism signatures shows the value of a single canonical “shape” for Vocabulary/Laws/Applicability/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 & handlers (OCaml 5, Koka, Effekt, Links): operation signatures + handler laws mirror Vocabulary + Laws while keeping implementations separate.
— Session/behavioural types (2016–2024): protocol/admissibility laws parallel the Laws row (at mechanism level).
— Graded/row‑polymorphic effects (Granule, row‑effects): inform the EffectDiscipline vocabulary and equational laws.

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

#Relations

• Specialises / is specialised by: A.6.1 (adds OperationAlgebra / LawSet / AdmissibilityConditions / 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 & cross‑context transport; naming).

• Consumed by (profiles): U.FormalSubstrate and U.PrincipleFrame specialisations of U.Signature on the principled path; UNM (Context Normalization) remains the single source of truth for CG‑Spec/ComparatorSet/Transport editions that Signature consumers pin on faces.

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

#A.6.0:End