#Cluster A.IV.A - Signature Stack & Boundary Discipline (A.6.)*

Preface node heading:cluster-a-iv-a-signature-stack-boundary-discipline-a-6:6884

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#Signature Stack & Boundary Discipline

Type: Architectural (A) Status: Stable Normativity: Mixed (normative only where explicitly marked; claim-classification semantics live normatively in A.6.B) Placement: Part A → A.6.* (cluster overview; coordinates A.6.0 / A.6.1 / A.6.3 / A.6.B / A.6.5 / A.6.6 / A.6.7) Builds on: E.8 (authoring template), A.6.B (Boundary Norm Square — quadrant semantics & link discipline), A.6.0 (U.Signature), A.6.1 (U.Mechanism), A.6.3 (U.EpistemicViewing — views as episteme-lane projections under viewpoints), E.17.0 (U.MultiViewDescribing), E.17 (MVPK — fixed face kinds & “no new semantics” publication), A.7 (EntityOfConcern and Description-episteme boundary; specification use and publication-carrier distinction), F.18 (promise, utterance, and commitment), E.10.D2 (EntityOfConcern and Description-episteme boundary; specification use/refinement discipline), E.10 publication face, form, unit, and carrier discipline Purpose (one line): Keep boundary claims evolvable by classifying each statement under the right layer of the Signature Stack and the right quadrant of the Boundary Norm Square (A.6.B).

Mint/reuse (terminology): Mints “Signature Stack”, “Boundary Discipline Matrix”, and “Claim Register” as local authoring aids; reuses existing FPF meanings of U.View/U.Viewpoint (E.17.0/A.6.3) and uses publication face/form or interop publication form terms for publication lanes. The labels L/A/D/E used below are claim-classification labels for statements, not MVPK face kinds and not pattern IDs.

Canonical companion. The square itself (quadrant definitions, form constraints, and cross‑quadrant dependency discipline) is specified normatively in A.6.B — Boundary Norm Square. This overview only (i) maps quadrants onto the Signature Stack, and (ii) explains how MVPK faces project the canonical L/A/D/E-classified claim set. If anything in this overview conflicts with A.6.B, A.6.B is authoritative.

Start here when. The dominant question is an API, protocol, contract, compliance, SLO/SLA, connector, interface, or publication boundary package whose statements are mixing runtime behaviour, governance, and evidence into one undifferentiated boundary account.

First output. One Claim Register or equivalent L/A/D/E-classified atomic claim set with stable L-*, A-*, D-*, and E-* identifiers, stack placement, and face citations by ID rather than paraphrase.

Boundary-claim activation discipline. Use only as much claim-classification structure as the live work claim or reliance claim requires. Split a statement only where one sentence carries more than one claim kind, governingPatternRef or authoritySourceRef, or work or reliance consequence, or where evidence, gate, duty, assurance, work occurrence, P2W class, admissible work, or admissible reliance would otherwise remain ambiguous. For a local first-pass repair, an equivalent L/A/D/E-classified claim set may be a two-to-four-row scratch table. Use a persistent Claim Register when the claim set is reused, published, audited, release-bearing, cross-context, or relied on by A.15, A.10, B.3, A.21, A.20, A.2.8, A.2.9, or A.15.1. Do not atomize ordinary modifiers when one governingPatternRef or authoritySourceRef and one work or reliance consequence are already clear.

Typical neighboring governing patterns and authority-reference repairs. A.6.B for the quadrant semantics, A.6.C for contract unpacking, A.6.P, C.16.Q, or A.6.A for lexical repair, and E.17 faces for audience-specific publication of the same decomposed claim set.

Common neighboring-pattern mistakes. If the real object is still cue preservation or an early candidate-route cue, use A.16 or A.16.1; if a qualified relation, quality term, or action invitation is itself being repaired, apply A.6.P, C.16.Q, or A.6.A; if agent duties are being mixed into one contract sentence, split them through A.6.B rather than minting one more contract-soup paragraph.

Causal/deontic split. A mixed boundary sentence such as "deploy because it would reduce harm" is not settled by one hidden pattern. C.28 carries the causal-use question, CausalityLadderRung, estimand, support basis, support verdict, and supported causal use and unsupported causal use. A.6.B classifies deontic duties, boundary admissibility gates, and work-effects as atomic L/A/D/E claims. A.6.C unpacks contract, promise, commitment, utterance, and boundary-publication language when the sentence is agreement-like or release-facing. A causal support record does not by itself create a duty, commitment, promise, release gate, or boundary admissibility predicate.

Authority wording split (subordinate boundary-claim stress case). When a boundary, policy, API, schema, connector, or compliance statement uses "approved", "allowed", "authorized", "guaranteed", "certified", "recommended", or equivalent wording, do not decide by the word. The object under repair is still the L/A/D/E-classified boundary claim set: split the statement into A.6.B L-* definition or invariant claims, A-* admissibility or gate claims, D-* commitment claims, and E-* evidence or work-effect claims before treating it as action guidance. When "guaranteed", "promise", "contract", "SLA", "SLO", or certified-under-agreement wording is agreement-like, service-facing, promise-bearing, or release-facing, unpack promise content, utterance package, deontic commitment, and work or evidence substrate through A.6.C, A.2.3, A.2.8, and A.2.9 before using the L/A/D/E-classified claims. When "recommended" wording is cue preservation, advice, or action invitation, apply A.16, A.16.1, or A.6.A according to the kind under repair; when it is an admissibility criterion, use the A-* claim and any live A.21 gate decision; when it is evidence-supported advice, use the E-* claim plus A.10; only recommendation-as-duty uses a D-* claim and A.2.8. If the encountered item is a dashboard or status display rather than boundary prose, do not turn color, label, or visible status into an A-* admissibility claim; return through A.15, A.10, and, when a gate decision is live, A.21. If the split result will guide work, release, permission, role or status reliance, evidence reliance, or assurance, return through A.15 to the governing FPF pattern and project-side FPF kind and reference named by value that carry the claim being made or effect.

Positive repaired path. A repaired boundary statement is not merely "less vague"; it is an L/A/D/E-classified claim set that tells the user which statement is definitional, which is an admissibility predicate, which is a deontic commitment, which is an evidence or work-effect claim, and which FPF pattern or project-side FPF kind and reference named by value must be cited before the work claim or reliance claim is used.

Credential-currentness boundary. A displayed credential can support only issuer, holder, verifier, status, and currentness claims after an A.10 evidence path verifies it for the relying context. Boundary permission, admissibility, authorization, deontic commitment, role or status effect, or gate passage still needs the exact A.6.B, A.2.8, A.2.9, A.2.1, or A.21 source.

Register-backed status boundary. A pass, badge, dashboard cell, API response, certificate view, or other status-looking item may be only a publication of a governing register entry or status-source entry. If that register entry is the source that creates or changes permission, role or status, duty, or gate state in the bounded context, cite that register entry or status-source named by value entry and split the created claims through A.6.B, A.2.1, A.2.8, A.2.9, or A.21. If the item is only an extract, cache, screenshot, certificate view, or convenience display, keep it as source-finding or currentness support under A.10 until the exact source is recoverable.

Conflicting-source boundary. When routed boundary wording, a display, copied summary, current source, gate decision, credential status, register entry, status-source display, recency signal, or provenance label disagree, do not resolve by wording emphasis, visual salience, color, or apparent freshness. Name the source order, decision source, freshness policy, and supersession rule; until those are resolved, keep only cue use, source-finding, or bounded reversible probes available.

Adversarial wording guard. Do not let intentionally ambiguous "allowed", "approved", "authorized", "certified", "recommended", or "guaranteed" wording collapse L-*, A-*, D-*, and E-* claims. Split the boundary statement first, then cite the supporting source named by value for the live work use, reliance use, evidence use, gate use, commitment use, or assurance use.

Lint trigger. In boundary, API, schema, or policy text, approved, authorized, allowed, guaranteed, certified, or recommended should trigger the A.6 split: identify the L-*, A-*, D-*, and E-* claims, then cite the exact source before work use, reliance use, evidence use, gate use, commitment use, or assurance use.

Boundary and source repair assignment. If splitting boundary wording exposes a missing or broken L-*, A-*, D-*, or E-* source, assign repair to the accountable boundary-maintenance or source-maintenance role assignment: boundary author, policy or schema maintainer, gate source, commitment source, evidence-carrier source, or publication face maintainer. Keep only cue use, source-finding, or bounded reversible use available until that source is exposed or repaired.

Role prompts for boundary wording use:

Recurring boundary ambiguity repair. If the same boundary, API, schema, or interface wording repeatedly needs the same split or source recovery, repair the boundary package rather than making each user reinterpret it: replace misleading labels, expose L/A/D/E claim IDs, cite the gate source, commitment source, evidence source, or work-effect source, add currentness or supersession refs, or remove the phrase that invites unsupported work claims or reliance claims. Repetition is a signal that the boundary source or publication face needs repair, not a normal per-use task.

Display guidance for boundary wording: a publication face, API doc, schema page, connector card, or compliance statement that uses approval-, authorization-, permission-, recommendation-, certification-, or guarantee-like wording should expose the L-*, A-*, D-*, and E-* claim IDs, the source for each live work claim or reliance claim, freshness and supersession refs where currentness matters, and unsupported work claims, reliance claims, or effects. If it cannot expose those, keep the wording as source-finding or repair the boundary package.

Incident-learning fields for boundary wording overread: displayed phrase, intended next work move or reliance move, required source-backed claim or effect, missing or ambiguous L/A/D/E claim ID, exact L-*, A-*, D-*, or E-* source needed, plausible overread, safe disposition used now, and upstream repair item for labels, L/A/D/E claim IDs, source refs, currentness refs, supersession refs, or publication-face wording.

Conventions: The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and SHALL are to be interpreted as in RFC 2119/8174. Lower‑case “must/may/should” in explanatory prose is descriptive, not normative.

Statement identifiers (recommended): Adopt the quadrant‑prefixed ID scheme from A.6.B:0 for routable statements: L-* (law/definition), A-* (admissibility gate), D-* (deontic/commitment), E-* (effect/evidence). Other sections and faces SHOULD refer to these IDs instead of restating the same constraint in new words. IDs are intended to be “lintable” anchors (and are especially useful when D‑duties enforce A‑gates or E‑claims). Consider pairing IDs with a lightweight Claim Register (A.6.B:7) to reduce paraphrase drift across faces. Non-collision note (informative): The A-* prefix here is “Admissibility”, not Part‑A numbering and not MVPK’s AssuranceLane face kind. If this is a readability hazard in your program, prefer an explicit G-* (“Gate”) local convention while keeping the quadrant name “Admissibility”.

Admissibility-predicate distinction (informative): An A-* claim is a mechanism admissibility predicate or entry condition inside the L/A/D/E-classified boundary claim set. It is not an A.21 GateDecision, DecisionLogRef, or proof that a gate passed. An A-* claim may name a condition that a later A.21 gate evaluates; actual gate passage needs the A.21 source. An A.20 ConstraintValidity witness remains separate from both the predicate and the gate decision.

Claim Register (informative, recommended). Use the Claim Register mini‑record in A.6.B:7. In this cluster the register is additionally used to record stack placement (Signature/Mechanism/Norms/Evidence) and the MVPK faces that cite each claim (viewRef/viewpointRef), so “no paraphrase drift” can be audited mechanically.

#Problem frame

Boundaries are where architecture lives: at the edge of a theory, an API, a protocol, a hardware connector, an organisational interface, or a published model. FPF already has the core building blocks to describe such edges:

• U.Signature as a public, law‑governed declaration (with Vocabulary, Laws, Applicability).
• U.Mechanism as a specialization that introduces operational “entry gates” (AdmissibilityConditions) and additional operational blocks (Transport, Audit, etc.).
• Multi‑view publication discipline via U.MultiViewDescribing (views + viewpoints).
• Strict separation of EntityOfConcern vs Description episteme vs publication carrier so we do not accidentally attribute agency or work to an episteme, or treat a file as the entity, claim, work, evidence, or decision.

Yet boundary descriptions in practice fail in a predictable way: authors blend several fundamentally different kinds of claims into one “contract soup”. The result is brittle architecture: signatures become entangled with runtime gates, deontic language is mixed into mathematical invariants, and “effects” are asserted without any disciplined carrier/evidence story.

This cluster overview makes one disciplined move:

1. Treat a boundary as a stack of boundary layers (Signature → Mechanism → Work/Evidence carriers) plus publication views and faces, and
2. Provide a boundary discipline matrix (2×2) that routes statements to the correct layer, so evolution remains controlled and substitutions are possible.

Terminology note (informative): In this pattern:

• Layer names a stratum in the boundary stack (Signature → Mechanism → Work/Evidence carriers → Publication).
• View (U.View) is an episteme-lane projection, not a file/document.
• Viewpoint (U.Viewpoint) is an accountability specification that constrains views.
• Face (MVPK sense) is a named publication view kind (PlainView, TechCard, InteropCard, AssuranceLane) whose rendering lives on a publication face or publication form on a carrier. Do not coin “signature/mechanism ...Surface” terms; use publication face, form, unit, carrier, and rendering terms only when a publication lane is live.

#Problem

When boundaries are described without an L/A/D/E claim-classification discipline, four confusions dominate:

1. Laws vs admissibility. Authors encode runtime gate predicates as “laws”, or write invariants using RFC‑style deontic verbs, blurring “what is true/defined” with “what is allowed to be applied”. FPF explicitly separates these: operational guard predicates belong to mechanisms (A.6.1), not signatures (A.6.0). Common mistake #0 — Applicability ≠ Admissibility (informative): Signature Applicability scopes declared admissible use and bounded context; it is not a runtime entry gate. Runtime entry checks and permission predicates belong in U.Mechanism.AdmissibilityConditions as A-*. If an agent is obligated to satisfy/enforce such a gate, express that as a D-* duty that references the A-* claim ID (per A.6.B), not by rewriting the gate as “X MUST …”.

2. Admissibility vs deontics. “MUST/SHOULD/MAY” is used both for agent obligations and for world‑state admissibility predicates. E.8 already demands keeping deontics distinct from admissibility/definitions and recommends predicate‑style constraints for admissibility rather than RFC keywords.

3. Contract talk category errors. “The interface promises…” is a metaphor. A promise (and a contract) is an agent‑level phenomenon; an episteme is an utterance; a running service is the delivered work. FPF provides an ontological anchor for this via promise/utterance/commitment distinctions (F.18).

4. Effects without evidence or carriers. Effects happen only in work; therefore, “effect claims” must be anchored to observation and carriers. Without A.7’s EntityOfConcern and Description-episteme / publication-carrier discipline, writers conflate the published description with runtime traces or treat a file as the system itself.

These confusions destroy evolvability: you cannot swap implementations behind a stable signature if the signature already smuggles mechanism‑gates, audit logistics, or agent commitments into “laws”.

#Forces

#Solution — A stack + a routing matrix

#Why “stack”: what is stacked, and what “higher/lower” means

This pattern uses stack in the same pragmatic sense as other FPF stacks (e.g., the holonic import stack and other layered disciplines): an ordered set of layers where higher layers are more stable commitments, and lower layers are more volatile realizations/evidence. “Higher” and “lower” are not metaphysical claims; they are engineering guidance for evolvability:

• Higher in the stack = closer to public, reusable boundary intent.
• Lower in the stack = closer to execution, implementation, and evidence (what is actually done and observed).

This is consistent with existing “stack discipline” uses in FPF (e.g., import layering over holonic strata).

The Signature Stack (as used in this cluster) is the ordered family of canonical claim layers for a boundary package. Each layer is a stable “landing zone” for one quadrant of statements (L/A/D/E), with a canonical boundary publication form or section that carries those statements:

1. Signature layer (L: laws/definitions). U.Signature provides the stable declarative boundary: Vocabulary + Laws + Applicability, without runtime gate predicates.

2. Mechanism layer (A: admissibility/gates). U.Mechanism specializes the signature and adds AdmissibilityConditions (the entry gate) plus operational blocks (e.g., Transport, Audit/Observability). These blocks specify runtime gates and observability interfaces; they are still descriptions. The evidence itself exists only as carriers produced in work.

   Audit vs AssuranceLane (avoid duplication): the Mechanism’s Audit/Observability block defines the required semantics of an observability/evidence interface (carrier classes and required fields, correlation keys, exposure interface). Retention/access/enforcement are D‑claims (agent duties) that reference the same carrier classes by ID. An MVPK AssuranceLane is a projection for auditors that explains how to read/check the evidence interface. This is a special case of CC‑A.6.6: the lane references the Mechanism section and the relevant claim IDs rather than restating semantics.

3. Norms & commitments layer (D: duties/commitments). Deontic statements are anchored to accountable agents/roles (authors, implementers, operators, providers, reviewers). Canonical placement is a Norms/Commitments section in the boundary package (typically rendered inside TechCard), and those statements reference L-*/A-*/E-* by ID rather than duplicating predicates.

4. Evidence bindings layer (E: effects/evidence). E-* claims bind observed behaviour to carrier classes and measurement conditions. Canonical placement is an Evidence/Carriers section in the boundary package (typically rendered in AssuranceLane), and adjudication happens against carriers produced in work.

5. Work & realizations (outside the description stack). Realizations (substitutable implementations) are exercised by doing work; actual executions produce state changes, traces, and measurements. Effects exist only in work. A.6.0 already frames realizations as substitutable behind signatures and warns against smuggling bridge mechanics into the signature layer.

6. Publication faces (MVPK views rendered on publication face/forms). MVPK yields audience‑specific U.View instances (faces) that are typed projections over the canonical claim layers above and carry viewpoint accountability (viewRef + viewpointRef). Physical documents/files live on carriers (publication face/form), not in the U.View itself.

Observability compatibility note (informative): When specifying evidence carriers and correlation rules, it is often convenient to describe evidence-carrier classes in terms familiar from contemporary observability practice (post‑2015): traces/spans, logs/log records, and metrics time‑series, with explicit correlation identifiers. Treat these as example carrier schemas and join keys, not as mandatory technology choices. (Concrete schema/exchange mapping remains outside Part E; keep Part E conceptual.)

#AssuranceLane skeleton (informative)

An MVPK AssuranceLane is a view that teaches a specific audience how to adjudicate E-* claims against carriers produced in work. It references (not restate) the Mechanism’s Audit/Observability semantics.

Minimal content (suggested):

• Scope: boundaryRef, version, viewRef, viewpointRef.
• Carrier inventory: carrier class/schema refs (A.7 Carrier) + where to obtain them.
• E‑claim map: a table keyed by E-* ID with: measurement conditions, carrierRef(s), join/correlation keys, and a reference to the canonical E-* text that defines pass/fail criteria.
• Operational policies: references to relevant D-* duties (retention, access control, exposure), without redefining them.
• Limitations: sampling, redaction, missing signals, expected false negatives/positives.

No new semantics reminder. The lane may include procedural adjudication guidance (queries, joins, dashboards) as informative text. Any normative thresholds/criteria that would change the boundary’s commitments MUST be authored as E-* claims in the canonical Evidence/Carriers section and cited by ID, rather than being introduced only inside the lane text.

Example (conceptual, no tools):

AssuranceLane:
  viewRef: <ViewId>
  viewpointRef: <ViewpointId>
  boundaryRef: <BoundaryId>
  version: <SemVer or revision>
  evidence:
    - E: E-OBS-1
      carrierRefs: [Carrier.AuthorizationRecord, Carrier.AuditLogEntry]
      measurement:
        conditions: "on every rejection due to A-AC-1"
        vantage: "Operator/Auditor pipeline"
        correlation: ["traceId", "requestId"]
      adjudication:
        check: "query audit stream for code=NotAdmissible and join to traceId"
        criteriaRef: "E-OBS-1 (pass/fail lives canonically in the E-claim)"
      references: [A-AC-1, D-RET-1, Mechanism.AuditObservability]

Default landing zones (quadrant → stack layer / section):

• L → Signature.Laws (and, where appropriate, mechanism‑local semantic laws; never runtime gates)
• A → Mechanism.AdmissibilityConditions
• D → Norms/Commitments (U.Agent or U.Role duties; publication/accountability duties)
• E → Evidence/Carriers (claims adjudicated against work via carriers; the publication face for these is typically AssuranceLane)

Integration stitches (informative; this cluster is a routing hub, not a standalone philosophy):

• A.6.1 ↔ A‑quadrant: U.Mechanism.AdmissibilityConditions is the canonical claim layer for A-* gate/admissibility claims.
• A.10 / B.3 ↔ E‑quadrant: E-* claims should be anchored to evidence carriers + provenance (A.10); without an explicit evidence anchor they are treated as AssuranceLevel:L0 (Unsubstantiated) in the Trust & Assurance calculus (B.3).
• A.2.3 / F.12 ↔ D/E separation: a U.PromiseContent promise is not evidence; promise acceptance is linked to work evidence via F.12, and role obligations to maintain admissibility are expressed as D-* duties referencing A-* and/or E-* by ID.

A stack is useful because the intended direction of change is clear:

• Lower layers (realizations, audit formats, transport mechanisms) are expected to change more frequently and can often evolve without forcing higher‑layer changes, provided higher‑layer commitments remain satisfied.
• Changes to higher layers are boundary-claim evolution and typically require explicit compatibility reasoning (and therefore explicit versioning and communication).

#Boundary Discipline Matrix: route by A.6.B (the Boundary Norm Square)

Normative source. The canonical 2×2 square (the two A.6.B distinctions, quadrant semantics, form constraints, and cross‑quadrant reference rules) is defined in A.6.B. This section provides a short operational summary and worked rewrites only.

A “four‑part list” is insufficient, because real sentences reuse the same visible words (“must”, “guarantees”, “valid”) across different logical roles. A 2×2 matrix is better fit because it arises from crossing two independent distinctions:

• Modality family: truth‑conditional vs governance (permissions/obligations/commitments).
• Adjudication substrate: in‑description vs in‑work (whether satisfaction is decided from the description alone or requires observing executed work/carriers).

Operational summary (quadrant → canonical claim layer in the stack):

• L (Laws & Definitions) → Signature.Laws (truth‑conditional semantics, in‑description)
• A (Admissibility & Gates) → Mechanism.AdmissibilityConditions (runtime entry predicates / permission checks)
• D (Deontics & Commitments) → Norms/Commitments (U.Agent or U.Role duties and commitments; may be audited via E-*)
• E (Work‑Effects & Evidence) → Evidence/Carriers (work‑adjudicated effects tied to carriers and measurement conditions)

Atomicity rule:

If a sentence mixes roles (e.g., “MUST” + a gate predicate + an effect claim), it is not routable as a single statement. Per A.6.B, split it into atomic claims so each one has exactly one quadrant (and, ideally, an identifier you can reference).

Micro‑template: Atomize → Route → Place → Anchor (A.7) → Register

1. Split the sentence into atomic claims (one logical role each).
2. Assign each claim to exactly one quadrant (L/A/D/E) using the matrix.
3. Place each claim into its correct section or publication form (stack layer + section).
4. Anchor A.7: for each claim, name the primary A.7 side it is about (EntityOfConcern, Description episteme, or publication carrier) and ensure the grammatical subject matches (agents/roles for D-*, carriers for E-*).
5. Register: add the atomic claim to the Claim Register (if used) and ensure every downstream face references the claim by ID rather than paraphrasing.

Action outputs after classification:

• implement or repair an admissibility predicate when the claim being made is A-*;
• assign, remove, or clarify an accountable role/commitment when the claim being made is D-*;
• add, repair, or expose evidence-carrier instrumentation when the claim being made is E-*;
• publish or update an MVPK face that cites L/A/D/E claim IDs rather than paraphrasing them;
• reopen an A.21 gate decision, A.20 constraint-validity witness, A.2.9 speech act, A.2.8 commitment, A.10 evidence path, or B.3 assurance claim when the L/A/D/E-classified statement is being used beyond boundary wording;
• downgrade the visible wording to cue use or source-finding only when the exact source is missing;
• keep the work claim or reliance claim local, reversible, or blocked only for the unsupported work claim or reliance claim while the source is repaired.

Informative example. Example rewrite (mixed → atomic):

Before (mixed, not classifiable yet): “Clients MUST include header X; otherwise the request is invalid and the system logs NotAdmissible.”

After (classifiable + lintable):

• A-AC-1 (Quadrant A, Mechanism.AdmissibilityConditions): admissible(req) iff hasHeader(req, "X").
• D-CL-1 (Quadrant D, Norms/Commitments): “Client implementers MUST satisfy A-AC-1.”
• E-OBS-1 (Quadrant E, Evidence/Carriers): “When a request is rejected due to A-AC-1, an AuditLogEntry{code="NotAdmissible"} carrier is produced and can be observed in the audit stream.”

Informative example. Example rewrite (guarantee + SLA + measurement + enforcement):

Before (mixed, contract soup): “The service guarantees 99.9% availability per calendar month and MUST keep p95 latency under 200ms; breaches are penalized; operators SHALL alert on violations.”

After (classifiable + adjudicable):

• D-SLA-1 (Quadrant D, Commitments/SLA): “Provider SHALL meet E-SLA-AVAIL-1 and E-SLA-LAT-1 under the stated exclusions.”
• E-SLA-AVAIL-1 (Quadrant E, Evidence/Carriers): “availability ≥ 0.999 over calendar month T, measured by carrier UptimeProbeSeries from viewpoint VP.ExternalMonitor.”
• E-SLA-LAT-1 (Quadrant E, Evidence/Carriers): “latency_p95 ≤ 200ms under workload W, measured by carrier LatencyMetricSeries from viewpoint VP.Client.”
• D-OPS-ALERT-1 (Quadrant D, Ops duty): “Operators MUST page on breach of E-SLA-AVAIL-1 or E-SLA-LAT-1 within 5 minutes (policy).”
• E-ALERT-1 (Quadrant E, Evidence/Carriers): “Pages are evidenced by carrier AlertEvent{ruleId,firedAt,target} and can be joined via incidentId.”

See A.6.B:4–A.6.B:6 for the normative square, quadrant form constraints, and explicit cross‑quadrant link patterns (notably: D→A, E→A, D→E, and A/E→L).

#Authority-wording split examples

These examples are informative. They show how to keep mixed authority prose from becoming evidence, assurance, commitment, gate passage, or work by wording alone.

Before (mixed): "This API is approved for production use and guarantees safe rollback."

After (classifiable + source-ready):

• L-API-1 (Quadrant L): the API operation and rollback terms are defined in the signature vocabulary.
• A-API-1 (Quadrant A): a request is admissible only under the named subject, action, object, context, and policy-version predicate.
• D-API-1 (Quadrant D): the accountable provider or operator commits to maintain or enforce A-API-1 under the named window and exclusions.
• E-API-1 (Quadrant E): rollback success is evidenced only by the named work traces, audit records, or metrics; a gate decision carrier can support gate passage, but not rollback execution by itself.

Then:

• if a user is deciding whether the wording may guide action, enter A.15;
• if evidence, currentness, or provenance is live, attach the A.10 path;
• if trust, readiness, compliance, or release confidence is being raised, build the B.3 assurance tuple;
• if an actual gate decision or gate passage is asserted, cite A.21 OperationalGate(profile), GateDecision, and DecisionLogRef;
• if a flow witness or constraint witness is asserted, cite A.20 ConstraintValidity status or witness;
• if release, deployment, rollback, or execution work is asserted, cite A.15.1 dated U.Work occurrence plus its A.10 evidence carrier path;
• if the phrase is only an action invitation or cue, keep it in A.6.A, A.16, or A.16.1 according to the kind under repair.

Policy-as-code, dynamic authorization, credential, register-backed status, provenance, attestation, and assurance practices support complementary parts of this split: policy engines support bounded authorization decisions; credentials support issuer, holder, verifier, and status claims; governing registers or status-source entries may carry role effects, status effects, permission, duty, or gate-state effects only when the bounded context gives that source such force; provenance and attestation support bounded origin or process claims; assurance practice supports claim-argument-evidence confidence claims. None of them lets wording, a displayed credential, a register excerpt, a provenance label, or a schema cue stand in for the subject named by value, requested policy operation or work class, affected resource or work target, context, policy or gate version, evidence refs, validity or revocation window, gate decision, or work occurrence needed for work use or reliance use.

#Viewpoint is not optional: projections live under accountable viewpoints

“Projection” language is useful (a view is a projection), but FPF does not drop viewpoint. U.MultiViewDescribing makes viewpoints explicit and treats views as epistemes; MVPK specialises this for publication and fixes a closed set of face kinds (PlainView, TechCard, InteropCard, AssuranceLane) under publication face, form, unit, and carrier discipline.

A disciplined stack therefore requires:

• Every published face is a Description (A.7) that is about an Object and is carried by some Carrier; do not conflate these layers.
• Each face must declare the viewpoint that justifies its projection (ISO/42010 discipline operationalised by MVPK).
• Per E.17 (“no new semantics”), a face MUST NOT introduce new semantic commitments beyond the boundary’s canonical L/A/D/E-classified claim set (the authoritative L-*, A-*, D-*, and E-* statements at their canonical locations). A face MAY add informative explanation, examples, and cross‑references, provided they are clearly marked as informative. Any normative sentence on a face MUST cite the L/A/D/E claim ID(s) it depends on (or be moved into the canonical claim set); paraphrase is allowed only as explicitly informative text.
• Per E.17 and publication-face/form discipline (face‑kind closure), a publication package that claims MVPK alignment MUST NOT mint additional MVPK face kinds (e.g., “EvidenceCard”, “NormsCard”) as if they were first‑class kinds; if you need local headings, keep them as sections within the canonical face kinds.

#“Contract” unpacking: avoid assigning agency to epistemes

When practitioners say “the API contract”, they usually compress multiple distinct things into one word. The core naming split is the F.18:16.1 triad; boundary engineering adds the missing adjudication substrate (see also A.6.C):

• Promise content (promise content; U.PromiseContent, A.2.3): what is promised to be made available to eligible consumers — a promise, not execution (U.Work).
• Utterance package (published descriptions + instituting act): what is said/published and versioned (signature/mechanism + MVPK faces), plus the U.SpeechAct <: U.Work that published/approved it when provenance matters (A.2.9).
• Commitment (deontic binding; U.Commitment, A.2.8): what an accountable U.Role or U.Agent is obligated, permitted, or prohibited to do (often: to satisfy a promise content).
• Work + Evidence (adjudication substrate; U.Work + carriers): what actually happens and what carriers/traces can adjudicate whether commitments and operational guarantees were met.

In A.6 terms:

• The signature is the utterance substrate for the boundary; it is not itself a promiser or obligor (A.7).
• Deontics belong to accountable role assignments or agents and should be expressed as D-* commitments (U.Commitment) that reference L-*, A-*, or E-* by ID (A.6.B, A.2.8).
• Operational “guarantees” are empty rhetoric unless they are routed as either L (truth‑conditional law), D (agent commitment), or E (measured property with evidence).

This paragraph is a compact reminder; the reusable expansion (including “Service ≠ Work” discipline, claim‑ID link hygiene, and MVPK face projection rules) is A.6.C — Contract Unpacking for Boundaries.

#Where statements go (routing examples)

Informative. Routing examples for learning the discipline; they do not add requirements beyond A.6:7.

The table below intentionally uses near‑everyday spec phrases. The same visible words appear in different quadrants depending on what they do.

Notes:

• The routing is not just about modal verbs. “Shall” can be D (a duty) or A (a gate behavior). “Guarantees” can be D (a commitment) or E (a measured property). The matrix forces disambiguation.
• If a sentence reads like “X MUST … if … then …”, it almost always bundles multiple quadrants. Split into (A) a gate predicate (A-*), (D) an enforcement duty on a U.Agent or U.Role (D-* referencing the gate ID), and (E) an evidence claim (E-*) if observability matters.
• When something needs to be enforceable but is mathematical, prefer predicate blocks rather than deontic language in the L/A blocks, per E.8’s deontics vs admissibility guidance.

#Routing sanity rules (informative, concept-level)

These are writing diagnostics, not tool requirements. They exist to keep the mental model crisp.

• RFC keyword inside Definition/Invariant/Admissibility predicate → classification error (rephrase as predicate; move obligation to D-*).
• E-* without (carrier + measurement conditions + viewpointRef) → incomplete evidence claim (cannot be adjudicated).
• D-* that re-states an A-*/L-* predicate instead of referencing its ID → drift risk (prefer “MUST satisfy A-…”).
• A face introduces new L/A/D/E content not present in underlying Signature/Mechanism → view-fork (make it informative only, or move the commitment to the underlying signature or mechanism publication).
• “The system/service SHALL …” where no accountable agent is named → likely misclassified deontic (rewrite as E-* behavior + D-* duty on implementers/operators).

#Archetypal Grounding (Tell–Show–Show; System / Episteme)

Informative. Worked examples for learning the L/A/D/E claim-classification discipline; they do not add requirements beyond A.6:7.

#Tell (universal rule)

A boundary description is evolvable iff its claims are separated across the signature stack and each statement is routed by the boundary discipline matrix to its proper layer (Laws, Admissibility, Deontics/Commitments, Effects/Evidence), while preserving EntityOfConcern and Description-episteme / publication-carrier separation.

#Show #1 (U.System): effectful API boundary (algebraic effects intuition)

System: A “Payment Authorize” service.

• Signature layer (A.6.0).

  • Vocabulary: PaymentRequest, AuthDecision, MerchantId, Money, etc.
  • Laws: e.g., “If decision is APPROVED then reservedAmount = requestedAmount” (truth‑conditional).
  • Applicability: bounded context “Payments/Authorization”.

• Mechanism layer (A.6.1).

  • Admissibility gate: request is admissible iff tokenValid ∧ merchantActive ∧ amountWithinLimit.
  • Transport: HTTP headers, idempotency key transport, canonical currency conversions.
  • Audit/Observability: specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their semantics (fields, correlation IDs, retention class).

• Realization/work layer.

  • Actual side effects: reservation entry in ledger, emission of event, timers, retries.
  • Evidence: traces, logs, metrics.

• Publication faces (MVPK).

  • PlainView: narrative for stakeholders (what the service promise is, in plain terms).
  • TechCard: signature/mechanism details (types, error codes, version policy, admissibility predicate refs).
  • InteropCard: machine‑exchange oriented boundary details (canonical field names, schema refs, transport bindings).
  • AssuranceLane: evidence bindings (which carriers exist, how to adjudicate E-* claims, retention/access duties by reference).

SoTA tie‑in: This boundary is naturally understood using algebraic effects & handlers: the signature is the “operation interface” (effect signature), while the mechanism/realization provides handlers (semantics). The stack keeps the abstract operation signature stable while allowing multiple handlers/realizations to evolve.

Routing example:

• “Defined iff tokenValid” belongs in Quadrant A (admissibility gate).
• “Clients MUST include Idempotency‑Key” belongs in Quadrant D (agent obligation) but should reference the same gate semantics to avoid divergence.
• “System emits AuthorizationRecord” belongs in Quadrant E (evidence via carriers).

#Show #2 (U.Episteme): published evaluation protocol boundary (multi‑view + evidence)

Episteme: A published “Model Evaluation Protocol” for a safety‑critical classifier.

• Signature layer: defines operations like Evaluate(model, dataset) → Report and truth‑conditional definitions of metrics (AUROC, calibration error) as Laws.

• Mechanism layer: admissibility gate encodes when evaluation is permitted: dataset version must match declared license; measurement environment must meet constraints; seeds pinned.

• Deontics/commitments: reviewers MUST use dataset vX.Y; authors SHALL publish MVPK faces and cite the measurement environment; an organisation commits to a review SLA (explicitly an agent commitment).

• Effects/evidence: the produced report file, logs of evaluation runs, cryptographic hashes, and trace IDs are carriers. A.7 discipline prevents calling the report “the evaluation” (object) and prevents treating the file as the model.

• Multi‑view (MVPK canonical face kinds only):

  • PlainView for decision makers: what this protocol means for assurance.
  • TechCard for engineers: metric definitions named by value, admissibility predicates, and a clearly marked Norms/Commitments section (D‑claims) for governance.
  • InteropCard for exchange-oriented consumers: conceptual field names/anchors and schema references (concrete format mapping lives outside Part E).
  • AssuranceLane for auditors: evidence map (which carriers prove what happened) and adjudication steps keyed by E-* IDs.

This episteme is a boundary because it mediates between theory (“metric definitions”) and work (“a run produced a report”). The signature stack provides the stable interface for that mediation.

#Bias‑Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for boundary descriptions in A.6.*.

• Arch bias: Biases toward separation of concerns and explicit layering; mitigated by allowing multiple faces (views) so audiences are not forced into the same amount of detail.
• Onto/Epist bias: Treats signatures/mechanisms as epistemes that must not be conflated with work; mitigated by explicit evidence carriers and evidence records.
• Gov bias: Prefers auditable responsibility (viewpoint accountability and commitment unpacking); mitigated by keeping the stack conceptual and tool‑agnostic.

#Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#Consequences

#Rationale

A boundary is simultaneously:

• a mathematical object (signature: operations over vocabulary, governed by laws),
• an engineering interface description (stable intent, evolvable implementations),
• a governance object (commitments, responsibilities, deontics), and
• an operational phenomenon (effects happen only by doing work and observing traces).

If these are mixed, evolution becomes impossible to reason about: every change becomes “semantic”, and every claim becomes unfalsifiable.

The stack creates a default direction of dependence: higher layers constrain lower layers, not vice versa. The matrix creates a default routing that is not reliant on word choice alone and therefore survives natural‑language variation (“must”, “guarantee”, “valid”, “allowed”).

#SoTA‑Echoing (post‑2015 practice alignment)

Informative. Alignment notes; not normative requirements.

• Adopt — algebraic effects & handlers / effect systems. Modern effect systems separate the signature of operations from handler semantics (e.g., Koka’s effect typing; mainstream effect handlers in OCaml 5 era). A.6 aligns by keeping boundary-signature content in U.Signature and placing execution semantics in U.Mechanism/Realizations, preserving substitution and evolvability.

• Adopt — session/behavioural types for protocol boundaries. Post‑2015 practice in behavioural typing treats boundaries as typed interaction protocols with progress/safety properties. A.6’s routing matrix makes “protocol laws” (Quadrant L) explicit and separates entry gates (Quadrant A) from agent duties (Quadrant D) and runtime evidence (Quadrant E), reducing ambiguity.

• Adapt — categorical optics / lenses / bidirectional transformations. Contemporary lenses treat boundaries as paired transformations with coherence laws; this mirrors the signature/mechanism split plus cross‑context view morphisms. In FPF, the “projection faces” (views) remain governed by viewpoints, and any cross‑context reuse must remain explicit (Bridge/CL discipline).

• Adapt — ISO/IEC/IEEE 42010 viewpoint discipline and views‑as‑queries (SysML v2 motif). A.6 explicitly preserves viewpoint as a first‑class accountability handle: MVPK requires viewRef and viewpointRef, turning “views” into disciplined projections rather than informal screenshots.

• Adapt — DDD bounded contexts and microservice contract-language practice. Modern architecture practice keeps meaning local and makes crossings explicit. A.6’s stack and L/A/D/E claim-classification discipline provide a precise placement scheme for what belongs to the context boundary claim set, what belongs at the entry gate, what belongs to governance duties, and what belongs to observability evidence.

• Adapt — observability as evidence discipline. Post‑2015 observability practice treats traces/logs/metrics as first‑class evidence carriers. A.6 places such claims in Quadrant E and ties them to carriers (A.7), preventing “guarantees without telemetry”.

• Adapt — Zero Trust, dynamic authorization, and policy-as-code practice. Current authorization practice separates policy, API, or schema text from a decision over subject, requested policy operation or work class, affected resource or work target, context, policy or gate version, decision source, and evidence. Cedar-style policy language and Zanzibar-style relation authorization are useful practice anchors for this split: the wording is not the decision. A.6 keeps policy, API, or schema wording in routed L-*, A-*, D-*, and E-* claims and returns work use or reliance use to A.15 rather than letting "allowed" or "authorized" wording decide by itself.

• Adopt/adapt/reject stance for authority-looking boundary wording. A.6 adopts policy-as-code separation of policy text from evaluated decision, adapts credential, register-backed status, provenance, and attestation practice as source, evidence, and currentness support rather than as the L/A/D/E split itself, and rejects visible wording, schema cues, credential displays, register excerpts, or provenance labels as permission, gate passage, work occurrence, evidence, or assurance by themselves.

• Adapt — Markov blankets / active inference as probabilistic boundary views. Markov‑blanket thinking can help pick observables and diagnose “boundary leaks”, but it does not replace deontics, invariants, or admissibility gates; therefore it is a complementary view under a viewpoint, not the primary boundary-description object.

#Relations

• Implements authoring discipline: Follows canonical section order and style expectations from E.8.
• Constrains signature writing: Reinforces A.6.0 separation of Laws vs operational gates (AdmissibilityConditions live in mechanisms).
• Constrains mechanism writing: Aligns with A.6.1 structure (Signature block plus mechanism‑only blocks such as AdmissibilityConditions, Transport, Audit).
• Requires EntityOfConcern and Description-episteme / publication-carrier discipline: Uses A.7 to prevent category mistakes; ties evidence to evidence carriers and publication faces to descriptions.
• Operationalises U.View and U.Viewpoint accountability: Uses MVPK and U.MultiViewDescribing (E.17.0) so each face is a projection under a viewpoint, not a viewpoint‑free snapshot.
• Unpacks “contract” talk: Reuses F.18’s promise/utterance/commitment separation to keep agency and responsibility explicit.
• Connects to signature engineering patterns: A.6.5 (slot discipline) and A.6.6 (anchor/base discipline) can be read as “constructor/enabling” operations that help build well‑formed signatures by disciplined unpacking and grounding (they belong in the same stack discipline because they govern boundary construction).
• Coordinates with C.28 CausalUse-CAL: When boundary prose uses causal support to justify deployment, release, duty, commitment, or admissibility, A.6 splits the boundary sentence while C.28 carries the causal-use question, CausalityLadderRung, estimand, support basis, support verdict, and supported causal use and unsupported causal use.
• Coordinates with A.15, A.10, B.3, A.21, A.20, and A.15.1: When routed boundary wording is then used for work, reliance, evidence, currentness, provenance, assurance, gate decision, constraint-validity witness, release work occurrence, or deployment work occurrence, the required claim or effect is carried by the exact source: A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef; A.20 for ConstraintValidity status or witness; A.15.1 for dated U.Work occurrence.

#Quantum-like boundary-route note

Use A.6 first for ordinary boundary, interface, API, protocol, contract, connector, publication-face, and observability-evidence wording. Quantum-like boundary prose is supported only after the boundary text still needs a probe, order, frame, export, or state-reading distinction that ordinary boundary patterns would otherwise erase.

Action path:

1. Identify the boundary sentence and name the boundary object in ordinary A.6 terms.
2. Name endpoints, channel, and carrier separately; do not let one word such as "interface", "service", "contract", or "context" stand for all of them.
3. Apply the applicable ordinary FPF patterns to the ordinary boundary content: A.6, A.6.B, F.9, A.15, C.16, or C.25.
4. If the boundary text uses a coarsened representation to claim preserved action, intervention, manipulation, explanation, or preserved structure across representation scales, state the causal-abstraction or approximate-causal-abstraction mapping before retaining QL wording.
5. Ask whether the boundary act is being used as a passive read or unjustified lossless-transfer reading while actually changing the represented state, export validity, or viability decision.
6. If yes, apply C.26.1 only to that remaining residual question; keep the ordinary boundary pattern active.
7. If no, keep the text in the ordinary boundary, bridge, work, measurement, or quality pattern and remove QL wording.

Minimum boundary discipline before a quantum-like boundary reading:

Useful outputs:

• an L/A/D/E-classified boundary claim set when ordinary A.6 is enough;
• a Bridge Card when the issue is export/loss across contexts;
• a C.26.1 probe-coupled boundary note only when the boundary act changes the represented state in a decision-relevant way;
• a relation repair using A.6.P or F.18 when coupling words become reusable relation candidates.

#A.6:End

#Recognition Signatures for Descriptions

Type: Architectural pattern Status: Stable Normativity: Normative unless marked informative

#Problem frame

A reader often meets one description before they know whether it is the right description to inspect. The reader may see a boundary clause, method note, interface excerpt, pattern opening, or public projection. The first entry load is not yet the full semantics of that description. It is first-contact recognition: what description is seen, where it is encountered, what it applies to, what excludes it, which definitionEpistemeRef identifies its defining U.Episteme, and which nearby reading or wrong defining U.Episteme must be rejected.

Plain recognition line. Do not let the first wording you see define itself; ask which defining U.Episteme gives it meaning and which nearby reading it rejects.

Use this pattern when the live entry load is still first-contact recognition over one encountered description carrier or projection. The reader needs to decide whether this is the right description to inspect before broader comparison, publication-face selection, boundary-claim routing, or pattern-language entry comparison begins.

What goes wrong if this pattern is missed:

• one summary, excerpt, boundary phrase, or local top is mistaken for the defining U.Episteme of the description;
• one access/request description is over-read as a promise about downstream effect;
• one boundary-presented description is over-read as L/A/D/E-classified claim structure or as the full semantic claim set;
• one method note is treated as applicable before its actual method family and exclusions are recoverable;
• one pattern-local opening is forced to carry cross-pattern comparison that belongs to E.11.

What this pattern buys:

• the reader can tell what the encountered description is for before deeper semantics are reconstructed;
• carrier, projection, description, and defining U.Episteme stay distinct;
• false neighboring descriptions and wrong defining U.Episteme references become rejectable in one first pass;
• later boundary, publication, lexical, or pattern-language repairs start from a typed first-contact read instead of from guesswork.

Ordinary not-this-pattern boundary:

• not when the live entry load is already full routed-claim structure, published view law, lexical repair, or cross-pattern entry orientation;
• not when the real question is the whole semantics of the method, boundary claim, interface promise, or pattern;
• not when a search/query phrase needs naming repair rather than first-contact recognition of a particular encountered description.

#Problem

When first-contact recognition is under-governed, several defects recur:

1. One reader finds a boundary, method, interface, or pattern-local opening but cannot tell whether it is the right description to inspect.
2. An encountered carrier or public projection is misread as the defining U.Episteme.
3. Recognition cues drift into description semantics, workflow hints, graph metaphors, or lexical aliases that belong elsewhere.
4. Pattern-entry navigation is asked to solve a broader description-recognition entry load that belongs before pattern-language comparison begins.

#Forces

#Solution

#Relation-signature object and non-goals

A.6.RSIG governs description-recognition signatures in general: the first-contact cue structure by which one reader can recover what encountered description is live, what carrier or projection exposed it, what it applies to, what excludes it, which definitionEpistemeRef identifies its defining U.Episteme, and which nearby false description or wrong defining U.Episteme must be rejected.

Here "description-recognition signature" is lower-case authoring and reading discipline. It is not U.Signature, not a Signature Stack object, not a new Description object by default, not a U.* kind, and not a specialization of A.6.0 unless another pattern explicitly promotes a particular declaration.

The encountered carrier or projection may help recognition; it does not become authoritative merely by being encountered. When this pattern talks about an encountered publication or projection, that wording does not mint a new surface kind; use an existing publication face, publication form, interop publication form, U.View, card, or lane kind only when that kind is actually being made.

Use definitionEpistemeRef for the defining U.Episteme. If the definition is available only through one publication, cite the U.EpistemePublication that publishes it separately; the publication, projection, or carrier does not become the defining episteme by being the encountered item.

A.6.RSIG does not govern:

• general information architecture or search UX;
• documentation layout or publication-face selection;
• pattern-entry discoverability across a pattern language;
• the full semantics of the description itself;
• lexical repair, alias acceptance, or naming governance as such;
• graph ontology, workflow sequencing, or runtime route semantics.

#Two-level description-recognition shape

Reader-visible minimum. For ordinary reader-facing use, the minimum is not a card. One or two good sentences may be enough if they make recoverable:

1. what this description is for;
2. when it applies;
3. when it does not apply;
4. which definitionEpistemeRef applies;
5. what nearby false reading or wrong defining U.Episteme to reject.

Review-expanded shape, only when needed. When the recognition entry load is load-bearing or under review, use the expanded recoverability shape:

description_seen
encountered_carrier_or_projection
reader_viewpoint
case_signal_or_access_condition
applies_to
excludes
expected_first_recognition_gain
first_admissible_entry_stop_or_reroute
definitionEpistemeRef
projection_role_if_any
nearby_false_description_or_wrong_definition_episteme

This shape is a review aid, not a mandatory form for every encountered description. It exists to keep description, carrier, projection, and definitionEpistemeRef from collapsing into one overloaded publication label or projection label.

#Minimal local repair and review sequence

Use this sequence when authoring or reviewing one recognition-signature repair:

1. Name the description_seen and the reader viewpoint in one concrete first sentence.
2. Name the encountered carrier or projection if confusing it with authority is a live risk.
3. State what the description applies to and what excludes it.
4. Name the defining U.Episteme to inspect first.
5. Name one nearby false description or wrong defining U.Episteme that looks plausible in the same situation.
6. State the first admissible entry stop or neighboring-pattern application.
7. If that stop cannot be stated without A.6.B claim routing, publication-face law, lexical repair, or cross-pattern comparison, apply the appropriate neighboring pattern instead of stretching A.6.RSIG.

Minimal admissible output:

• one first-contact recognition statement the reader can use immediately;
• one explicit defining U.Episteme;
• one explicit false-neighbor rejection;
• one admissible entry stop or reroute.

#Parent cases

A.6.RSIG keeps the main parent cases explicit:

• boundary-description recognition: can one reader recover what one boundary-presented description is for before L/A/D/E-classified claim structure becomes the dominant entry load;
• method-description applicability recognition: can one reader recover whether one method description is the right description to inspect, reject, or compare under the live entry load;
• interface/access-description recognition: can one reader recover the right access or interface description without confusing it with promise, execution, or downstream effect semantics;
• pattern-local recognition-signature case: can one reader recover one pattern opening as the right first description to inspect before broader pattern-language comparison begins.

#Neighbor boundaries

Neighbor boundaries remain explicit:

• A.6.B governs routed L/A/D/E claim structure when the boundary description is already in routed-claim territory;
• E.17.0 / E.17 govern admissible view and publication-face projection when the same recognition entry load is carried through published views;
• E.10.D2 and the E.10 / F.18 / A.6.P lane govern lexical repair, collision checks, and naming survival;
• C.25 / C.16.Q govern formal quality treatment when the discoverability or recognition claim becomes explicitly evaluative;
• the relevant authoritative pattern body governs pattern semantics when the encountered description is one pattern-local opening.

The four-part split for pattern-local recognition is:

#No-minting rule

This pattern does not mint:

• one standalone U.Discoverability;
• one new U.Signature, Signature Stack object, U.Characteristic, CHR, or local Q-Bundle;
• one publication face kind, publication form kind, interop publication form kind, carrier kind, DescriptionKind, relation kind, graph ontology, pattern-reference publication graph, or process-family claim;
• one universal reader-orientation role.

If a recognition-signature entry load is promoted into a quality claim with a higher evidence requirement, typed signature object, reusable description object, or publication-face law, that promotion is explicit and handled by the existing neighboring patterns.

#Archetypal grounding

#System-side worked recognition repair: boundary-presented description

Draft cue:

"The system shall reject invalid requests."

Why the cue is not enough yet:

• the reader can tell this is important, but not whether they are reading one law, admissibility gate, duty, work effect, or evidence statement;
• one summary page or local paraphrase can be mistaken for the governing boundary description;
• a reviewer can start arguing full semantics before the first-contact recognition entry load has been stabilized.

Recognition repair:

1. description_seen = one boundary-presented admissibility description.
2. encountered_carrier_or_projection = one clause or excerpt where the description is seen.
3. reader_viewpoint = one practitioner or reviewer deciding whether this is the right boundary description to inspect first.
4. applies_to = requests presented at the boundary under the declared admissibility conditions.
5. excludes = downstream effect claims, duty allocation, or evidence claims not actually stated by this description.
6. definitionEpistemeRef = the governing boundary description, not one local paraphrase or summary note.
7. nearby_false_description_or_wrong_definition_episteme = one evidence/work claim or one routed quadrant statement that only becomes admissible after the reader has stabilized the admissibility description.
8. first_admissible_entry_stop_or_reroute = the reader can now say "this is the admissibility description to inspect first"; if the entry load becomes routed claim structure, inspect A.6.B.

#System-side anti-case: interface/access description over-read as promise

Draft cue:

"POST /deploy triggers deployment."

Plausible but wrong first reading:

• the reader treats one access/request description as if it already promised one downstream operational effect or successful completion.

Recognition repair:

1. description_seen = one interface/access description.
2. encountered_carrier_or_projection = one API excerpt or endpoint note.
3. applies_to = request accessibility and invocation form.
4. excludes = success, completion, rollout, or downstream effect guarantees not present in the access description itself.
5. definitionEpistemeRef = the specification or pattern that actually governs downstream effect, if that entry load is live.
6. first_admissible_entry_stop_or_reroute = "this is the access description to inspect first, not the promise of the whole deployment result."

#Episteme-side worked recognition repair: method-description applicability

Draft cue:

"Use pairwise comparison."

Why the cue is not enough yet:

• the reader cannot tell whether the note applies to ranking alternatives, selecting one option, shaping a shortlist, or comparing method families;
• the method note can be mistaken for the defining U.Episteme of selection semantics;
• a team can prematurely choose C.11 or G.5 before knowing what kind of comparison entry load is actually being made.

Recognition repair:

1. description_seen = one method-description applicability note.
2. encountered_carrier_or_projection = one method-description note, pattern excerpt, or review comment that mentions pairwise comparison.
3. applies_to = comparison under a declared comparator set or characteristic family.
4. excludes = publication of a selected set, execution planning, evidence sufficiency, and one-off decision doctrine unless those governing FPF patterns or authoritySourceRef targets are separately opened.
5. definitionEpistemeRef = the relevant comparison or method pattern, not the note itself.
6. nearby_false_description_or_wrong_definition_episteme = selection/publication doctrine treated as if the method note had already settled it.
7. first_admissible_entry_stop_or_reroute = method applicability is recognized or rejected before selection semantics begin.

#Bias-Annotation

This pattern counters:

• front-door centralization bias, where every recognition entry load is pushed into one global front-door cue;
• signature-stack overreach, where any useful cue is prematurely promoted into U.Signature;
• carrier-authority collapse, where an encountered carrier or projection is treated as the defining U.Episteme;
• alias bias, where uncontrolled synonyms compensate for missing recognition structure;
• workflow bias, where first-contact recognition is narrated as sequence or handoff.

#Conformance checklist

• CC-RSIG-1 First-contact only. The pattern governs recognition of the right description, not the full semantics of that description.
• CC-RSIG-2 Carrier/definition-episteme split. A conforming description-recognition signature distinguishes description_seen, encountered carrier or projection, defining U.Episteme, and projection role when those distinctions are load-bearing. The encountered carrier or projection may help recognition, but it does not become authoritative merely by being encountered.
• CC-RSIG-3 Neighbor boundaries explicit. The text states when entry loads go to A.6.B, E.17, E.10 / F.18 / A.6.P, C.25 / C.16.Q, or the relevant authoritative pattern body.
• CC-RSIG-4 No kind inflation. Recognition signatures are not silently promoted into U.Signature, Signature Stack objects, publication face kinds, publication form kinds, carrier kinds, graph objects, workflow objects, or new U.* kinds.
• CC-RSIG-5 Recoverable cue shape. For load-bearing cases, description, viewpoint, cue, applicability, exclusion, defining U.Episteme, false neighbor, and admissible entry stop remain recoverable.
• CC-RSIG-6 No alias minting. Query cues and ordinary phrasing do not become aliases, bridges, semantic twins, or lexical authority without applying the relevant naming pattern or authoritySourceRef target.

#Common Anti-Patterns and How to Avoid Them

• Recognition-as-semantics. The opening tries to define the whole description instead of making the right description recoverable. Repair by shrinking back to first-contact discrimination.
• Carrier-as-authority. A local excerpt, public projection, or retrieved fragment is treated as the defining U.Episteme. Repair by naming the encountered carrier or projection and the defining U.Episteme separately.
• Boundary-routing collapse. A boundary-description cue tries to absorb L/A/D/E-classified claim structure. Repair by classifying quadrant work under A.6.B.
• Pattern-language collapse. Pattern-entry comparison is written as if it were just another description cue. Repair by routing cross-pattern selection to E.11.
• Signature inflation. Any recurring cue is treated as one typed signature object. Repair by keeping description-recognition signature lower-case unless one explicit promotion is justified.

#Consequences

This pattern gives one neutral governing discipline for first-contact description recognition without turning discoverability into one universal governing pattern. It sharpens the boundary between cue recognition, semantic authority, lexical repair, publication-face projection, and pattern-language entry.

The cost is one extra explicit split when a cue is confusing: description, encountered carrier or projection, defining U.Episteme, and false neighbor must not be collapsed. The cost stays bounded because the expanded shape is review-only or risk-triggered, not a required card for ordinary prose.

#Rationale

This pattern lands in the A.6 cluster because the entry load is still one description/signature entry load: a reader is recovering what one description is for, what it applies to, and which defining U.Episteme to inspect first. That sits closer to signature and boundary discipline than to pattern-language navigation or review-profile law.

Read this honestly as one FPF-local synthesis over current SoTA, not as one already established external standard term. It combines information-scent, human/AI expectation-management, controlled vocabulary, and retrieval-context practices into one description-facing discipline for FPF.

#SoTA-Echoing

This pattern is an FPF-local synthesis, not an established external term. It carries the modern practice concern only where that concern sharpens one description-facing recognition question: can the reader recover the right description, its carrier or projection, its exclusions, its defining U.Episteme, and its tempting false neighbor before relation precision or epistemic precision-restoration work begins?

#Relations

• Builds on: A.6, A.6.P, F.18, E.10
• Does not specialise: A.6.0 / U.Signature; it uses "signature" only in the lower-case cue-pattern sense unless an explicit neighbouring pattern promotes the structure into a typed declaration.
• Neighbors: A.6.B, A.6.C, E.17.0, E.17, E.10.D2, C.25, C.16.Q
• Supports: E.11 as the pattern-language application above this neutral substrate

#A.6.RSIG:End

#A.6.B — Boundary Norm Square (Laws / Admissibility / Deontics / Work‑Effects)

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.6.B (matrix module; referenced by A.6 cluster overview) Builds on: E.8 (authoring template), A.6.0 (U.Signature), A.6.1 (U.Mechanism), A.6.3 (U.EpistemicViewing), E.17.0/E.17 (MVPK + “no new semantics” faces), A.7 (EntityOfConcern and Description-episteme boundary; specification-use and publication-carrier distinction), F.18 (promise/utterance/commitment), E.10.D2 (EntityOfConcern and Description-episteme boundary; specification-use/refinement discipline), E.10 publication face, form, unit, and carrier discipline Purpose (one line): Provide a canonical 2×2 norm square that classifies boundary statements (L/A/D/E), constrains how each quadrant is written, and defines explicit cross‑quadrant reference rules so boundaries remain evolvable and audit‑ready.

#A.6.B:0 — Conventions

Keywords. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, MAY, and SHALL are to be interpreted as in RFC 2119/8174. Lower‑case “must/may/should” in explanatory prose is descriptive, not normative.

Quadrant labels. This pattern uses the routing labels L / A / D / E as statement quadrants:

• L — Laws & Definitions
• A — Admissibility & Gates
• D — Deontics & Commitments
• E — Work‑Effects & Evidence

These labels are claim-classification labels for statements, not MVPK face kinds and not pattern identifiers.

Statement identifiers (recommended). Routable statements SHOULD be given stable IDs with a quadrant prefix: L-*, A-*, D-*, E-*. Other sections and views SHOULD reference these IDs rather than restating the same constraint in new words.

Non-collision note (informative). The A-* prefix here is “Admissibility”, not Part‑A numbering and not MVPK’s AssuranceLane face kind. If this is a readability hazard in your program, prefer an explicit G-* (“Gate”) local convention while keeping the quadrant name “Admissibility”. Also avoid introducing single‑letter mnemonics for MVPK face kinds inside this cluster (MVPK has a legacy L,P,D,E mnemonic); spell face kinds in full to reduce collisions.

Atomic claim. An atomic claim is a sentence (or bullet) that performs exactly one logical role and is routable to exactly one quadrant. If a sentence mixes roles, it is not atomic and MUST be split before it can be routed.

Adjudication substrate (for routing). For the purposes of this square, an atomic claim is classified by the primary substrate that decides its satisfaction:

• In‑description / in‑theory: satisfaction is decided from the description alone (e.g., proof/type validation), or the claim is itself a governance utterance whose content is fully determined by the text.
• In-work or in-execution: deciding satisfaction requires observing executed work and/or inspecting carriers produced in work.

Note (important). D-* claims are authored and interpreted in the description; whether they are met is typically established indirectly via referenced E-* claims (or other governance procedures). This does not move D-* into quadrant E; it clarifies the routing distinction.

Modality family. A claim is either:

• Truth‑conditional: definitions, invariants, typing rules (“is”, “iff”, “∀”).
• Governance: governance conditions, obligations, commitments, and exclusions (“MUST/SHOULD/MAY”, “is admissible”, “is blocked”, “commits to”).

#A.6.B:1 — Problem frame

Boundary descriptions routinely collapse four distinct claim families into “contract soup”: definitions are written as obligations, runtime gates are hidden inside laws, governance talk is assigned to “the interface”, and “guarantees” are asserted without any evidence story. The resulting boundary is brittle: substitution becomes unclear, and auditability becomes performative rather than adjudicable.

FPF already separates the necessary strata (Signature vs Mechanism, EntityOfConcern / Description episteme / carrier, views under viewpoints). What is still needed is a single, reusable routing primitive that any boundary text can apply consistently and that other patterns can cite as a stable authoring module.

#A.6.B:2 — Problem

When authors cannot reliably answer two questions—

1. “Is this a truth‑conditional statement or a governance statement?”
2. “Is it adjudicated by reading the description or by observing work?”

—then boundary statements drift across layers, faces fork semantics, and “compliance” becomes a matter of interpretation rather than a property that can be checked.

A boundary needs a minimal, stable classification that:

• routes every atomic statement to a unique quadrant, and
• forces any cross‑quadrant dependencies to be explicitly referenced, not smuggled by paraphrase.

#A.6.B:3 — Forces

#Solution — the Boundary Norm Square

#Two independent distinctions

The Boundary Norm Square is the cross product of two independent distinctions:

1. Modality family: Truth‑conditional vs Governance
2. Adjudication position: In-description vs in-work

The square yields four quadrants that are mutually exclusive for atomic claims.

#A.6.B:4.2 — The square

Clarification (do not conflate). The Governance column includes two different “normative” roles:

• D is U.Agent or U.Role governance (duties, commitments, prohibitions).
• A is mechanism governance (admissibility predicates: what the mechanism admits at application time). A-* is not an obligation on an actor; obligations belong in D-* and may reference A-*.

Normative rule (single quadrant). Each atomic claim MUST be routable to exactly one quadrant L/A/D/E.

Normative rule (no mixed sentences). A conforming boundary text SHALL decompose any sentence that bundles multiple quadrants (typical form: “MUST … if … then … and it is logged …”) into multiple atomic claims before those claims are treated as normative.

#A.6.B:4.3 — Canonical placements in the Signature Stack

The quadrants have canonical placements in the boundary stack:

• L → Signature layer: U.Signature.Laws (and mechanism‑local semantic laws if present).
• A → Mechanism layer: U.Mechanism.AdmissibilityConditions (entry gates / runtime admissibility predicates).
• D → Norms & commitments layer: role‑anchored duties, commitments, publication/accountability duties (often rendered inside MVPK TechCard).
• E → Evidence bindings layer: work‑adjudicated effects tied to carriers and measurement conditions (authored canonically in an Evidence/Carriers section; commonly rendered inside MVPK AssuranceLane as a projection).

A published view MUST NOT introduce new semantic claims outside this L/A/D/E-classified claim set. E.17 (MVPK) is a specialization that enforces this rule for a fixed set of publication face kinds.

#A.6.B:5 — Quadrant specifications

This section is the normative “API” of the square: what each quadrant is for, how it is written, and what it must not contain.

#A.6.B:5.1 — Quadrant L: Laws & Definitions

Intent. State truth‑conditional content: definitions, invariants, typing/well‑formedness constraints, equational laws.

Adjudication. In‑description: can be checked by inspection, proof, type validation, or model reasoning.

Canonical form. Definition: / Invariant: / predicate‑style constraints using “is / iff / for all”.

Prohibitions.

• An L-* statement MUST NOT contain RFC deontic keywords (MUST/SHALL/SHOULD/MAY) as operators inside the law/definition itself.
• An L-* statement MUST NOT encode runtime gate predicates (those are A-*).
• An L-* statement MUST NOT assert evidence availability or measurement outcomes (those are E-*).

A.7 anchoring. L-* claims are Descriptions: they specify semantics of the signature/mechanism description, not work.

Typical dependence. A-* and E-* claims may reference L-* IDs for vocabulary, metric definitions, and invariants needed for interpretation.

#A.6.B:5.2 — Quadrant A: Admissibility & Gates

Intent. Specify when a mechanism application is admissible: runtime entry predicates, authorization gates, validity gates, applicability checks that require context or execution environment.

Common mistake #0 — Applicability ≠ Admissibility (informative). Signature Applicability scopes intended use/bounded context; it is not a runtime entry gate. Runtime entry checks and admissibility predicates belong in U.Mechanism.AdmissibilityConditions as A-*. If your prose reads like “clients must satisfy the applicability”, you almost certainly want a D-* duty + an A-* gate (linked by ID) instead.

Adjudication. In‑work: evaluated at mechanism entry (or operationally at the point the mechanism is applied).

Canonical form. Predicate style, e.g.:

• “A request is admissible iff …”
• admissible(x) iff P(x) (conceptual form; no particular syntax is required)

Prohibitions.

• An A-* statement MUST NOT be placed in U.Signature.Laws.
• An A-* statement MUST NOT use RFC deontic keywords as if it were an agent obligation. (It is a gate predicate, not a duty.)
• An A-* statement MUST NOT claim that evidence exists (that is E-*) or that someone must enforce the gate (that is D-*).

A.7 anchoring. A-* claims are Descriptions of a mechanism gate. They are not “what a client must do”; they are “what the mechanism admits”.

Required references (explicit). If an A-* predicate relies on defined terms or invariants, it SHOULD reference the relevant L-* IDs (or at minimum the signature that defines them).

#A.6.B:5.3 — Quadrant D: Deontics & Commitments

Intent. State governance: obligations, governance conditions, exclusions, commitments, publication duties, operational duties, contractual commitments—always with accountable agents/roles.

Adjudication. In‑description (governance is stated in the spec); compliance may be audited via E-*.

Canonical form. A deontic statement MUST have an accountable subject (U.Agent or U.Role), e.g.:

• “Client implementers MUST satisfy A-….”
• “Operators SHALL retain carriers …”
• “Provider SHALL meet E-… under exclusions …”

Canonical payload (recommended; lintable). When a D-* claim is intended to be lintable/reusable, it SHOULD be representable as a U.Commitment record (A.2.8). Default fields to make explicit:

• id (often the D-* claim ID),
• subject (accountable role/party; never an episteme),
• modality (BCP‑14/RFC keyword family normalized),
• scope + validityWindow,
• referents (by ID; e.g., SVC-*, L-*, A-*, E-*, MethodDescriptionRef(...)),
• optional adjudication.evidenceRefs when the commitment is meant to be auditable,
• optional source when authority/provenance matters.

Prohibitions.

• A D-* statement MUST NOT use “the system/service/interface/spec” as the grammatical subject unless the accountable role/party is explicitly named (so the statement is representable as a U.Commitment with an explicit subject, A.2.8). (F.18 is a lexical anchor only.)
• A D-* statement MUST NOT restate L-* or A-* predicates in new words when an ID exists; it SHOULD reference the ID.
• A D-* statement MUST NOT pretend that commitments are laws. A commitment is an agent relation, not a truth‑conditional invariant.

A.7 anchoring. D-* claims are primarily about Objects (roles/agents and their duties) or about Carriers (retention/exposure duties), but they are still written as Descriptions.

Required references (explicit).

• If a D-* statement imposes compliance with a gate, it MUST reference the relevant A-* ID(s).
• If a D-* statement is meant to be auditable, it SHOULD reference the E-* claim(s) that provide evidence and the carrier classes involved.

#A.6.B:5.4 — Quadrant E: Work‑Effects & Evidence

Intent. State what happens in work and how it can be evidenced: observed effects, emitted events, traces/logs/metrics, produced reports, measurement outcomes.

Adjudication. In‑work: checked by running/operating and inspecting carriers produced in work.

Canonical form. An E-* statement SHOULD include the minimum fields needed for adjudication:

1. Observation/measurement conditions (when/where/how observed; workload/window; triggers)
2. Carrier class/schema reference (A.7 Carrier) that bears the evidence
3. Viewpoint/consumer (who uses this evidence and why; ties to viewpointRef discipline)

Prohibitions.

• E-* statements SHOULD NOT use RFC deontic keywords (they are not obligations; they describe adjudicable effects/evidence).
• An E-* statement MUST NOT hide a gate predicate; gate predicates are A-*.
• An E-* statement MUST NOT assign agency (“the interface guarantees …”); if enforceability/commitment is intended, express it as D-* referencing the E-*.

A.7 anchoring. E-* claims are primarily Carrier‑anchored: they assert what carriers exist and how they relate to observed work.

Required references (explicit).

• If the effect/evidence is conditioned on a gate decision, the E-* statement SHOULD reference the relevant A-* ID(s).
• If the evidence is interpreted using metric definitions or invariants, the E-* statement SHOULD reference relevant L-* ID(s).

#A.6.B:6 — Cross‑quadrant link discipline

The square is not just classification; it is a dependency discipline. Claims often depend on each other; such dependencies MUST be explicit (by claim ID) rather than duplicated prose.

#A.6.B:6.1 — Explicit reference rule

If a claim’s meaning materially depends on another L/A/D/E-classified claim, that dependency MUST be represented as an explicit reference to the other claim’s ID (or to the canonical location where it lives), rather than by restating it.

Guideline (informative). Treat this as “import hygiene” for prose: reuse by reference, not by copy.

#A.6.B:6.2 — Canonical cross‑quadrant dependency patterns

These patterns are valid (and common). The square becomes operational when these links are used systematically.

#(D → A) Duty-to-gate linkage

When governance requires someone to comply with a gate:

• D-*: “Role MUST satisfy/enforce A-*.”

This separates what is admissible (A) from who is responsible (D).

#(E → A) Evidence-for-gate linkage

When gate decisions must be observable:

• E-*: “On rejection/acceptance due to A-*, carrier C is produced/observable under conditions …”

This separates gate semantics (A) from evidence semantics (E).

#(D → E) Duty-to-evidence linkage

When governance requires evidence production/retention/exposure or commits to measured properties:

• D-*: “Role MUST retain/expose carrier class C used by E-* …”
• D-*: “Provider SHALL meet E-* under exclusions …”

This separates obligation/commitment (D) from adjudication (E).

#(A/E → L) Semantic grounding linkage

When a gate predicate or measurement relies on definitions/invariants:

• A-* / E-* references L-* that define terms/metrics.

This prevents “metric drift” and “definition drift” across views.

#(D → L) Governance-to-definition linkage

When an obligation/commitment relies on precise term or metric meanings:

• D-* references L-* that define the terms/metrics it uses.

This keeps governance text from accidentally redefining semantics in prose.

#A.6.B:6.3 — The “triangle decomposition” for mixed sentences

Normative rule (decomposition). A conforming boundary text SHALL decompose any mixed sentence that expresses (i) an entry condition, (ii) an obligation to satisfy/enforce it, and (iii) an observability expectation into the three quadrants:

• A: admissibility predicate (A-*)
• D: duty/commitment referencing the gate (D-* → A-*)
• E: evidence binding referencing the gate (and carriers) (E-* → A-*)

This is the canonical repair for “contract soup” around validity, authorization, compliance, audit, and security boundaries.

#A.6.B:6.4 — Dependency direction (no “upward” imports)

The square is intended to preserve layered modularity: semantics should not depend on governance text, and evidence semantics should not depend on duties.

Normative rule (no upward dependencies).

• L-* claims MUST NOT depend on or reference A-*, D-*, or E-* claims (except for purely informative notes explicitly marked informative).
• A-* claims MUST NOT depend on or reference D-* claims. (A-* may reference L-* for defined terms/invariants.)
• E-* claims MUST NOT depend on or reference D-* claims. (E-* may reference A-* for conditioning and L-* for metric/term meanings.)
• D-* claims MAY reference L-*, A-*, and/or E-* claims as needed, and SHOULD do so by ID rather than restating content.

Rationale (informative). This keeps foundational meaning stable (L), keeps runtime gates independent of governance prose (A), and keeps evidence semantics independent of enforcement policy (E). Governance (D) is the place where “who must do what, using which gates and which evidence” is assembled.

#A.6.B:7 — Mini-register: Claim Register (informative, recommended)

A Claim Register is a drift‑control device that lists every routable statement verbatim with routing metadata. It is not a new meaning authority.

Guidance (informative):

• The Statement cell should contain the normative text as authored (copy/paste), not a paraphrase.
• Canonical location should point to the one place the statement “lives” (e.g., Signature.Laws, Mechanism.AdmissibilityConditions, TechCard.NormsCommitments, Evidence.Carriers), so other faces can cite it by ID.
• Stack layer should be one of {Signature, Mechanism, Norms/Commitments, Evidence/Carriers} to make routing auditable.
• A.7 primary side is the claim’s primary referent (EntityOfConcern, Description episteme, or publication carrier), even though the claim is always written as a Description episteme.
• Use References for explicit cross‑quadrant links (e.g., which D-* enforces which A-*, which E-* adjudicates which commitments, which L-* defines a metric used by E-*) and for external standards/policies where applicable.

#Archetypal Grounding (Tell–Show–Show)

Informative. Examples for learning the square; they do not add requirements beyond A.6.B:10.

#Tell (universal rule)

A boundary remains evolvable and auditable when every normative statement is decomposed into atomic claims, each claim is routed to exactly one quadrant of the Boundary Norm Square, and cross‑quadrant dependencies are expressed by explicit claim‑ID references rather than paraphrase.

#Show #1: Effect signature vs handler (post‑2015 effect systems)

A service boundary naturally mirrors algebraic effects & handlers practice (popularized broadly in the post‑2015 era, with mainstream effect handlers becoming especially prominent around OCaml 5):

• L: defines the operation vocabulary and laws (effect signature semantics).
• A: defines when the operation is admissible (runtime guard predicates).
• D: states who must enforce guards and what the provider commits to (operator/implementer duties; SLAs).
• E: ties “what happened” to observable carriers (traces/logs/metrics/events) so commitments can be adjudicated.

The square prevents accidentally writing handler obligations as laws or treating observability as a definition.

#Show #2: ML evaluation protocol boundary (reproducibility discipline)

A published “evaluation protocol” boundary (common in modern ML governance) benefits from strict routing:

• L: metric definitions and invariants (e.g., what counts as AUROC; data partition invariants).
• A: admissibility gates (dataset usage-term constraints; pinned environment constraints; seed policy).
• D: checker and author duties (publish required faces; use declared dataset version; retention duties for run evidence carriers).
• E: evidence carriers (run logs, hashes, reports, trace IDs) and adjudication conditions (which viewpoint measures, what windows).

The square keeps “must use dataset vX” (D) separate from “evaluation is admissible iff dataset usage terms match” (A), and both separate from “a run produced report carrier R with hash h” (E).

#A.6.B:8.4 — Worked Rewrite Kit (informative, recommended)

Informative. This kit is a worked, copy‑pasteable restatement of A.6.B’s rules (atomicity, L/A/D/E routing, explicit references, triangle decomposition, and no‑upward dependencies). If anything here conflicts with A.6.B, A.6.B is authoritative.

#Goal

Convert a boundary-ish sentence that mixes “laws / gates / duties / evidence” into:

1. atomic L/A/D/E-classified claims (L/A/D/E),
2. explicit references by claim ID (no paraphrase duplication),
3. a readable recomposition (Tech + Plain),
4. a minimal anti-pattern lint (things we reject / flag).

#Micro-procedure (Atomize → Route → Triangle → Link → Anchor → Recompose)

Step 1 — Atomize. Split mixed prose into atomic claims; each must route to exactly one quadrant.

Step 2 — Route (L/A/D/E).

• L if the claim is truth‑conditional and adjudicable in‑description (inspection, proof/type validation, or model reasoning over declared assumptions): definitions, invariants, typing/well‑formedness constraints. Guardrails: L-* MUST NOT (i) use RFC deontic keywords as operators, (ii) encode runtime entry predicates (those are A-*), or (iii) assert evidence existence/measurement outcomes (those are E-*).
• A if it is an in‑work gate predicate: what the mechanism admits at application time (“admissible iff …”). It is not a duty and MUST NOT be phrased as one. Guardrails: A-* SHOULD be written in predicate form and MUST NOT (i) use RFC deontic keywords as if it were an agent obligation, (ii) claim that evidence/carriers exist (that is E-*), or (iii) assign responsibility/enforcement (that is D-*). (Do not confuse this with Signature.Applicability: applicability scopes intended meaning/use; it is not a runtime entry gate.)
• D if it assigns duties/commitments to an accountable U.Role or U.Agent (RFC keywords belong here; “the interface/system promises” does not). Guardrails: D-* MUST name an accountable subject and SHOULD reference L-*/A-*/E-* by ID rather than restating them in new words (to prevent paraphrase drift).
• E if it is an in‑work truth‑conditional claim about adjudicable effects/evidence: what carriers exist, under what observation conditions, and/or what was observed. Minimum fields (recommended): (1) observation/measurement conditions, (2) carrier class/schema reference, and (3) viewpoint/consumer. Guardrails: E-* SHOULD NOT use RFC deontic keywords, MUST NOT hide a gate predicate (that is A-*), and MUST NOT cite D-*. (If the sentence is “Role SHALL measure/retain/expose …”, route that obligation to D, even if it is about evidence.)

Step 3 — Triangle decomposition. If the original sentence mixes (i) an entry condition, (ii) an obligation/commitment, and (iii) an observability expectation (a common failure mode with “guarantee/ensure/approved/aligned”), decompose it into:

• A: the admissibility predicate (what must be true to treat the claim as applicable),
• D → A: who is responsible for keeping/ensuring the predicate,
• E → A: what evidence/traces are used to adjudicate the predicate.

Note (claim-classification sanity). D-* claims are authored in the description even when their compliance is audited via E-* claims. Auditing via evidence does not move D-* into quadrant E.

Guideline. Keep gate semantics independent of specific evidence carriers: write the gate predicate in A-*, then bind observability in E-* that references the gate (E → A). A-* claims MUST NOT reference E-* (no upward dependencies), even though E-* is used to adjudicate gate satisfaction.

Step 4 — Link by ID, not by paraphrase. Supported directions (no upward deps):

• A-* may cite L-*
• E-* may cite L-* and A-*
• D-* may cite L-*, A-*, E-*
• Unsupported: L-* citing anything; A-* or E-* citing D-*.

Common link motifs (informative). The most reusable boundary rewrites use the canonical motifs: D→A, E→A, D→E, A/E→L, and D→L.

Step 5 — Anchor (minimal A.7 discipline).

• Anchor L claims in Signature.Laws (and mechanism‑local semantic laws if present), and A claims in Mechanism.AdmissibilityConditions.
• Anchor D claims to accountable roles/agents and prefer ID references (no restatement of L-* / A-* content in new words).
• Anchor E claims to carriers + observation conditions and SHOULD include viewpoint/consumer (minimum: conditions + carrier class/schema + consumer/viewpoint).

Optional drift-control. Add each L/A/D/E-classified claim verbatim to a Claim Register row (A.6.B:7) with canonical location + references so faces can cite by ID without paraphrase.

Step 6 — Recompose into readable text. Produce two surfaces:

• Tech surface: a short L/A/D/E-classified claim bundle (sometimes called a “claim skeleton”) listing L/A/D/E claims and ID references.
• Plain surface: a one-paragraph narrative that summarizes the bundle and points to IDs (no new semantics). If you need a new constraint, add a new atomic L/A/D/E-classified claim; do not smuggle it into Plain.

#Anti-pattern (quick)

• AP-1 Evidence-free guarantees. “X guarantees Y” with no E-claims.
• AP-2 Interface-as-promiser. Non-agent objects “promise/commit”.
• AP-3 Gate-as-evidence. Treating the gate predicate (A) as if it were an observation (E).
• AP-4 Gate-as-law. Entry predicates as signature “laws/definitions” (L) instead of A-*.
• AP-5 Adjective smuggling. “fast/secure/approved/aligned” used instead of qualifiers/slots.
• AP-6 Paraphrase drift. Restating L/A content in D or E with changed meaning (instead of citing by ID).
• AP-7 Deontics in predicates. RFC keywords (“MUST/SHALL/…”) used as operators inside L-* or A-* predicates (should be D-* that references L-*/A-*).
• AP-8 View-fork semantics. Recomposition/face text introduces new L/A/D/E meaning not present in the L/A/D/E-classified claim set (violates “no new semantics” discipline).
• AP-9 Applicability-as-gate. Using Signature.Applicability (intended use) as a substitute for A-* runtime admission predicates.

#Example 1 — Software engineering (SLO-ish API latency)

#Draft sentence (non-conformant)

“This API guarantees p95 latency < 200ms.”

#Atomize + Route (L/A/D/E)

L-API-01 (Definition). p95_latency(window W, population P, unit U, method M) is defined as … (formal measurement definition). (Lives in Signature.Laws or a referenced measurement definition pack.)

L-API-02 (Interface signature). The API endpoints and parameters are as declared (including parameter passing discipline / units). (Signature-level structure.)

A-API-01 (Gate predicate: admissibility). The claim “p95 < 200ms” is admissible only under declared load/profile + deployment region + sampling method + window: AdmissibleLatencyClaim := (region=US) ∧ (concurrency≤X) ∧ (payload≤Y) ∧ (W=5m) ∧ (M=HDRHistogram@v…) ∧ (P=requests that match filter F) (References L-API-01 for definition.)

D-API-01 (Commitment). ServiceOwner SHALL meet the latency target p95_latency < 200ms when A-API-01 holds, adjudicated per L-API-01 using the carriers/observation conditions in E-API-01. (References L-API-01 and A-API-01 by ID; does not restate them.)

D-API-02 (Operational duty). SRE_oncall SHALL publish incident notes when the commitment D-API-01 is violated, and SHALL avoid claiming compliance outside A-API-01. (References D-API-01 and A-API-01 by ID.)

E-API-01 (Evidence / carriers). For decisions under A-API-01, the following carrier classes are produced or observable under the declared observation conditions: trace/span IDs, raw histogram carriers with schema reference, percentile dashboard snapshots, and pinned sampling configuration for window W. Observation conditions (minimum): workload/profile selector, sampling method/config pins, and computation method reference (L-API-01). Viewpoint/consumer (minimum): the role/view that uses the carriers to adjudicate the gate and/or audit commitments (e.g., SRE/PerfReview). (References A-API-01 and L-API-01; avoids RFC deontics; does not smuggle gates. Note: E-* MUST NOT cite D-*.)

D-API-03 (Duty-to-evidence linkage). Operators SHALL retain/expose the carrier classes referenced in E-API-01 for the audit window required by policy. (References E-API-01 by ID.)

E-API-02 (Observed value claim). For interval Γ_time = [t1..t2] under conditions pinned to A-API-01 and using carriers in E-API-01, observed p95_latency = 173ms (computed per L-API-01). (References A-API-01, L-API-01 and E-API-01.)

#Triangle decomposition (explicit)

• A-API-01 is “the predicate”.
• D-API-01 → A-API-01 states the commitment under the gate/envelope.
• E-API-01 → A-API-01 anchors adjudication (carriers used to decide the gate/commitment).
• D-API-03 → E-API-01 expresses retention/exposure obligations for those carriers.

#Readable recomposition

Tech recomposition (L/A/D/E-classified claim bundle, short):

• L-API-01 defines p95 latency computation.
• A-API-01 specifies when the latency claim is admissible.
• D-API-01 states the commitment under that envelope.
• E-API-01 lists adjudicable carriers/conditions used to adjudicate A-API-01 (and therefore any commitments that reference it).
• D-API-02 assigns operational incident-note duties.
• D-API-03 assigns retention/exposure duties for carriers in E-API-01.
• E-API-02 reports observed performance under A-API-01 for Γ_time=[t1..t2].

Plain recomposition (one paragraph, readable): “The API’s latency target uses the p95 definition in L-API-01 and is only applicable under the declared operating envelope A-API-01. The service owner commits to meeting the <200ms target under that envelope (D-API-01). Adjudication uses the telemetry carriers listed in E-API-01, which operators must retain/expose (D-API-03), and the on-call SRE must publish incident notes when the commitment is violated (D-API-02). Under that envelope, the observed p95 over Γ_time=[t1..t2] was 173ms (E-API-02).”

#Example 2 — Mechanical engineering (fit / coaxiality)

#Draft sentence (non-conformant)

“This fit ensures coaxiality.”

#Atomize + Route

L-FIT-01 (Definition). coaxiality is defined relative to a declared base axis and measurement method (datum scheme, instrument, tolerance zone). (Truth-conditional: “what it means”.)

L-FIT-02 (Interface/boundary structure). The boundary relation involves shaft, bushing, datum axis, tolerance class, temperature window, assembly procedure class. (Signature-level arity recovery / slots.)

A-FIT-01 (Gate predicate). The coaxiality claim is admissible only if manufacturing and assembly satisfy the declared process envelope: material batch, temperature window, tool calibration validity, surface finish class, alignment procedure version. (Gate predicate; can be checked using evidence, but is not itself evidence.)

D-FIT-01 (Duty). ProcessEngineer SHALL ensure A-FIT-01 holds for the production lot and SHALL not release the lot for use when A-FIT-01 is false. (References A-FIT-01.)

E-FIT-01 (Evidence carriers). Evidence carriers used to adjudicate A-FIT-01 include CMM reports, tool calibration certificates, assembly logs, temperature traces, and datum scheme pins. (References A-FIT-01 and L-FIT-01; avoids RFC deontics.)

D-FIT-02 (Duty-to-evidence linkage). QualityEngineer SHALL retain/expose the carriers referenced in E-FIT-01 for the production lot. (References E-FIT-01 by ID.)

E-FIT-02 (Observed). For lot L123 and window Γ_time=[t1..t2], under conditions pinned to A-FIT-01 and using carriers in E-FIT-01, measured coaxiality was within tolerance zone T (interpreted per L-FIT-01). (References A-FIT-01, L-FIT-01, and E-FIT-01.)

#Readable recomposition

Tech bundle:

• Meaning of coaxiality: L-FIT-01.
• Boundary arity/participants: L-FIT-02.
• When the claim is admissible: A-FIT-01.
• Who is responsible: D-FIT-01.
• What we observe and keep as carriers: E-FIT-01 and measured outcome E-FIT-02 (with retention duty D-FIT-02).

Plain paragraph: “‘Ensures coaxiality’ is made precise by fixing the definition and datum scheme (L-FIT-01) and by making the boundary participants explicit (L-FIT-02). The coaxiality claim is only applicable under the declared manufacturing/assembly envelope (A-FIT-01), which the process engineer is accountable for maintaining (D-FIT-01). Compliance is adjudicated using the measurement and process carriers listed in E-FIT-01; for lot L123 over Γ_time=[t1..t2], the observed coaxiality was within tolerance E-FIT-02.”

#Example 3 — Management (project “approved/aligned”)

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Route

L-PRJ-01 (Definition). approved(project, approvalKind) is defined as a relation kind; approval kinds include: “sponsor-signoff”, “stage-gate-pass”, “budget-authorized”, “staffing-assigned”, etc. (Truth-conditional: disambiguates kind and polarity.)

A-PRJ-01 (Gate predicate: stage entry). For starting execution work, ExecutionAdmissible(project) holds iff required approvals are present and required prerequisites are satisfied (e.g., risk review completed, budget line exists, key roles staffed). (This is the real “may start work” gate; references L-PRJ-01 for what counts as approvals.)

D-PRJ-01 (Duty). ProjectOwner SHALL not initiate execution unless A-PRJ-01 holds, SHALL keep the approval registry current, and SHALL retain/expose the evidence carriers referenced in E-PRJ-01. (References A-PRJ-01 and E-PRJ-01 by ID.)

E-PRJ-01 (Evidence carriers). Evidence carriers used to adjudicate A-PRJ-01 include: signed decision record IDs, meeting minutes pins, budget system references, staffing assignment records, and gate checklist snapshots. (References A-PRJ-01; avoids RFC deontics.)

E-PRJ-02 (Observed state). As of Γ_time=snapshot(t), a resolvable gate-status carrier (e.g., GateChecklistSnapshot#…) indicates A-PRJ-01 holds, with the referenced evidence set pinned as {DecisionRecord#…, BudgetLine#…, StaffingAssignments#…} (carrier classes as per E-PRJ-01). (Observed / pinned state; references A-PRJ-01 and E-PRJ-01; includes carrier instance(s), not just carrier classes.)

#Readable recomposition

Tech bundle:

• “Approved” is not one relation: L-PRJ-01 defines approval kinds.
• “May start execution” is a gate predicate: A-PRJ-01.
• Owner accountability: D-PRJ-01.
• Carriers and adjudication: E-PRJ-01 and observed snapshot E-PRJ-02.

Plain paragraph: “Instead of a generic ‘approved’, we select an explicit approval kind as defined in L-PRJ-01 and treat ‘may start execution’ as an admissibility gate (A-PRJ-01). The project owner is accountable for not starting execution unless that gate holds and for keeping the approval registry current (D-PRJ-01). Gate status is adjudicated using the pinned carriers listed in E-PRJ-01; as of snapshot t, the evidence indicates the gate holds (E-PRJ-02).”

#A compact “recomposition pattern” you can reuse verbatim

#Tech register (2–5 lines)

“This boundary claim is defined by L-…, is applicable only under A-…, is accountable under D-…, and is adjudicated using evidence carriers E-…. Observed status/value is E-… for Γ_time=….”

#Plain register (1 paragraph)

“We mean [short label] in the sense of L-…. It’s only meant to be used when A-… holds. [Role] is responsible for maintaining that condition (D-…). Whether it holds is checked using E-…, and the latest recorded status/value is E-….”

#A.6.B:9 — Bias‑Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for boundary descriptions.

• Arch bias: favors explicit separation and explicit references; mitigated by allowing narrative faces while keeping commitments routed and referenced by ID.
• Gov bias: makes accountability explicit (D) and auditability explicit (E); mitigated by keeping evidence conceptual and carrier‑anchored rather than tool‑specific.
• Onto/Epist bias: insists on EntityOfConcern / Description episteme / carrier and on work‑adjudicated effects; mitigated by providing clear cross‑quadrant link patterns so authors can still express real‑world governance needs.

#A.6.B:10 — Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#A.6.B:12 — Consequences

#A.6.B:13 — Rationale

The square is the smallest authoring primitive that forces an explicit choice across two distinctions that are otherwise routinely conflated:

• Truth vs governance (what is the case vs what is required/committed), and
• Description vs work (what can be decided by reading vs what must be decided by observing execution).

By requiring atomicity and explicit cross‑quadrant references, the square converts “contract talk” into a set of routed, evolvable claims with clear adjudication semantics.

#A.6.B:14 — SoTA‑Echoing (post‑2015 practice alignment)

Informative. Alignment notes; not normative requirements.

Representative sources (post‑2015; illustrative). See also A.6:11 for a fuller list.

• ISO/IEC/IEEE 42010:2022 (U.View and U.Viewpoint discipline).

• Leijen (2017) / Hillerström & Lindley (2018) (effects & handlers).

• OpenTelemetry Specification (v1.0+, 2021–) (evidence carriers as traces/logs/metrics).

• Effect systems & handlers: clear separation between operation signature (L) and handler/runtime behavior (A/E), with governance duties (D) attached to accountable operators/implementers.

• Behavioural/session typing: protocol laws (L) and admissibility (A) remain distinct from commitments (D) and runtime traces (E), improving interpretability of “progress/safety” style boundary guarantees.

• SRE/observability discipline: treating traces/logs/metrics as evidence carriers (E) and separating evidence semantics from retention/exposure duties (D) mirrors contemporary operational practice while staying tool‑agnostic.

#A.6.B:15 — Relations

• Used by A.6: supplies the canonical matrix and cross‑quadrant link discipline that A.6 references as “Boundary Discipline Matrix”.
• Constrains A.6.0 (U.Signature): enforces that L-* laws are truth‑conditional and do not include admissibility predicates.
• Constrains A.6.1 (U.Mechanism): enforces that admissibility lives in AdmissibilityConditions (A-*) and that evidence semantics are routed as E-* with carrier anchors.
• Requires A.7: anchors quadrants to EntityOfConcern, Description episteme, or publication carrier so agency and evidence are not misattributed.
• Interacts with MVPK/E.17: faces are projections that cite L/A/D/E-classified claims; faces must not mint new semantic commitments.

#Probe-coupled boundary claim routing

Probe-coupled boundary language does not create a fifth quadrant. A boundary sentence that says a question, metric, dashboard, workshop, bridge, or API read changes the represented state must still be atomized through the same L/A/D/E square.

Action path:

1. Copy the boundary sentence being used for a decision.
2. Split it into atomic claims before judging it: definition/law, admissibility/use condition, role commitment, and work/evidence effect.
3. Give each atomic claim its quadrant and identifier.
4. Put the state, probe, update, or export part in the quadrant where it belongs rather than treating "quantum-like boundary" as one claim.
5. Apply A.6.P and F.18 to reusable relation words; apply A.10 to evidence; apply B.3 to assurance; apply C.16 to measurement; apply C.26.1 to the remaining probe-coupled support load.
6. Emit a Claim Register row set or equivalent L/A/D/E-classified claim set only when the sentence is decision-bearing, reusable, contested, assurance-facing, or likely to be cited across faces.

For a local working note, the lighter action is enough: atomize the sentence mentally, write one clean L/A/D/E-classified sentence, and avoid the phrase "quantum-like boundary" as a single claim. Use the Claim Register when the L/A/D/E-classified claim set must survive reuse or dispute.

Useful outputs:

• a Claim Register row set when the boundary sentence mixes claim kinds;
• one rewritten L/A/D/E-classified sentence when the case is only a local working note;
• an ordinary A.6.B L/A/D/E-classified claim set when no QL support load remains;
• a C.26.1 route only for the remaining probe-coupled state-reading part;
• an A.10/B.3/C.16/F.9 route when evidence, assurance, measurement, or bridge work is the real entry load.

Do not write "the boundary is quantum-like" as one unL/A/D/E-classified claim. The action is: split the claim, classify the pieces, then decide whether C.26.1 still has a remaining job.

#A.6.B:End

#A.6.C — Contract Unpacking for Boundaries

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.6 Signature Stack & Boundary Discipline Builds on: A.6 (stack + routing intent), A.6.B (L/A/D/E), A.6.8 (RPR‑SERV) (service‑cluster polysemy unpacking), A.7 (EntityOfConcern / Description episteme / carrier), A.2.3 (U.PromiseContent / promise content), A.2.4 (U.EvidenceRole), A.2.8 (U.Commitment), A.2.9 (U.SpeechAct), A.15.1 (U.Work), E.10 (L‑SERV / LEX‑BUNDLE), E.17 (MVPK “no new semantics” faces), F.12 (service acceptance/evidence discipline) Lexical anchor: F.18 (NQD front for the service (promise) / utterance / commitment triad; naming, not ontology) Mint/reuse (terminology): Reuses “contract / SLA / guarantee” as Plain-level boundary shorthand; mints Contract Bundle as an unpacking lens (not a new entity kind), plus optional register columns (bundleId / bundlePart / faceRefs). NQD-front seeds (informative): contract packet, agreement bundle, boundary bundle (chosen: Contract Bundle for low collision with existing “bundle” terms). Purpose (one line): Prevent “contract soup” and agency misattribution by unpacking contract-language into distinct promise‑content, utterance package, commitment, and work+evidence (adjudication substrate) parts and routing each part into the Boundary Norm Square.

#A.6.C:1 — Problem frame

Boundary descriptions frequently use “contract” as a shorthand for “the thing that governs the interaction”. That shorthand is useful in conversation, but it collapses distinct layers that FPF deliberately keeps separate:

• Promise-level intent (what is promised to be true or provided),
• Published description (what is written and versioned),
• Deontic commitment relation (who is accountable for which obligations/permissions),
• Operational work and evidence (what actually happens and what can be observed).

When these layers are collapsed, authors accidentally assign agency to epistemes (“the interface guarantees…”), encode runtime gates as if they were internal laws, or treat observability as a property of text rather than of carriers and work. A.6 and A.6.B already provide an L/A/D/E claim-classification discipline for boundary claims, but “contract” language remains a recurring entry point for category mistakes.

Service-cluster note (modularity + lexicon). Boundary “contract talk” commonly co‑moves with the service cluster (service, service provider, server, SLA/SLO/service‑level). When those tokens appear, their referents MUST be disambiguated per A.6.8 (RPR‑SERV) before (or while) applying the four‑part Contract Bundle below. In particular, U.PromiseContent is promise content and is written in normative prose as promise content (not as bare “service”).

A.6.C makes contract-language usable inside the A.6 stack by providing a canonical unpacking that can be applied to APIs, hardware interfaces, protocols, and socio-technical boundaries.

Non‑goals (to preserve modularity). A.6.C does not:

• define “legal contract” doctrine (offer/acceptance/consideration, jurisdictional enforceability, etc.);
• resolve conflicts between incompatible commitments across scales or contexts (capture them as separate D-* claims and apply conflict or mediation patterns when they exist);
• redefine the core meanings of U.PromiseContent, U.Work, U.SpeechAct, or U.Commitment—it only makes “contract talk” routable into those objects/claims.
• redefine quadrant semantics (L/A/D/E) or cross‑quadrant reference rules; those are defined normatively in A.6.B.

#A.6.C:2 — Problem

How can an author write (or repair) contract-language so that:

1. Agency is not misattributed to descriptions (signatures, docs, specs, “interfaces”),
2. Governance statements (obligations/commitments) are distinguishable from admissibility gates and from semantic laws,
3. Operational “guarantees” become adjudicable via explicit evidence expectations, without smuggling evidence into semantics,
4. Multi-view publication (MVPK faces) does not create parallel Contract Bundles or rival canonical claim sets by paraphrase drift?

#A.6.C:3 — Forces

#A.6.C:4 — Solution

A.6.C introduces a Contract Bundle lens for boundary writing. It is not a new foundational entity kind; it is a disciplined way to interpret and rewrite contract-language under A.6.B.

#A.6.C:4.1 — The Contract Bundle (four-part unpacking)

Whenever a text uses “contract / guarantee / promise / SLA / interface agreement” language, unpack it into four parts:

1. Promise Content (Promise content)

   • The promised value/effect (the promise content) in the intended scope.

• In FPF terms (A.2.3), U.PromiseContent is promise content—a promise content, not an execution event (U.Work) and not (by itself) an accountable deontic binding (U.Commitment).
• Prose head rule (normative). When referring to U.PromiseContent in normative prose, authors SHALL use the head phrase promise content (or service offering clause or service promise clause) and SHALL NOT rely on the bare head noun service. If the surrounding text also talks about endpoints/systems/operations, apply A.6.8 to select facet‑typed phrases (service access point, service delivery system, service delivery work, and so on) rather than collapsing them into “service”.
  • Recommendation: give the promise-content a stable local ID (e.g., SVC-*) so it can be cited from commitments, gates, evidence, and MVPK faces without paraphrase drift.
• Routing discipline: keep the semantics/definitions of the promised behavior in L; express who is accountable for satisfying the promise as a D claim (U.Commitment) that references the U.PromiseContent (plus any A-*/E-* claims as needed).

2. Utterance Package (speech act + published descriptions)

   • The work occurrence of stating/publishing/approving (a U.SpeechAct <: U.Work, A.2.9) and the utterance descriptions it produces or updates (versioned epistemes on carriers) that carry the L/A/D/E-classified claim set.
   • A speech act may institute/update commitments, but only under an explicit context policy that recognizes that actType as having such institutional force.
   • The published utterance descriptions (signature/mechanism spec + MVPK faces) carry L/A/D/E-classified claims. The act is not “the contract”; it is the work occurrence that created/updated the descriptions and (when recognized) the associated commitments.
   • Default interpretation rule (normative). A conformant boundary model MUST NOT infer or assume any U.Commitment objects solely from the presence of a Publish/Approve U.SpeechAct. Publication creates/updates utterance descriptions and MAY institute publication/status claims (e.g., “Published”, “Approved as Standard”, “Deprecated”), but commitments exist only when represented explicitly as U.Commitment records (A.2.8).
   • If a bounded context defines a policy that maps certain publish/approve act types to commitment-instituting effects (e.g., a named SpecPublicationPolicy@Context), the model MUST cite that policy, and any resulting commitments MUST still be represented explicitly as one or more U.Commitment objects with accountable subjects (not inferred from publication alone).

3. Commitment (Deontic accountability relation)

   • The accountable U.Agent or U.Role bound to obligations, permissions, and prohibitions (including being accountable for satisfying a promise content).
   • This bundle part is the D‑side commitment object: by default, one or more U.Commitment records (A.2.8).
   • Default checklist (A.2.8 minimal structure):
     • id (stable; often the D-* claim ID),
     • subject (accountable role/party; never an episteme),
     • modality (normalized deontic token / BCP‑14 family),
     • scope (U.ClaimScope) and validityWindow (U.QualificationWindow),
     • referents (by reference/ID: promise content IDs like SVC-*, plus L-*/A-*/MethodDescriptionRef(...)/ServiceRef(...) as needed),
   • referents (by reference/ID: promise content IDs like SVC-*, plus L-*/A-*/MethodDescriptionRef(...)/PromiseContentRef(...) as needed),
     • optional owedTo (beneficiary/counterparty),
     • optional adjudication.evidenceRefs when the commitment is meant to be auditable (point to E-*),
     • optional source when authority/provenance matters (issuer + instituting speechActRef + description reference),
     • optional notes for explicitly informative commentary (not part of the binding).
   • A commitment is not “the spec text”: utterance descriptions carry the statement, but the binding is the U.Commitment object (A.7 / A.2.8).

4. Work + Evidence (Adjudication substrate)

   • The executed work and the observable carriers/traces that can adjudicate whether a commitment was met.
   • This is E quadrant: “what evidence is produced/exposed/retained, under what conditions, and how it is interpreted”.
   • Work is not “the contract”; it is what makes any operational claim testable.
   • In FPF terms, evidence is normally expressed as carrier‑anchored E-* claims (often backed by U.EvidenceRole assignments on epistemes with provenance from Work).

#A.6.C:4.2 — Routing recipe into A.6.B (L/A/D/E)

After unpacking, route each atomic statement using the Boundary Norm Square as defined normatively in A.6.B (quadrant semantics + form constraints + cross‑quadrant reference discipline). A.6.C does not redefine L/A/D/E; it applies them to contract-language as follows:

• Promise content → L/A (promise semantics + eligibility).
  • Put meanings, invariants, and metric definitions for what is promised in L (L-* in signature laws/definitions).
  • Put “eligible/covered/valid iff …” predicates as A (A-* admissibility/gate predicates), not as deontic obligations.
• Commitment → D (who is accountable).
  • Put “MUST/SHALL/commits to …” statements as D (D-*), preferably as U.Commitment payloads (A.2.8).
  • If compliance requires satisfying/enforcing a gate, the commitment MUST reference the relevant A-* ID(s) (D→A).
  • If the commitment is meant to be auditable, include evidence hooks by referencing E-* (D→E), preferably via U.Commitment.adjudication.evidenceRefs.
• Work + Evidence → E (how we can tell).
  • Put observable traces, audit records, measurement windows, and carrier semantics as E (E-*) with explicit carrier and observation/measurement conditions (A.6.B:5.4). Keyword placement rule (canonical claim set). Within the canonical L/A/D/E-classified claim set, BCP‑14 norm keywords (RFC 2119 + RFC 8174)—and their common synonyms (e.g., SHALL, REQUIRED, RECOMMENDED, OPTIONAL)—belong in D claims only, expressed as U.Commitment.modality and normalized per A.2.8. Authors SHOULD avoid using these keywords in L/A/E claims; phrase L as definitions/invariants (“is defined as…”, “holds iff…”), A as predicates (“is admissible iff…”), and E as observable/evidenced properties. If a BCP‑14 keyword (or synonym) appears in an L/A/E claim, it SHOULD be rewritten into predicate/definition form (or explicitly marked informative) before publication.

A helpful rewrite rule:

If a sentence mixes “when allowed” + “who must comply” + “how we can tell”, decompose it into an A predicate, a D duty referencing that predicate, and an E evidence claim referencing that predicate (per A.6.B triangle decomposition).

#A.6.C:4.3 — “Guarantee” disambiguation

Treat “guarantee” as ambiguous until routed:

• Semantic guarantee → L (“by definition / invariant”).
• Governance guarantee → D (“provider commits / implementer must”).
• Operational guarantee → E (measured property with evidence expectations; optionally referenced by D as the adjudication target).

If none of these fits, the statement is likely rhetorical and should be rewritten or explicitly marked as aspirational/informative.

#A.6.C:4.4 — MVPK faces are not second contracts

A contract bundle has one canonical claim set. Publication faces are views of that set under viewpoints:

• Faces may select, summarize, and render claims for audiences.
• Faces must not introduce new semantic commitments beyond the underlying claim set.
• Any face-level decision-relevant / normative-looking statement SHOULD cite the underlying claim ID(s). If it cannot be traced to claim IDs, it MUST be explicitly presented as informative commentary.

Keyword rule (faces). If a face contains BCP‑14 norm keywords (RFC 2119 + RFC 8174), including common synonyms (SHALL, REQUIRED, RECOMMENDED, OPTIONAL), then each such sentence MUST be a projection of an existing D‑* claim (U.Commitment) and MUST cite the underlying D claim ID(s). If a sentence cannot be traced to D‑* claim IDs, it MUST be rewritten to remove BCP‑14 keywords (e.g., turn it into explanatory prose that cites the relevant claim IDs) or moved out of the face. To avoid keyword‑evasion, equivalent deontic phrasings (e.g., “is required to…”, “is prohibited from…”) SHOULD follow the same trace-by-ID discipline even when no BCP‑14 keyword is present.

Projection may be paraphrased for audience fit, but it MUST NOT change the deontic or semantic claim; if exactness is critical or disputed, use verbatim.

This prevents faces from becoming “second contracts” by paraphrase drift.

#A.6.C:4.5 — Default register: Contract Claim Register (recommended)

Use the A.6.B Claim Register (IDs + statements + quadrant + anchor). Add two optional columns that make A.6.C auditable without adding new ontology:

• bundleId: ContractBundleId (local stable ID grouping the claims that constitute one boundary “contract bundle”)
• bundlePart ∈ {PromiseContent, Utterance, Commitment, WorkEvidence}
• faceRefs = {PlainView|TechCard|InteropCard|AssuranceLane : …} (where the claim is rendered)

#A.6.C:5 — Archetypal Grounding (Tell–Show–Show)

#A.6.C:5.1 — Tell

If you use contract-language for a boundary, do not treat “the interface/spec” as an agent. Instead:

1. Identify the promise content (promise content) being promised,
2. Identify the accountable Commitment holder(s) (roles/agents),
3. Identify the Utterance surfaces that publish the boundary (signature/mechanism + MVPK views),
4. Identify the Work + Evidence carriers that could adjudicate whether commitments were met,
5. Route each claim through L/A/D/E and reference across quadrants rather than paraphrasing.

#A.6.C:5.2 — Show (System archetypes)

(A) Software API boundary

Draft wording (contract soup): “The Payments API guarantees idempotency. Clients must provide Idempotency-Key. We log all requests. Availability is 99.9%.”

Unpack + route:

• Utterance: signature/mechanism publication for PaymentsAPI (MVPK faces: TechCard, InteropCard).
• L: define idempotency and the uniqueness semantics of Idempotency-Key. (“Idempotent” is a semantic property, not a duty.)
• A: admissibility predicate: request is admissible iff Idempotency-Key is present and valid. (Gate belongs to mechanism.)
• D: client implementers are obligated to satisfy the gate; provider implementers are accountable for the idempotency behavior as defined in L when the gate holds; provider commits to the availability target (scoped by window/exclusions). (Name the committing role; do not say “the API commits”.)
• E: evidence expectations: audit/log carriers include request id, idempotency key, rejection reason; availability measurement uses defined window and signal definition.

(B) Hardware interface boundary

Draft wording: “The connector guarantees safe operation. Devices must not exceed 20V. Negotiation must succeed before power is applied.”

Unpack + route:

• Utterance: published interface spec (pinout, electrical ranges, handshake procedure).
• L: electrical invariants / allowable ranges are definitions and invariants (truth-conditional).
• A: admissibility predicate: power delivery is admissible only after handshake state reaches an agreed mode.
• D: manufacturer/integrator obligations: implement handshake; enforce voltage constraints.
• E: evidence: test-report carriers; measurement traces; observable negotiation logs (if exposed), or lab measurements under a declared method.

#A.6.C:5.3 — Show (Episteme archetypes)

(C) Multiparty protocol boundary (behavioural/session type motif)

Draft wording: “The protocol guarantees progress. Participants must follow the sequence.”

Unpack + route:

• Utterance: protocol description (could be a type/protocol spec plus explanatory views).
• L: safety/progress properties as laws over the protocol model (truth-conditional, within the theory).
• A: admissibility: when an interaction trace is considered valid/admissible (e.g., runtime checks; compilation checks; gating conditions for entering a session).
• D: obligations on implementers/operators: implement the protocol; do not send messages outside the allowed state machine; publish conformance records if required.
• E: evidence: message trace carriers, conformance test-run records, and audit trails for disputed interactions.

(D) Socio-technical “SLA + audit trail” boundary

Draft wording: “Provider shall respond within 4 hours for Severity‑1 incidents. Only Severity‑1 is covered. Evidence is provided by ticket logs.”

Unpack + route:

• Promise content (service promise clause): responsiveness promise for a defined incident class and window.
• Utterance: SLA publication (and its views for different audiences).
• A: admissibility predicate for the promise: ticket qualifies iff severity classification meets stated conditions.
• D: provider commitment to meet the target; client duties (e.g., provide required info); auditor duties if applicable.
• E: evidence: ticket carriers, timestamps, classification records, and the measurement procedure binding “4 hours” to a time window and clock source.

#A.6.C:6 — Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for “contract talk” in boundary descriptions.

• Gov bias: prefers explicit accountability and adjudication hooks; increases clarity but adds authoring overhead.
• Arch bias: optimises evolvability by preventing hidden coupling (contract soup) across stack layers.
• Onto/Epist bias: enforces EntityOfConcern / Description episteme / carrier separation; discourages “interface-as-agent” metaphors in Tech prose.
• Prag bias: accepts that “contract” is common vocabulary; offers a disciplined rewrite rather than prohibition.
• Did bias: aims to be teachable via repeated unpacking examples across boundary types.

#A.6.C:7 — Conformance Checklist

A boundary description conforms to A.6.C iff it satisfies all items below:

1. CC‑A.6.C‑1 (Unpacking when contract-language appears). If the text uses “contract/guarantee/promise/SLA” language, it SHALL explicitly disambiguate the statement as referring to at least one of: Promise content (promise content), Utterance (published description), Commitment (deontic binding), Work+Evidence (adjudication).

2. CC‑A.6.C‑2 (No agency to epistemes). The text MUST NOT attribute promising/committing/obligating agency to signatures, mechanisms, interfaces, or documents. Any duty/commitment SHALL name an accountable U.Role or U.Agent.

3. CC‑A.6.C‑3 (Route contract-language statements via A.6.B). Contract-language statements SHALL be routable as atomic claims to L/A/D/E, with dependencies expressed by explicit references rather than paraphrase.

4. CC‑A.6.C‑4 (Promise content ≠ Work discipline). Statements about what is executed/observed SHALL be expressed as E claims about work/evidence/carriers. Promise‑content language SHALL refer to the promise content (U.PromiseContent, A.2.3) and its L‑defined semantics (and to explicit D‑* commitments represented as U.Commitment, A.2.8), not to execution events (U.Work) or runtime effects. Unqualified head‑noun service (and the co‑moving cluster service provider / server) in normative boundary prose SHALL be unpacked per A.6.8 (RPR‑SERV).

5. CC‑A.6.C‑5 (Evidence hook for operational guarantees). If a “guarantee” is operational (requires reality to decide), the text SHALL include an E claim that states what evidence would adjudicate it (even if the evidence surface is abstract/conceptual).

6. CC‑A.6.C‑6 (No second contracts via faces). MVPK faces MUST NOT add new commitments beyond the underlying L/A/D/E-classified claims; faces may only project/summarize/select from the canonical claim set under a viewpoint.

7. CC‑A.6.C‑7 (RFC‑keyword discipline inside faces). If an MVPK face contains BCP‑14 norm keywords, each BCP‑14 sentence MUST cite the underlying D‑* claim ID(s) (U.Commitment) it is projecting. If it cannot, the face is non‑conformant until rewritten (no BCP‑14 keyword) or moved out of the face.

8. CC‑A.6.C‑8 (No commitment-by-publication default). A Publish/Approve utterance (including publishing a …Spec) MUST NOT be treated as instituting U.Commitment objects by default. If a Context policy maps publication acts to binding effects, the policy SHALL be cited, and any resulting bindings SHALL still be represented explicitly as U.Commitment objects with accountable subjects.

#A.6.C:8 — Common Anti-Patterns and How to Avoid Them

#A.6.C:9 — Consequences

Benefits

• Category mistakes (“contract soup”) become systematically repairable.
• Commitments become accountable (named roles) and adjudicable (evidence expectations).
• Boundaries remain evolvable: laws, gates, governance, and evidence can evolve with controlled coupling.

Trade-offs / mitigations

• Additional authoring effort; mitigated by applying the unpacking only when contract-language appears or when a claim is used for decision/publication.
• Some stakeholders prefer “one sentence contract”; mitigated by MVPK faces that present curated projections while keeping the underlying claim set coherent.

#A.6.C:10 — Rationale

FPF already distinguishes signatures, mechanisms, and work/evidence layers. Contract-language is a high-frequency linguistic entry point that collapses these layers unless a disciplined unpacking is applied.

F.18 provides the naming intuition (service/promise vs utterance vs commitment) via an NQD example; A.6.C makes that split operational for boundaries and extends it with the missing fourth part: work+evidence as the adjudication substrate. This keeps “contract” language routable under A.6.B and compatible with MVPK multi‑view discipline without relocating ontology into the naming chapter.

#A.6.C:11 — SoTA‑Echoing (informative; post‑2015 alignment)

Informative. Alignment notes; not normative requirements.

• Adopt — BCP 14 (RFC 2119 + RFC 8174) norm keyword discipline for spec language. Modern spec-writing practice treats these keywords as a disciplined modality family; A.6.C constrains where such modality belongs (D) versus where predicate-style constraints belong (A/L).
• Adopt — behavioural/session types for protocol boundaries (post‑2015 practice). Protocols as typed interactions emphasize separating safety/progress properties (L) from runtime admission (A) and from implementer obligations (D), with trace-based evidence (E).
• Adopt/Adapt — algebraic effects & handlers / effect systems. The “operation signature vs handler semantics” split mirrors “utterance substrate vs work/evidence”, preventing execution semantics from being conflated with governing spec refs.
• Adapt — ISO/IEC/IEEE 42010:2022 viewpoint discipline. Multi-view publication is treated as viewpoints governing projections; A.6.C applies this to contract talk to avoid face-level semantic forks.

#A.6.C:12 — Relations

• Uses / is used by

  • Uses A.6.B for L/A/D/E claim classification, atomicity, and cross-quadrant reference discipline.
  • Used by A.6 cluster conformance (“contract unpacking”) as the detailed, reusable form of that discipline.
  • Complements A.6.S (signature engineering): contract unpacking is a common constructor step when turning prose boundaries into publishable signatures.
  • Coordinates with A.6.P families: when an RPR pattern touches “contract/guarantee” language, apply A.6.C to avoid category errors. (A.6.C is not a specialization of A.6.P; A.6.P is relation‑precision, A.6.C is boundary‑contract disambiguation.)

• Coordinates with

  • A.7 (EntityOfConcern / Description episteme / carrier) for correct placement of evidence claims.
  • F.12 (service acceptance) for structuring how promise-level commitments connect to evidence and acceptance windows.
  • E.17 MVPK “no new semantics” rule to prevent publication faces from becoming new contracts.

#A.6.C:End

#U.Signature - Universal, law‑governed declaration for a SubjectKind on a BaseType

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 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 aliases are mapped 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 aliases). — 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 (alias: NoReferencePlaneOnPF) and UNM‑priority (units, planes, comparators, and Transport are declared only by U.ContextNormalization and cited by edition or ref-id where needed).

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 on the principled path; 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

#U.Mechanism - Law‑governed application to a SubjectKind over a BaseType

One-line summary. A U.Mechanism is a specialisation of U.Signature (A.6.0): its Vocabulary is an explicit OperationAlgebra whose operators publish SlotSpecs (A.6.5), its Laws are a LawSet, and it adds AdmissibilityConditions (operational guards) plus a named Transport clause for cross-context use. Transport is Bridge-only (per F.9) with penalties recorded only in the Reliability channel (R, or R_eff when distinguished) (per B.3); F and G remain invariant; CL^plane follows C.2.1 CHR:ReferencePlane. Realizations MAY be published, but MUST be monotone with respect to the Mechanism’s LawSet and any imported Signature laws and MUST treat imported signatures as opaque by using imports, provides, and ClaimIds.

Status. Normative [A] in Part A (Kernel).

Placement. Immediately after A.6.0 as A.6.1. USM (A.2.6) and UNM (A.19 and C.16) become instances conforming to A.6.1 (no semantic change to either).

Mint vs reuse. This pattern mints the Kernel lexemes U.Mechanism, U.MechMorph, and U.MechanismDeclarationTemplate, plus the descriptive record names MechanismDescription, MechFamilyDescription, and MechInstanceDescription. It reuses U.Signature (A.6.0), U.Type, U.BoundedContext, and Part F Bridge, CL, and ReferencePlane terms without changing them; it does not mint new U.Type core types.

Type. Architectural pattern (kernel‑level; notation‑independent).

LEX.TokenClass (E.10). Declared here for the tokens minted by this pattern (see E.10:7.1).

• LEX.TokenClass(U.Mechanism) = KernelToken
• LEX.TokenClass(U.MechMorph) = KernelToken
• LEX.TokenClass(U.MechanismDeclarationTemplate) = KernelToken
• LEX.TokenClass(MechanismDescription) = KernelToken
• LEX.TokenClass(MechFamilyDescription) = KernelToken
• LEX.TokenClass(MechInstanceDescription) = KernelToken

#Use and boundary

Use this pattern when a reusable declaration has to do more than name a signature: it must declare a law-governed operation algebra, operational admissibility predicates, context-local applicability, and explicit cross-context or cross-plane Transport for a U.Mechanism.

Do not use this pattern when the claim being made is only a reusable declaration with no operational guards; use A.6.0. Do not use it to authorize work, pass a gate, certify evidence, choose a method, publish telemetry, or prove a result. Those claims use the work, gate, evidence, method, publication, or result patterns that cite the mechanism when needed.

First useful move: write the mechanism declaration as a specialization of the four-row A.6.0 Signature Block, then add only the mechanism-specific fields: OperationAlgebra, LawSet, AdmissibilityConditions, Transport, Γ_timePolicy, PlaneRegime, and Audit. If cross-context use is live, name the Bridge and the Reliability penalty relation before any reuse claim is made.

What goes wrong if missed: an implementation recipe, a policy rule, a telemetry package, or a cross-context reuse habit can masquerade as mechanism law. Downstream work then cannot tell which operations are lawful, which admissibility predicates fail closed, and which losses affect Reliability rather than Formality or Guarantee.

What this buys: USM, UNM, selection mechanisms, normalization mechanisms, scoring mechanisms, and publication mechanisms can be compared, refined, extended, transported, and realized without hiding law, guard, time, plane, or Reliability assumptions.

#Problem frame

Give FPF one uniform kernel shape for things like USM (set-algebra on context slices) and UNM (classes of admissible normalizations with ≡_UNM) so practitioners can define, compare, refine, compose, and port mechanisms without re-inventing the mechanism language; all cross-context use is Bridge-only with CL penalties recorded in R or R_eff, never in F or G.

#Problem

Without a kernel abstraction, scope, normalization, and comparison constructs proliferate with incompatible algebras and guard predicates; cross-context reuse lacks a visible Bridge and CL penalty relation; comparability drifts into illegal scalarisation (e.g., ordinal means). FPF already curbs this via A.6.0 (Signature discipline, SignatureManifest), USM (scope algebra and Γ_time), UNM (normalize-then-compare), and CG-Spec (lawful comparators and ScoringMethods), but lacks a common kernel kind for “mechanism.”

#Forces

Locality vs transport. Semantics are context-local; crossing contexts is Bridge-only (Part F and B.3); penalties are recorded in R or R_eff; F and G stay invariant.

Expressivity vs legality. Rich operators must stay inside CHR legality and CG-Spec constraints: no ordinal averages and no cross-unit arithmetic without lawful unit alignment.

Time determinacy. Explicit Γ_time; no implicit latest. (Required in USM’s ContextSlice.)

Slot clarity vs specialisation depth. Multi‑level specialisations require explicit SlotSpecs (A.6.5) and monotone refinement of ValueKinds; SlotKinds are stable across levels (no implicit positional parameters).

Signature hygiene. Obey SignatureManifest discipline (A.6.0:4.4.1): explicit imports and provides, acyclic imports, and no redeclare. Treat imported signatures as opaque: reference only their provides symbols and ClaimIds, and keep realizations monotone.

#Solution

#Mechanism Declaration

A U.Mechanism publishes MechanismDeclaration := ⟨DeclarationHeader, Imports, SubjectBlock := ⟨SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?⟩, SlotIndex, OperationAlgebra, LawSet, AdmissibilityConditions, Applicability, Transport, Γ_timePolicy, PlaneRegime, Audit⟩ and admits Realizations that respect it. The shape is notation‑independent and conceptual (no tooling, storage, or CI metadata).

• A.6.0 alignment (normative). U.Mechanism is a specialisation of U.Signature (A.6.0). A mechanism publication SHALL include the universal four-row Signature Block (SubjectBlock, Vocabulary, Laws, Applicability). The canonical mapping is: – SubjectBlock ↔ SubjectBlock – Vocabulary ↔ OperationAlgebra (including inline SlotSpecs per A.6.0:4.1.1 and A.6.5) – Laws ↔ LawSet – Applicability ↔ Applicability SlotIndex is a mechanism-only index projection over SlotSpecs used by OperationAlgebra and any extra SlotSpecs used only by AdmissibilityConditions; it does not introduce a fifth Signature row and does not relax A.6.0:4.1.1. Mechanism-only additions are AdmissibilityConditions, Transport, Γ_timePolicy, PlaneRegime, and Audit; they extend the Signature without contradicting the A.6.0 separation between declaration and realization.

• DeclarationHeader. id (PascalCase), version (SemVer), publicationState (draft, candidate, stable, or deprecated). SignatureManifest coupling (normative). If the mechanism is intended to be imported or reused, it MUST include a SignatureManifest (A.6.0:4.4.1) immediately above its Signature Block. When both are present: – DeclarationHeader.id = SignatureManifest.id – DeclarationHeader.version = SignatureManifest.version – DeclarationHeader.publicationState = SignatureManifest.publicationState (when publicationState is present) – Imports = SignatureManifest.imports and any public symbols minted by the Mechanism’s Signature Block MUST appear in SignatureManifest.provides. Avoid duplicating imports and provides elsewhere: dependency edges and exported names live in the manifest; operational details live in the mechanism.

• Imports. (Optional) SignatureIds that supply non-Kernel symbols used by this mechanism’s Signature Block or this mechanism’s operation algebra. If the mechanism includes a SignatureManifest, then Imports MUST equal SignatureManifest.imports. If present, the list MUST be acyclic and MUST respect the stratum dependency rule in A.6.0:4.4.1 (E.5.3 and E.10).

• BaseType. A U.Type the mechanism ranges over. CHR spaces (e.g., a U.CharacteristicSpace or chart family) appear here as types; outside CHR, use set-typed U.Types. A conformant U.Mechanism publication MUST NOT mint a new core type here; it MUST reference existing U.Types. If planes differ, state the ReferencePlane policy (see PlaneRegime).

• SubjectKind, SliceSet, ExtentRule, ResultKind?, and SlotIndex. • SubjectKind. The EntityOfConcern kind acted upon (C.3.1 and C.3.2), separate from quantification. • SliceSet. The addressable set of Context slices (USM: ContextSliceSet). • ExtentRule. A rule yielding Extension(SubjectKind, slice) (C.3.2), used as the quantifier’s domain. • ResultKind? Optional output kind for outputs of OperationAlgebra. • SlotIndex. A set of SlotSpecs SlotSpec = ⟨SlotKind, ValueKind, refMode⟩ (A.6.0:4.1.1; A.6.5) covering every argument position used by OperationAlgebra and AdmissibilityConditions. SlotKinds are stable names for substitution and specialisation; parameter names and numeric indices are presentation only. For Vocabulary-level operators, SlotSpecs remain declared in each operator’s parameter block (A.6.0:4.1.1). SlotIndex is an extracted index that MUST be mechanically derivable from those declarations (plus any guard-only SlotSpecs). Guard-only SlotSpecs SHALL be declared as part of the AdmissibilityConditions predicate signatures (not only as prose) so they remain mechanically extractable. Shorthand views (didactic only). A mechanism publication MAY include a simple name-to-ValueKind list (a ValueKindView) as a didactic projection of SlotSpecs, but it SHALL NOT replace SlotSpecs (SlotKind, ValueKind, refMode) in normative Mechanism definitions. If present, it MUST be mechanically derivable from SlotIndex (e.g., ValueKindView = π_value(SlotIndex) by dropping refMode). The colloquial label ParamKind is permitted only in prose as a synonym for the ValueKind component of a SlotSpec; it MUST NOT be introduced as a field name, token, or type.

• OperationAlgebra. Named operations whose signatures are expressed over SlotKinds from SlotIndex (A.6.5); no implicit parameters. For every n‑ary operator, its Vocabulary declaration SHALL publish SlotSpec triples per argument position (A.6.0:4.1.1); positional indices are presentation only. Examples: • USM: ∈, ⊆, ∩, SpanUnion, translate, widen, narrow, refit. • UNM: apply(method), compose, quotient(≡_UNM); normalize‑then‑compare.

• LawSet. Equations and invariants (no proofs here). Admission and eligibility tests belong under AdmissibilityConditions, not here. Laws MUST be compatible with CHR legality where numeric comparison or aggregation is induced. Examples: • USM: serial intersection; SpanUnion only where a named independence assumption is satisfied (state features or characteristics, validity window, evidence class); translate uses declared Bridges; Γ_time is mandatory. • UNM: scale‑appropriate transforms — ratio→positive‑scalar; interval→affine; ordinal→monotone; nominal→categorical; tabular:LUT(+uncertainty). (A conformant U.Mechanism publication MUST NOT mint a new Kernel token for “certificate” inside the mechanism definition. Any needed Kernel token requires an accepted FPF naming and kind decision under E.10 and F.18.)

• AdmissibilityConditions. Deterministic, context-local operational guard predicates that fail closed (e.g., “Scope covers TargetSlice” with named Γ_time; “NormalizationMethod class + validity window named”). Predicate arguments SHALL be declared via SlotSpecs from SlotIndex (A.6.5), not as implicit positional parameters. Unknowns → {degrade, abstain}; never coerce to 0 or false.

• Applicability. Binding to a U.BoundedContext with stance, plane, time notes, and any CG-Spec and MM-CHR legality claims; cross-context use is declared via Transport only.

• Transport. Bridge-only semantics for cross-context or cross-plane use: name the Bridge and channel (Scope or Kind) per F.9, and record ReferencePlane(src,tgt) per C.2.1. Terminology: this Transport clause is a declarative policy surface; it does not introduce a U.Transfer edge (see E.18 term separation). The Transport clause MUST NOT restate CL, CL^plane, Φ, or Ψ policy tables; it MUST reference the applicable policy ids or registries instead; penalties are recorded in R or R_eff only and never mutate F or G (per B.3). Crossings are explicit; no implicit crossings. Where USM and KindBridge are used together, apply the two-bridge rule: scope CL and kind CL^k penalties are handled separately in the Reliability channel (R or R_eff).

• Γ_timePolicy. Point, window, or policy; no implicit “latest.” Validity windows are named; required whenever guards reference time.

• PlaneRegime. Declare ReferencePlane on values or paths; when planes differ, name CL^plane and apply a Φ_plane policy (Part F and B.3). Plane penalties do not change CL; record them in R or R_eff only; F and G stay invariant.

• Audit. Conceptual audit surface only (no data or telemetry workflow): crossings are publishable on UTS; cite policy-ids rather than copying policy tables. Edition pins and regression hooks, if any, are referenced by id; operational details remain out of scope.

• SignatureBlock alignment. The referenced Signature’s four‑row Block (A.6.0) is canonical. Any mechanism rendering MUST preserve that block (or an explicit projection of it) and MUST obey A.6.5 for n‑ary argument discipline. SlotKinds and SlotSpecs in SlotIndex remain part of the Vocabulary row (A.6.0) and MUST obey A.6.5.

• Compatibility with A.6.* A.6.1 is a strict specialisation of A.6.0: the canonical four-row Signature Block remains the declaration locus; additional Mechanism fields must not introduce new semantic rows or shadow the signature's imports and provides.

#U.MechMorph - Refinement, Extension, Equivalence, and Composition

Intent. Provide structure-preserving relations and constructors between mechanisms. Definitions.

• Refinement M′ ⊑ M: narrows the SubjectBlock or SlotSpecs (ValueKind or refMode for inherited SlotKinds) and strengthens LawSet or AdmissibilityConditions (safe substitution; Liskov-style). A Refinement MUST NOT rename SlotKinds or add new required arguments to inherited operations.

• Extension M ⊑⁺ M″: adds operations and any new SlotKinds used only by those new operations without weakening existing Laws or Guards; old programs remain valid (conservative extension).

• Equivalence M ≡ M′: there exists a bijective mapping between Subjects and operations preserving and reflecting LawSet (up-to-isomorphism on BaseType and OperationAlgebra).

• Quotient M by ≈: factor by a congruence (e.g., ≡_UNM for charts).

• Product M×N: independent BaseTypes; ops are component‑wise; ensures no illegal cross‑ops (e.g., set‑algebra discipline for SpanUnion). Where independence is claimed, name and justify the assumption (do not mint new Kernel types here).

#Specialisation relation chains (normative)

Many families need a generic mechanism at the top (e.g., “select anything”) and progressively specialised mechanisms below (e.g., “select a method by decision theory”, “select a telemetry pack”). To keep such specialisation chains modular and to prevent leakage across the chain:

1. Explicit parent + morphism kind. Any mechanism that specialises another MUST name its parent and declare whether the step is a Refinement (⊑) or an Extension (⊑⁺). A specialisation family MUST be acyclic (a DAG).

2. SlotKind invariance across levels. For every inherited operation or guard predicate, SlotKinds are invariant (A.6.5). A specialisation step MUST NOT rename an inherited SlotKind, change its documented semantics, or rely on positional re-ordering instead of SlotKind identity.

3. ValueKind monotonicity. A Refinement MAY narrow ValueKind (i.e., ValueKind′ ⊑ ValueKind in Kind-CAL) or refMode for an inherited SlotKind, and MAY strengthen Laws or Guards. It MUST NOT widen ValueKinds or relax Guards; otherwise mint a new parent mechanism or publish an adapter mechanism.

4. No new mandatory inputs to inherited operations. If a specialisation needs extra inputs, it MUST introduce a new operation (Extension) or an adapter mechanism; it MUST NOT retrofit new required parameters into an inherited operation signature.

5. No upward leakage. A root mechanism in a specialisation chain SHOULD mention only the most general ValueKinds required by its SlotSpecs and Laws. Domain-specific policies, generators, and evaluation packs belong in specialised mechanisms that refine slots or add operations.

Informative selector specialisation-chain sketch. SelectorMechanism can declare a stable slot interface (CandidateSetSlot, ComparisonResultSlot, CriteriaSlot, ContextSlot, SelectionSlot) with generic ValueKinds. SelectorMethodMechanism ⊑ SelectorMechanism then narrows CandidateSetSlot.ValueKind to U.Method and, by Extension, adds decision-theory specific slots and operations; an OEE generator is declared as a separate mechanism that produces candidate and criteria packs consumed by the selector. Transport Bridge⋅M: lifts across Contexts or planes; names CL, CL^k, and CL^plane regimes; penalties are recorded in R_eff only; a UTS row may publish the crossing; ReferencePlane(src,tgt) is recorded. If mapping losses are material, narrow the mapped set or publish an adapter.

Passing example. USM′ = USM + “publish named independence‑assumption evidence for SpanUnion” ⇒ Refinement (strengthened law; substitution‑safe). Normalization quotient. UNM quotiented by ≡_UNM exposes compare-on-invariants surfaces for CPM and USCM (normalize-then-compare).

#U.MechanismDeclarationTemplate - Instantiation Template

MechanismDescription (E.8 Tell–Show–Show; strict-distinction-compliant): Mechanism: U.<Name> (Kernel conceptual description; no tooling fields) Imports: <Signatures and U.Types> - SubjectBlock: <SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?> - SlotSpecs: <SlotIndex (A.6.5)> - OperationAlgebra: <operators with SlotKinds> - LawSet: <equations and invariants> - AdmissibilityConditions: <admission predicates with SlotKinds; Γ_time> - Transport: <Bridge channels; CL, CL^k, and CL^plane named; ReferencePlane(src,tgt)> - PlaneRegime: <world, concept, or episteme rules>

#MechFamilyDescription and MechInstanceDescription

• MechFamilyDescription: {MechanismDeclaration, Realizationα, Realizationβ, …} — each Realization may tighten and must never relax Laws (Liskov-style).

• MechInstanceDescription: {MechanismDeclaration@Context, Windows, named Φ, Ψ, and Φ_plane regimes, BridgeIds} — a conceptual instance; operational telemetry workflows are out of scope.

#Defaults

• Local‑first semantics. All judgments are context‑local; crossings are explicit and costed (CL→R only).
• Compliance-first comparability. Numeric comparison or aggregation requires CG-Spec (lawful SCP, Γ-fold, MinimalEvidence); partial orders return sets; no ordinal means.
• Tri-state discipline. unknown → {degrade, abstain}; sandbox and probe-only are LOG branches with policy-ids (no implicit unknown→0 and no implicit unknown→false).
• R-only penalties. Φ, Ψ, and Φ_plane are monotone and bounded; penalties are recorded in R_eff only; F and G stay invariant.

#Born‑via‑A.6.1 sketch (informative)

PTM — Publication and Telemetry Mechanism (informative) BaseType: SoTA-Pack(Core), PathId, PathSliceId, PolicyId. OperationAlgebra: emit selector-ready packs with parity pins and telemetry stubs; listen for edition or illumination bumps; trigger slice-scoped refresh. LawSet: no change of dominance defaults unless CAL policy promotes; edition-aware refresh. Guards: GateCrossing visibility harness blocks publication on missing crossing attestations (BridgeCard plus UTS row, ReferencePlane, CL, CL^k, CL^plane, and Φ or Ψ policy-ids), on lane-purity violations (CL penalties recorded in R only; F and G invariant), or on lexical precision violations (E.10). Transport and Audit: G.10 and G.11 publication and refresh semantics (CL penalties recorded in R or R_eff).

Informative SoTA: telemetry hooks align with post-2015 quality-diversity families (CMA-ME, MAE, DQD, and MEGA) and open-ended methods (POET-class) when monitored via illumination telemetry rather than scored.

#60‑second didactic script

“To mint a mechanism, fill a MechanismDeclaration: declare SubjectBlock (SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?) and SlotSpecs (use a SignatureManifest if it is reusable); then OperationAlgebra, LawSet, AdmissibilityConditions, and Γ_time; define Transport (Bridge and CL with penalties recorded in R only), and Audit (UTS plus E.18 PathId pins). USM and UNM are already such mechanisms; the same template produces comparison, scoring, and publication mechanisms safely bound to CG-Spec without leaving the kernel grammar.”

#Mechanism Declaration Checklist

1. State why this Mechanism is needed, which guard predicates and comparability claims are in scope, which DesignRunTag or CtxState.locus boundary it mediates, and whether a Γ_m (CAL) builder is needed.

• Fill MechanismDeclaration (SubjectBlock, SlotSpecs, OperationAlgebra, LawSet, AdmissibilityConditions, Applicability, Transport, Γ_timePolicy, PlaneRegime, Audit).

• Bind CHR legality and CG-Spec when comparing or aggregating (ComparatorSet, ScaleComplianceProfile (SCP), MinimalEvidence, Γ-fold).

Publish UTS and G.10 relations; cite G.11 telemetry when live; ensure penalties are recorded in R_eff only.

#Archetypal Grounding

#U.Scope (Claim, Work, Publication) — USM as a U.Mechanism instance (informative example)

• Imports: U.ContextSliceSet; Part F.9 Bridge; C.2.1 ReferencePlane (noted for crossings); C.2.2 F–G–R; C.2.3 U.Formality.
• BaseType: U.ContextSliceSet.
• SliceSet: U.ContextSliceSet (addressable U.ContextSlices).
• SubjectKind: U.Scope with specializations U.ClaimScope (G), U.WorkScope, and U.PublicationScope.
• OperationAlgebra: ∈, ⊆, ∩, SpanUnion, translate, widen, narrow, refit.
• LawSet: serial intersection; SpanUnion only where a named independence assumption is satisfied (state features or characteristics, validity window, evidence class); translate uses declared Bridges; Γ_time is mandatory.
• AdmissibilityConditions: deterministic “Scope covers TargetSlice”; fail-closed; unknown → {degrade, abstain} (no implicit unknown→0 and no implicit unknown→false).
• Transport: Bridge-only with CL; penalties are recorded in R_eff; F and G stay invariant; publish UTS notes.
• Γ_timePolicy: point, window, or policy; no implicit “latest.”
• PlaneRegime: not applicable to scope sets (scope is set-valued over ContextSlice, no value-plane); CL^plane not applicable.

#Bias-Annotation (informative)

This pattern intentionally biases Mechanism declaration toward explicit signatures and laws, context-local semantics, and auditable reuse.

• Gov (governance). Bias toward publishable declaration rows, conformance checks, and explicit policy-ids for crossings. Risk: perceived declaration overhead. Mitigation: reuse the MechanismDeclaration template; keep Realizations opaque and put operational details outside the Kernel.
• Arch (architecture). Bias toward locality-first semantics and Bridge-only transport with costs recorded in R or R_eff. Risk: reduced convenience for ad-hoc cross-context reuse. Mitigation: publish adapter mechanisms and make crossings explicit via Transport (CC-UM.3 and CC-UM.4).
• Onto and Epist (ontology and epistemology). Bias toward lawful comparability (CHR legality; CG-Spec binding) and against illegal scalarisation (e.g., ordinal means). Risk: some heuristic scoring practices become non-conformant. Mitigation: represent uncertainty explicitly and use unknown → {degrade, abstain} rather than coercions (CC-UM.7).
• Prag (practice). Bias toward notation-independence and against tool or vendor tokens in the Kernel. Risk: teams may want to inline CI or telemetry fields. Mitigation: keep audit surfaces conceptual (Audit) and reference operational hooks by id only (CC-UM.6).
• Did (didactic). Bias toward explicit SlotKinds and SlotSpecs over positional parameters. Risk: steep learning curve. Mitigation: allow non-normative projections (ValueKindView) and include a “60-second” script plus a mechanism declaration checklist (A.6.1:4.7 and 4.8).

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them (informative)

#Consequences (informative)

• Uniform kernel shape. Scope, normalization, comparison families can be declared and compared without lexical drift.
• Auditable reuse. GateCrossings are UTS-visible via CrossingBundle (E.18); penalties are transparent (R only), with LanePurity and lexical precision (E.10) checks runnable (GateChecks in A.21; Bridge and UTS discipline through F.9, F.17, E.17, and E.18).
• Scalarisation avoids illegality. Partial orders remain set-valued; cross-scale arithmetic is blocked by CG-Spec and CSLC.

#Rationale (informative)

Binding mechanisms to an explicit Signature -> Realization discipline (A.6.0 SignatureManifest plus CC-UM.2 monotonicity and opacity) keeps reuse safe: signatures and laws carry the boundary semantics; realizations may vary but cannot relax laws. It also makes cross-context Bridge crossings explicit and records costs in R_eff, never in F or G.

#SoTA-Echoing (post-2015 practice alignment) (informative)

Purpose. To show how the FPF concept of a Mechanism (law-governed signature with guards and transport) aligns with, and improves upon, leading research and engineering practices after 2015. All comparisons are informative: they serve didactic continuity, not new normative force.

#Contemporary references (post-2015 sources)

SoTA binding note (E.8:11). This section cites primary post-2015 sources directly as the current source-use form for mechanism semantics. When a current ClaimSheet, CorpusLedger, or BridgeMatrix id is available for the same source decision, cite that id instead of repeating the source narrative.

1. Algebraic effects and handlers (post-2015 effect systems and handler implementations) — Adopt and Adapt. They motivate the split “operation signature vs handling”; A.6.1 keeps OperationAlgebra explicit and adds LawSet, AdmissibilityConditions, and Γ_time so legality and time are not implicit. (e.g., Hillerström and Lindley, 2018; Multicore and OCaml-5 effect handlers, 2021–2022).

2. Typed semantic translation frameworks (institution-style morphisms and functorial data migration) — Adapt. A.6.1 uses explicit refinement, extension, and quotient structure (U.MechMorph) but requires cross-Context transport to be Bridge-only with penalties recorded in R or R_eff. (e.g., Spivak and Schultz, 2017; CQL practice, 2017–2023).

3. Policy-as-Code (declarative guard and risk rules) — Adapt. A.6.1 turns runtime policies into deterministic, fail-closed AdmissibilityConditions with named Γ_time windows; evaluators and tool binding stay out of Core. (e.g., Open Policy Agent and Rego, 2016+; UL 4600:2020; ISO 21448:2019).

4. Session and typestate types (post-2015 protocol safety) — Adapt. Protocol constraints inform how guards can restrict legal operator sequences, but A.6.1 keeps boundary semantics as signature and laws and surfaces sequencing constraints as explicit guard predicates rather than hidden state. (e.g., Scalas and Yoshida, 2016–2018; mainstream session-type toolchains, 2017–2024).

5. Lawful measurement and calibrated uncertainty (monotone and calibrated learning, conformal prediction) — Adopt and Adapt. Modern calibrated methods show why comparability must be explicit; A.6.1 binds induced numeric operations to CG-Spec and CSLC and forbids illegal scalarisation (e.g., ordinal means). (e.g., Romano et al., 2019; Angelopoulos and Bates, 2021).

Each source corresponds to a distinct Tradition: formal semantics, categorical algebra, compliance automation, protocol safety, and lawful AI.

#Alignment with A.6.1 fields and concepts

#Adopt, Adapt, and Reject summary

• Adopt. The “explicit operations and explicit laws” stance from modern semantics work, and the calibrated and monotone stance from lawful ML, because both reduce hidden assumptions.

• Adapt. Typed translation ideas and policy‑as‑code idioms into a kernel form that is Context‑local by default, with explicit guards (AdmissibilityConditions) and explicit time windows (Γ_timePolicy) instead of implicit recency.

• Reject. Tool‑bound semantics, automatic recency heuristics, and any cross‑scale arithmetic without CSLC proof; A.6.1 also rejects implicit cross-Context or cross-plane reuse.

• Cross-Context or cross-plane delta (E.8:11). Whenever a SoTA practice would reuse semantics across Contexts or planes, A.6.1 requires an explicit BridgeId (F.9) plus CL, CL^k, CL^plane, Φ, Ψ, and Φ_plane policy-ids (B.3), with penalties recorded in R or R_eff only and never mutating F or G.

#Holonic repeatability

The same correspondence holds at every holonic level: a part-holon declares its own OperationAlgebra, LawSet, and AdmissibilityConditions; a whole-holon merges them via Bridges; a meta-holon re-binds mechanisms under a new Γ-closure. All penalties remain in R or R_eff, while F and G invariants propagate intact.

#Relations (quick pointers)

Builds on A.6.0; instantiates A.2.6 USM (ContextSlice, Γ_time, intersection, SpanUnion, translate) and A.19 plus C.16 UNM (classes, ≡_UNM, validity windows); uses Part B (Bridges, CL, CL^k, CL^plane; no implicit crossings); binds CG-Spec for any numeric comparison or aggregation; telemetry and publication use G.10 and G.11.

#P2W Mechanism Use Relation

When E.18.1 reaches a mechanism cue, this pattern carries the mechanism meaning: OperationAlgebra, LawSet, AdmissibilityConditions, effect realization when declared, transport, and mechanism descriptions. P2W may name the cue and governing pattern, but it does not define these mechanism relations locally.

If the issue under repair is new mechanism introduction, mechanism stabilization, or method-related mechanism use, use the current E.20 governing pattern when live. A P2W citation of a mechanism does not select a method, execute work, pass a gate, prove evidence, or certify a result.

#Lowering, repair, and refresh conditions

A U.Mechanism remains usable while its MechanismDeclaration, imported signatures, SlotSpecs, LawSet, AdmissibilityConditions, Applicability, Transport, Γ_timePolicy, PlaneRegime, and Audit relations remain recoverable and monotone with respect to A.6.0.

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

• an inherited SlotKind is renamed, widened, or given a new required argument;
• a realization relaxes a law, bypasses an admissibility predicate, or depends on hidden structure inside an imported signature;
• a cross-context or cross-plane reuse claim lacks BridgeId, ReferencePlane, CL, CL^k, CL^plane, or Reliability penalty relation;
• a numeric comparison or aggregation is no longer legal under CG-Spec, MM-CHR, CSLC, or the current characteristic-space declarations;
• a Γ_timePolicy, validity window, or “latest” assumption changes an admissibility result;
• a current SoTA change in algebraic effects, session types, typed semantic translation, Policy-as-Code, calibrated uncertainty, or context normalization changes the operation algebra, guard discipline, morphism relation, or transport boundary.

Do not repair the mechanism merely because one work occurrence, telemetry publication, evidence record, gate decision, method choice, or realization version changed. Repair the object governed by that later relation unless the change alters the MechanismDeclaration, its imported signature relation, or the monotone relation between a realization and the MechanismDeclaration.

#A.6.1:End

#U.EffectFreeEpistemicMorphing — Effect‑free morphisms of epistemes

One‑line summary. U.EffectFreeEpistemicMorphing (EFEM) is the universal class of effect-free, law-constrained morphisms between epistemes. An EFEM morphism rewrites episteme components (ClaimGraph, entityOfConcernRef, optional groundingHolonRef, viewpointRef, referenceScheme, and—where C.2.1+ is in use—representationSchemeRef and related slots, plus meta) in a conservative, functorial, reproducible way, with an explicit mode for what happens to the EntityOfConcernSlot (EntityOfConcernChangeMode ∈ {preserve, retarget}) as defined by C.2.1 U.EpistemeSlotGraph.

Placement. After A.6.1 U.Mechanism and before any specialisations (A.6.3 U.EpistemicViewing, A.6.4 U.EpistemicRetargeting).

Builds on. A.6.0 U.Signature (subject/vocabulary/laws/applicability); A.6.1 U.Mechanism; A.6.5 U.RelationSlotDiscipline; C.2.1 U.Episteme — Epistemes and their slot graph; E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement gates); C.3.* (Kind‑CAL / KindBridge for EntityOfConcern classes).

Used by. A.6.3 U.EpistemicViewing; A.6.4 U.EpistemicRetargeting; E.17.0 U.MultiViewDescribing; E.17 (MVPK); E.18 (E.TGA StructuralReinterpretation, Transduction graph).

EntityOfConcern change-mode discipline. EFEM uses EntityOfConcernChangeMode for the preserve/retarget characteristic over C.2.1's EntityOfConcernSlot / entityOfConcernRef family. Earlier source-side spellings must be normalized to the EntityOfConcern family before conformant use and do not define a second EntityOfConcern ontology.

#Problem frame

FPF has many operations that transform knowledge epistemes or publications without directly doing work in the world:

• turning an informal method description into a more formal specification;
• projecting a large system description into a smaller “for‑safety‑officer” view;
• re‑expressing the same behavioural model in a different calculus or notation;
• retargeting an analysis from “this subsystem” to “that subsystem” along a known KindBridge.

All of these are episteme→episteme transforms: they change what is written in an episteme, but they do not themselves measure, execute, or actuate. They are neither Work (A.15) nor Mechanisms in the A.6.1 sense; they are “pure morphisms over epistemes”.

Without a universal pattern for such morphisms:

• every family (KD‑CAL, E.TGA, MVPK, discipline packs) reinvent their own notion of “projection”, “reinterpretation”, or “refinement”;
• laws about what may change in an episteme (content vs EntityOfConcern vs grounding holon vs reference plane) fragment across the spec;
• cross‑family reasoning (e.g. “this E.TGA StructuralReinterpretation is a retargeting, not a view”) becomes brittle and ad‑hoc.

#Problem

Concretely, without EFEM:

1. No single place for “effect‑free” discipline. The distinction “episteme‑only change” vs “Work in the world” is already important (C.2.1 separates episteme components from Work and from publication forms, renderings, and carriers), but the laws for “episteme‑only” operations are scattered or implicit.

2. EntityOfConcern behaviour is unclear. Many transforms intend to keep “what this episteme is about” fixed (viewing), others intend to change it under an invariant (retargeting). Without a common EntityOfConcernChangeMode discipline we get silent breaks in “entityOfConcern”: an operation that looks like a harmless format change may in fact surreptitiously change the entity of concern.

3. No functorial backbone. MVPK, KD‑CAL and E.TGA all implicitly assume that episteme transforms compose and respect identities, but the conditions for this (purity, conservativity, idempotence, scope) are not formulated once and reused. Different parts of the spec repeat subtly different sets of laws.

4. Slot/Ref confusion. With the new U.EpistemeSlotGraph and U.RelationSlotDiscipline, every episteme now has explicit SlotKind / ValueKind / RefKind discipline. Laws for “projection” or “retargeting” that are written against “fields” or unnamed tuple components are now out of alignment.

The result: engineers and tool builders can no longer tell when they are allowed to transform epistemes without changing what is being claimed about the world, nor what needs to be witnessed by Bridges and CL‑penalties when entityOfConcern does change.

#Forces

• Epistemic purity vs operational power. Effect‑free episteme transforms are attractive precisely because they can be reasoned about algebraically and composed freely. But the more operational power they are given (IO, solver calls, measurements), the less they remain “pure” and the more they belong under U.Mechanism / U.WorkEnactment.

• Preserve vs retarget. Viewing is entityOfConcern‑preserving; reinterpretation along a KindBridge is entityOfConcern-retargeting. Both are important, but they must be distinguished and witnessed differently.

• Conservativity vs usefulness. EFEM should be conservative: no new commitments about the EntityOfConcern beyond what input epistemes already entail. At the same time, transformations may factor, aggregate, or normalise content, which may drop information or change representation when the loss and interpretation rule are explicit.

• Locality vs reference planes and Bridges. Epistemes live on reference planes (C.2.1); cross‑plane and cross‑Context reasoning goes via Bridges and CL penalties (Part F/B.3). EFEM must respect this: it cannot smuggle plane changes or transport into “pure” content rewrites.

• EntityOfConcern and Description-episteme boundary and specification-use refinement. The EntityOfConcern is not identical to the Description episteme produced by this use; it may itself be U.Episteme when an episteme is under concern. ...Description names a Description episteme, and ...Spec names a Description episteme admitted for specification use when its subjectRef decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ and the declared checkability/formality/harness gate is present. EFEM admits operations on those epistemes and their slot/ref discipline while keeping EntityOfConcern, Description episteme, Description episteme admitted for specification use, publication face, publication form, publication unit, publication carrier, and rendering lanes distinct (A.7, E.10.D2).

#Solution — define U.EffectFreeEpistemicMorphing once

#Informal definition

Definition. A U.EffectFreeEpistemicMorphing (EFEM) is a class of episteme→episteme morphisms that:

• operate only on the components of an episteme as fixed in C.2.1 U.EpistemeSlotGraph (ClaimGraphSlot, EntityOfConcernSlot, GroundingHolonSlot, ViewpointSlot, representation/reference schemes, and meta);
• are effect‑free (no Work, no Mechanism application, no mutation of systems or carriers);
• are conservative in what they claim about the EntityOfConcern: no new EntityOfConcern commitment may appear unless it is a logical consequence under the declared ReferenceScheme, correspondence, or bridge invariant;
• are functorial (identities and composition behave as expected on the category of epistemes);
• declare an explicit EntityOfConcernChangeMode ∈ {preserve, retarget}, controlling how EntityOfConcernSlot behaves, and how source-migration subjectRef decodes through DescriptionContext when that older wiring name is still present.

The category-theory objects of the EFEM universe are epistemes of some U.EpistemeKind (typically realised as U.EpistemeCard / U.EpistemeView / U.EpistemePublication). The arrows are EFEM morphisms f : X → Y satisfying the P0–P5 laws below.

Specialisations:

• U.EpistemicViewing (A.6.3) — EFEM with EntityOfConcernChangeMode = preserve.
• U.EpistemicRetargeting (A.6.4) — EFEM with EntityOfConcernChangeMode = retarget, tied to KindBridges/ReferencePlanes.

#Signature Block (A.6.0 alignment)

As a U.Signature, EFEM publishes the following SubjectBlock and the standard four‑row block (“SubjectBlock / Vocabulary / Laws / Applicability”) from A.6.0, specialised to episteme→episteme morphisms.

SubjectBlock

SubjectBlock
  SubjectKind   = U.EffectFreeEpistemicMorphing
  BaseType      = ⟨X : U.Episteme, Y : U.Episteme⟩        // episteme pair (domain,codomain)
  Quantification= SliceSet:=U.ContextSliceSet;
  ExtentRule:=admissibleEpistemeMorphisms // Context slices & admissible EFEM per slice
  ResultKind?   = U.Morphism                               // typed morphism f : X→Y

This says: EFEM is “about” morphisms between epistemes, indexed by Context slices; its results are morphisms of a declared type U.Morphism in the Ep category.

Vocabulary (core operators & kinds)

• Types

  • U.Episteme (as holon; realised via species U.EpistemeCard, U.EpistemeView, U.EpistemePublication under C.2.1).
  • U.EpistemeKind (episteme n‑ary relation signature; slots per A.6.5 / C.2.1).
  • U.SubjectRef (source-migration wiring name only; for Description epistemes, including Description epistemes admitted for specification use, it decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ per C.2.1 §6.1 / E.10.D2). It does not define another EntityOfConcern family.
  • U.Morphism (arrow in Ep).
  • U.EntityOfConcernChangeMode = {preserve, retarget} (enumeration; no new Kernel type for “EntityOfConcern”).

• Operators (arrow algebra)

  • id_X : U.Morphism(X→X) for any episteme X.
  • compose(g,f) : U.Morphism(X→Z) where f : X→Y, g : Y→Z.
  • apply(f, x:U.Episteme) : U.Episteme.
  • dom(f), cod(f) : U.Episteme.
  • subjectRef(E) : U.SubjectRef as source-migration projection from DescriptionContext, when old wiring still exposes that name.
  • entityOfConcernChangeMode(f) : U.EntityOfConcernChangeMode // EFEM‑level characteristic from C.2.1.

Each operator that takes epistemes as arguments obeys SlotSpec discipline from A.6.5: in particular, laws below are phrased in terms of the named SlotKinds (EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ReferenceSchemeSlot, ViewSlot, and—when the C.2.1+ extension is used—RepresentationSchemeSlot) and their associated ValueKind/RefKind; we never speak of “field 1/2/3”.

Laws row and Applicability are given by P0–P5 and the Scope clause below.

#Laws P0–P5 (normative)

All laws below are admissibility predicates: a morphism advertised as an instance of U.EffectFreeEpistemicMorphing satisfies them.

#P0 — Typed signature & component profile (C.2.1‑grounded)

For any EFEM morphism f : X→Y:

1. Typed epistemes. X and Y are epistemes of declared kinds K_X, K_Y : U.EpistemeKind, each with a SlotKind signature as per C.2.1 and A.6.5 (at least EntityOfConcernSlot, ClaimGraphSlot, ViewpointSlot?, RepresentationSchemeSlot?, ReferenceSchemeSlot?; GroundingHolonSlot?, ViewSlot? where relevant).

2. Component projection. For each episteme E, EFEM laws may refer to:

   • content(E) : U.ClaimGraph — value of ClaimGraphSlot (stored by value in the minimal core);
   • entityOfConcernRef(E) : U.EntityRef — value of the RefKind for EntityOfConcernSlot;
   • groundingHolonRef?(E) : U.HolonRef — if the episteme kind includes GroundingHolonSlot;
   • viewpointRef?(E) : U.ViewpointRef — if ViewpointSlot is present;
   • referenceScheme?(E) : U.ReferenceScheme — value of ReferenceSchemeSlot (stored by value in the minimal core);
   • representationSchemeRef?(E) : U.RepresentationSchemeRef — only for episteme kinds that use the C.2.1+ RepresentationSchemeSlot;
   • meta(E) — edition/provenance/status components (species‑level).

3. Declared EntityOfConcernChangeMode. Each EFEM species declares a fixed EntityOfConcernChangeMode ∈ {preserve, retarget}. At the level of individual morphisms:

   • if entityOfConcernChangeMode(f) = preserve, then entityOfConcernRef(Y) = entityOfConcernRef(X) (and usually groundingHolonRef(Y) = groundingHolonRef(X) unless an explicit Grounding Bridge is declared);
   • if entityOfConcernChangeMode(f) = retarget, then entityOfConcernRef(Y) ≠ entityOfConcernRef(X) in general and the record names a KindBridge between the two EntityOfConcern values (A.6.4 / F.9).

4. SubjectRef source-migration discipline. For Description epistemes, including Description epistemes admitted for specification use (…Description / …Spec), subjectRef(E) is a DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ (E.10.D2). EFEM species state how source-migration subjectRef transforms in terms of these components (usually: preserve or explicitly adjust ViewpointRef while preserving EntityOfConcernRef and BoundedContextRef).

#P1 — Purity (no external effects)

EFEM morphisms are pure functions on epistemes:

• Applying f : X→Y does not:
  • change any U.System or U.Holon state;
  • execute Work (U.WorkEnactment) or run a U.Mechanism (A.6.1) with operational guards;
  • mutate U.PresentationCarrier (files, databases, message buses, IDEs).
• The only state change introduced by EFEM is the replacement of input epistemes by output epistemes according to apply(f, X) = Y, with all component changes governed by P2–P5.

Any operation that requires measurements, simulations, solver calls, or tool use with external side-effects is modelled as a U.Mechanism/U.Work that produces new epistemes, which may then be related by EFEM morphisms.

#P2 — Conservativity (no new EntityOfConcern commitments)

Let content_X = content(X), content_Y = content(Y), with associated referenceScheme_X, referenceScheme_Y, entityOfConcernRef_X, entityOfConcernRef_Y, groundingHolonRef_X, groundingHolonRef_Y. Interpret each content via its ReferenceScheme and slots. Then:

The set of claims about the EntityOfConcern values that can be interpreted from Y introduces no new atomic commitments beyond those that are logical consequences of the claims interpreted from X, possibly after applying a declared correspondence between representation/reference schemes.

Intuitively:

• EFEM may:

  • delete information (projection/abstraction);
  • normalise or re‑express information (e.g., reordering ClaimGraph, changing notation via a ReferenceScheme/RepresentationScheme correspondence);
  • add meta‑claims about the episteme itself (edition, source, status, witness entries).

• EFEM may not:

  • assert new atomic facts about the EntityOfConcern values or grounding holons beyond what is derivable from input ClaimGraphs under the declared ReferenceSchemes;
  • silently widen the scope of claims (e.g., treating local facts as global, changing Context or ReferencePlane without a Bridge).

Where entityOfConcernChangeMode(f) = retarget, conservativity is understood relative to a declared invariant of the KindBridge (A.6.4): e.g., conservation of energy for a Fourier transform, or preservation of functional behaviour for a structural reinterpretation.

#P3 — Functoriality (identity, composition, correspondence)

We work in the category Ep whose objects are epistemes (species of U.Episteme) and whose arrows are EFEM morphisms satisfying P0–P2, together with the functor

α : Ep → Ref

that maps each episteme to its EntityOfConcern reference (value of EntityOfConcernSlot, i.e. entityOfConcernRef(E)) as in the mathematical description used for epistemes. EFEM instances with entityOfConcernChangeMode(f) = preserve are vertical morphisms for α (α(f) = id), while those with entityOfConcernChangeMode(f) = retarget reindex along a declared KindBridge in Ref.

1. Identities. For each episteme X, there exists id_X : X→X such that:

   apply(id_X, X) = X
   compose(id_Y, f) = f = compose(f, id_X)

   id_X preserves all components (content, entityOfConcernRef, groundingHolonRef, viewpointRef, representationSchemeRef, referenceScheme, meta).

2. Composition. For f : X→Y, g : Y→Z, the composite h = compose(g,f) is an EFEM morphism X→Z with:

   apply(h, X) = apply(g, apply(f, X))
   entityOfConcernChangeMode(h) = combine(entityOfConcernChangeMode(f), entityOfConcernChangeMode(g))   // as per species-specific rules

and P0–P2 hold for h. For example, two preserve morphisms compose to preserve; preserve after retarget is retarget if the KindBridge composition exists.

3. Correspondence‑aware composition. When EFEM changes RepresentationScheme or ReferenceScheme, a CorrespondenceModel (as in C.2.1 §6 and E.17) may be needed to witness commutativity: composition respects these correspondences up to declared isomorphism/oplax naturality (witness epistemes may be recorded in meta).

#P4 — Idempotence & determinism (on fixed configuration)

For any EFEM morphism f : X→Y with fixed configuration (episteme kinds, EntityOfConcernChangeMode characteristic, KindBridge/CorrespondenceModel where needed):

1. Determinism. For the same input episteme X (identical content, slots, meta), apply(f, X) yields the same output episteme Y up to declared structural equivalence (normal forms, alpha‑renaming etc.). There is no dependence on ambient time, randomness, network state, or solver heuristics unless these are encoded as explicit inputs.

2. Idempotence (up to declared equivalence). Re‑applying the same EFEM to its own output yields no further essential change:

   apply(f, apply(f, X)) ≅ apply(f, X)

   where ≅ denotes the structural equivalence declared for the episteme kinds in question (e.g., ClaimGraph normalisation).

Species MAY weaken idempotence to “idempotent after normalisation”; if so, the normalisation step is itself specified as an EFEM morphism and the composite be idempotent.

#P5 — Applicability, scope & compatibility

Each EFEM species publishes an Applicability clause:

• EntityOfConcernClass / EntityOfConcern class. A constraint on the allowed ValueKind of EntityOfConcernSlot (via EntityOfConcernClass ⊑ U.Entity): e.g., “epistemes describing U.Holon that are systems of type X”.

• Grounding holon & Context. Constraints on GroundingHolonSlot and U.BoundedContext: where the morphism is valid (lab, runtime environment, organisational context).

• Representation/ReferenceSchemes. Enumerates admissible RepresentationScheme/ReferenceScheme pairs and any required CorrespondenceModels.

• Viewpoint discipline. For Description epistemes, including Description epistemes admitted for specification use, EFEM specifies which U.Viewpoints (E.17.0) are admissible and how it interacts with U.MultiViewDescribing families (e.g., “works only on engineering viewpoints from TEVB” or “viewpoint‑agnostic normalisation”).

Applying EFEM outside its Applicability (e.g., wrong EntityOfConcernClass, missing grounding holon, incompatible Viewpoint) is non‑conformant: a conformant implementation rejects such attempts or models them as different mechanisms/works, not as EFEM.

Cross‑Context or cross‑plane use (changing U.BoundedContext or ReferencePlane) is not part of EFEM; it is handled by Bridges (Part F) and A.6.1 transport, which then feed new epistemes into EFEM.

#Archetypal Grounding (Tell–Show–Show)

The examples below show how EFEM is intended to be used across the EntityOfConcern and Description-episteme boundary, specification-use refinements, and Viewpoint/MVPK publication lanes.

#Typed specification-use refinement SpecifyDescEpSpecDesc (species of EFEM)

Context. You have an informal U.MethodDescription for a safety check and want a more formal U.MethodSpec with test harness obligations, but about the same method.

Shape.

• Domain: X = U.MethodDescription episteme with entityOfConcernRef(X) : U.MethodRef, content(X) : U.ClaimGraph_D, viewpointRef(X) an engineering viewpoint (TEVB), ReferenceScheme_D.
• Codomain: Y = U.MethodSpec episteme with the same entityOfConcernRef(Y) = entityOfConcernRef(X), viewpointRef(Y) = viewpointRef(X), more structured content(Y) : U.ClaimGraph_S, more explicit ReferenceScheme (explicit pre/post, obligations).

Specify_DescEp_SpecDesc is a species of EFEM:

• entityOfConcernChangeMode(Specify_DescEp_SpecDesc) = preserve.
• P1 — effect‑free: it transforms epistemes only.
• P2 — conservative: any behavioural claims in the Spec must be logically entailed by the informal Description and the method that fills EntityOfConcernSlot; if the spec makes behavioural claims not entailed by that pair, that is modelled as creating a new EntityOfConcern claim with its own Description epistemes and specification use/refinement gates, not as a valid EFEM instance.
• P3–P5 — functorial and scoped: specs compose, applicability bound to the appropriate engineering context and Viewpoints.

This matches A.7 and E.10.D2: EntityOfConcern-to-Description (Describe_EoC_DescEp) is the strict-boundary describing step and is not itself an episteme→episteme morphism; Specify_DescEp_SpecDesc is an optional EFEM species over a Description episteme after a specification use/refinement gate is present. EFEM supplies the episteme→episteme laws for that refinement; it does not make Specification a third peer in A.7.

#Internal normalisation of a View (species of EFEM, entityOfConcernChangeMode = preserve)

Context. In MVPK you compute a engineering view V of a system description; you then normalise the view (sort, factor, put equations into normal form) without changing what it says.

Let X = V_raw, Y = V_norm, both U.EpistemeView instances with the same:

• entityOfConcernRef(X) = entityOfConcernRef(Y) (same system);
• groundingHolonRef(X) = groundingHolonRef(Y) (same environment);
• viewpointRef(X) = viewpointRef(Y) (same Viewpoint);
• representationSchemeRef(X) = representationSchemeRef(Y) (same notation).

The EFEM NormalizeView : X→Y:

• has entityOfConcernChangeMode(NormalizeView) = preserve;
• changes only content and maybe meta (e.g. “normalised at edition E”);
• is idempotent and deterministic (P4);
• is conservative (P2): no new claims, only re‑expression.

MVPK can then assume functoriality of such normalisations without re‑stating the EFEM laws.

#Retargeting sketch (bridge‑backed, entityOfConcernChangeMode = retarget)

Context. E.TGA’s StructuralReinterpretation maps a physical layout view into a functional behaviour view, changing the EntityOfConcern from “physical module assembly” to “functional graph” along a KindBridge.

Inside EFEM, this becomes a species with entityOfConcernChangeMode = retarget:

• input episteme describes S₁ (e.g. a component hierarchy holon);
• output episteme describes S₂ (e.g. a functional network holon);
• a declared KindBridge(S₁,S₂) and invariant (e.g. behavioural equivalence) provide the semantic glue;
• P2 conservativity is checked w.r.t. that invariant.

The details belong to A.6.4/E.TGA; EFEM provides the generic discipline.

#Worked SlotSpec example (engineering SystemDescription episteme kind)

(informative)

To make the SlotKind/ValueKind/RefKind discipline and EFEM laws concrete, consider a simple engineering U.EpistemeKind for system descriptions over EntityOfConcernClass ⊑ U.Entity with EntityOfConcernClass = U.System in a given Context. A minimal SlotSpec table for such a kind could be:

This table is an instance of A.6.5 U.RelationSlotDiscipline: each row is a SlotSpec triple ⟨SlotKind, ValueKind, refMode/RefKind⟩; no additional kernel types are introduced, and C.2.1’s constraints on EntityOfConcernSlot/GroundingHolonSlot are preserved.

Two typical EFEM species over this kind are:

• Specify_DescEp_SpecDesc_Sys : SystemDescription → SystemSpec — a EntityOfConcernChangeMode = preserve species that:

  • reads EntityOfConcernSlot, GroundingHolonSlot, ViewpointSlot, ReferenceSchemeSlot and writes a refined ClaimGraphSlot and possibly a strengthened ReferenceSchemeSlot;
  • satisfies P2 by only adding claims that are logical consequences of the original description plus the fixed EntityOfConcern (A.7 and E.10.D2);
  • satisfies CC‑C.2.1‑5 by explicitly declaring its slot profile and change mode.

• Normalize_EngView : EpistemeView → EpistemeView — a view‑normalisation EFEM (again with EntityOfConcernChangeMode = preserve) that:

  • reads all slots and writes only ClaimGraphSlot (normal form) and meta;
  • is idempotent and deterministic (P4) and pure (P1);
  • is conservative (P2) by construction: it never introduces new atoms about the selected system.

In later A.6.3/A.6.4/E.17.* patterns, concrete EpistemeKinds (for specific engineering description and specification-useification idioms) are expected to provide SlotSpecs of this general shape and to state explicitly, per CC‑C.2.1‑5 / CC‑EFEM.*, which slots their EFEM species read and write.

#Bias & Defaults (informative)

• Episteme‑first, world‑second. EFEM is strictly about epistemes as objects; any world contact (measurements, executions) lives in U.Mechanism/U.Work and produces new epistemes that EFEM may subsequently relate.

• SlotKinds, not “fields”. Laws talk about EntityOfConcernSlot, GroundingHolonSlot, etc., and their ValueKind/RefKind, as per A.6.5 and C.2.1; they never use unnamed tuple positions or “unnamed slot positions”. This keeps EFEM aligned with the slot discipline used for methods, roles, services, and other n‑ary relations.

• Local‑first semantics. EFEM is Context‑local; crossings of Context or ReferencePlane are always delegated to Bridges / A.6.1 transport (with CL penalties to R/R_eff only). No “implicit cross‑Context EFEM” is permitted.

• EntityOfConcern and Description-episteme boundary and specification-use/refinement respect. EFEM never collapses EntityOfConcern with Description epistemes or with specification-use refinements: EntityOfConcern-to-Description and optional specification-use refinement operations are typed explicitly. The former remains the A.7 describing boundary; the latter is an EFEM species only when it is an episteme→episteme refinement admitted by a specification use/refinement gate named by value .

#Conformance Checklist (normative)

#SoTA‑Echoing (informative, lineage)

EFEM is intentionally “thin”: it provides a minimal categorical and slot‑based discipline for episteme→episteme morphisms, making it easy to align with several post‑2015 lines of work:

• Categorical semantics & displayed categories. Treating Ep as a category over Ref via a functor α : Ep → Ref (mapping each episteme to its EntityOfConcern) matches the displayed categories view on fibrations: EFEM arrows are those morphisms in Ep that are “vertical” (preserve α) or “structured reindexings” (retarget under a KindBridge). This is exactly the intended alignment with C.2.1’s subjectRef/ReferencePlane picture.

• Optics as universal projections. Viewing operations (U.EpistemicViewing) refine EFEM in a way analogous to lenses/prisms/traversals in the optics literature: effect‑free, compositional accessors for parts of a larger structure. EFEM captures the laws that underlie those projections (purity, conservation, functoriality); optics‑style constructions can then be used inside discipline packs without modifying the core.

• Structured cospans & correspondences. Many correspondence‑based multi‑view patterns (ISO 42010 correspondences, model synchronisation, traceability links) can be seen as spans/cospans between epistemes. EFEM ensures that the legs of such cospans are effect‑free and conservative, while CorrespondenceModels carry the extra structure needed for consistency management.

• Bidirectional transformations (BX). The “no new commitments” and “functorial & idempotent” constraints mirror modern BX practice around consistency restoration: EFEM is the universal core that BX‑like constructions (view updates, synchronisers) must respect when instantiated for epistemes.

EFEM does not prescribe a specific calculus (deductive, probabilistic, latent‑space), nor a specific representation (symbolic vs distributed); those choices are captured in U.ClaimGraph, U.RepresentationScheme and discipline‑level patterns. EFEM only says what it means to transform epistemes legally in that chosen substrate.

#Consequences

• Single place for episteme‑to‑episteme laws. All effect-free transforms of knowledge epistemes, across KD‑CAL, MVPK, E.TGA, discipline packs, can now be defined as species of EFEM, instead of each family re‑inventing its own law set.

• Clear separation from mechanisms & work. Anything that touches the world (measurements, execution, simulation) is forced into U.Mechanism / U.WorkEnactment, with CL‑penalised Bridges and Γ_time; EFEM remains pure and compositional.

• Stable backbone for Viewing & Retargeting. A.6.3 and A.6.4 do not need to repeat P0–P5; they specialise EFEM with additional constraints (preserve/retarget). Other patterns (e.g. MultiViewDescribing, MVPK, E.TGA StructuralReinterpretation) can depend on EFEM as a stable base.

• Slot‑level clarity. By formulating EFEM laws in terms of SlotKinds/ValueKinds/RefKinds (A.6.5) and the EpistemeSlotGraph (C.2.1), it becomes much harder for Episteme to confuse “EntityOfConcern”, “slot in a relation”, and “reference to that entity”.

• Better didactics. The old “semantic triangle” becomes a didactic projection of EFEM over the EpistemeSlotGraph: EFEM + C.2.1 explain precisely what the triangle was trying to gesture at (symbol, concept, referent), while correctly foregrounding operations, viewpoints, grounding holons, and reference schemes.

#Rationale

Why a separate EFEM pattern (A.6.2) instead of folding into A.6.1 or C.2.1?

• A.6.1 governs Mechanisms (operations with AdmissibilityConditions, Γ_time, transport and Bridges)—too operational for the pure episteme transforms we want here.
• C.2.1 fixes the ontology of epistemes (slots, components, ReferencePlane), but does not talk about morphisms. EFEM is explicitly a morphism‑level pattern over that ontology.

This split mirrors how Signature (A.6.0) separates “what is declared” from “how it is realised”: C.2.1 says what an episteme is; A.6.2 says what an admissible episteme-to-episteme transform is.

Why insist on EntityOfConcernChangeMode?

Because almost all subtle errors in multi‑view reasoning show up as silent retargeting: a transform that appears to keep the same EntityOfConcern actually changes it (e.g., from “component assembly” to “function bundle”) without naming the bridge or invariant. By forcing every species to declare preserve vs retarget, EFEM makes those decisions explicit and reviewable.

Why attach EFEM to SlotKinds instead of informal “fields”?

FPF already committed to a single SlotKind/ValueKind/RefKind discipline (A.6.5) across relations, methods, roles, and now epistemes. Re‑using that discipline here:

• aligns episteme morphisms with the rest of the framework;
• enables later mechanised checks (e.g., that a viewing only touches slots it promised to touch);
• avoids minting yet another notion of “parameter” or “role in a relation”.

#Relations

• Specialises / is specialised by.

  • Builds on A.6.0 U.Signature and A.6.1 U.Mechanism for the uniform SubjectBlock/vocabulary/laws/applicability structure.
  • Specialised by A.6.3 U.EpistemicViewing (entityOfConcern‑preserving EFEM) and A.6.4 U.EpistemicRetargeting (entityOfConcern-retargeting EFEM).

• Constrained by. A.6.5 U.RelationSlotDiscipline (SlotKind/ValueKind/RefKind); C.2.1 U.EpistemeSlotGraph (episteme components, ReferencePlane); E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement gates); Part F (Bridges, CL, ReferencePlane crossings); E.10 (LEX‑BUNDLE naming rules, especially on …Slot / …Ref and ban on Subject/Object in episteme tech names).

• Consumed by. E.17.0 U.MultiViewDescribing (families of Description epistemes, including Description epistemes admitted for specification use, under Viewpoints); E.17 (MVPK — publication as species of Viewing/EFEM); E.18 (E.TGA StructuralReinterpretation and other transductions over epistemes); KD‑CAL/LOG‑CAL rules that reason about episteme transforms categorically.

#A.6.2:End

#U.EpistemicViewing — EntityOfConcern-preserving morphism

One‑line summary. U.EpistemicViewing is the EntityOfConcern-preserving species of U.EffectFreeEpistemicMorphing: an effect‑free projection between epistemes that may change content and representation, but never changes what the episteme is about (the value filling EntityOfConcernSlot in C.2.1). EntityOfConcern preservation discipline. A.6.3 names the preserve branch of the C.2.1 EntityOfConcern preservation law: entityOfConcernRef(Y) = entityOfConcernRef(X) and EntityOfConcernSlot is read-only. Earlier source-side spellings are source-migration wording only; conformant text normalizes them to EntityOfConcern* before use.

Placement. After A.6.2 U.EffectFreeEpistemicMorphing, before A.6.4 U.EpistemicRetargeting.

Builds on. A.6.0 U.Signature; A.6.2 U.EffectFreeEpistemicMorphing; A.6.5 U.RelationSlotDiscipline; A.7 and E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement discipline, DescriptionContext); C.2.1 U.Episteme — Epistemes and their slot graph; C.2 (KD‑CAL/LOG‑CAL, subjectRef, ReferencePlane).

Used by. E.17.0 U.MultiViewDescribing; E.17 (MVPK — Multi‑View Publication Kit); E.17.1/E.17.2 (Viewpoint bundle libraries, TEVB); B.5.3 (Role‑EpistemicViewing); discipline packs for architecture, safety, and ML/LLM‑based representations.

#Problem frame

Engineers and researchers constantly need views that preserve the same EntityOfConcern:

• an ISO 42010‑style architectural view for a particular stakeholder group over a shared architecture description;
• a SysML v2 “view‑as‑query” over an underlying model, changing visualisation but not the modelled system;
• a publication view (Plain/Tech/Assurance) in MVPK over a common description and specification-useification;
• an LLM‑friendly episteme derived from a symbolic specification (or vice versa), preserving what system is being described.

All of these are episteme→episteme transforms that must:

• keep the EntityOfConcern fixed (EntityOfConcernSlot in C.2.1), and
• change only how the episteme talks about it: sliced U.ClaimGraph, different U.Viewpoint, alternative U.RepresentationScheme, or a different U.ReferenceScheme tuned to the same EntityOfConcern and grounding holon.

We need a single, reusable notion of “epistemic viewing” that captures these projections as:

• effect‑free (no Work/Mechanism side‑effects),
• EntityOfConcern-preserving (no silent retargeting),
• conservative (no new commitments about the EntityOfConcern),
• and functorial (compose cleanly in multi-step compositions).

#Problem

Without a dedicated pattern for EpistemicViewing:

1. Views vs retargetings blur. Operations that intend to change only representation (viewing) are easily conflated with operations that change the EntityOfConcern (retargeting). A Fourier‑style transform or a StructuralReinterpretation in E.TGA can quietly drift from “view of S” into “view of a different S′”, without declaring a KindBridge.

2. “View” vs “viewpoint” vs rendered publication collapse. In standards and tools, “view” is often used interchangeably to mean:

   • the viewpoint (specification of concerns and conformance rules),
   • the episteme produced under that viewpoint, and
   • the rendered publication or carrier (document, GUI, export, or other bearer). Without a clear episteme-lane notion of viewing, MVPK and E.17.0 cannot cleanly separate these lanes.

3. No entityOfConcern guarantees. A projection that looks like a harmless slice of a system description may in fact:

   • change entityOfConcernRef (switching to a subsystem or a function),
   • change groundingHolonRef (different plant or runtime),
   • or smuggle in new commitments about the EntityOfConcern. Without explicit invariants over C.2.1 components, “view” becomes an informal metaphor, not a reliable morphism class.

4. Multi‑view reasoning has no core discipline. Multi‑view patterns (ISO 42010 viewpoint libraries, SysML v2 view queries, TEVB, MVPK faces) need:

   • vertical projections that preserve entityOfConcernRef (α : Ep → Ref fixed),
   • and correspondence‑based projections that rely on explicit cross‑episteme links. If each family re‑invents its own notion of “view”, consistency and tool checks degrade.

#Forces

• Same EntityOfConcern, different concerns. Stakeholders want different slices of the same description and specification-useification, sometimes under different viewpoints, without re-identifying the system, method, service, or other entity that fills EntityOfConcernSlot.

• Internal vs cross‑episteme views. Some views depend only on a single episteme (direct viewing); others depend on a CorrespondenceModel (e.g. aligning requirements and design models). Both are admissible, but they require different witnesses.

• Conservativity vs expressivity. A view must not introduce new commitments about the EntityOfConcern, but it may:

  • aggregate or factor claims,
  • change representation regime (diagrammatic vs symbolic vs latent),
  • or shift to a different inference regime, as long as this is conservative.

• EntityOfConcern and Description-episteme boundary and specification-use strictness. …Description names a Description episteme, and …Spec names a Description episteme admitted for specification use whose subjectRef decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ when the declared checkability/formality gate is present. Viewing works over these DescriptionContext triples without collapsing the EntityOfConcern into the Description episteme or Description episteme admitted for specification use produced by the use, while still allowing that EntityOfConcern to be a U.Episteme when an episteme is under concern; it also must not confuse those epistemes with publication faces or carriers.

• Slot discipline and modularity. With C.2.1 and A.6.5, epistemes now have explicit SlotKind/ValueKind/RefKind triples. Viewing invariants must be stated per SlotKind, not in terms of ad‑hoc “fields”, so they can be reused across engineering, publication, and discipline packs.

#Solution — U.EpistemicViewing as EFEM profile (entityOfConcernChangeMode = preserve)

#Informal definition

Definition (informal). U.EpistemicViewing is the EntityOfConcern-preserving species of U.EffectFreeEpistemicMorphing. A U.EpistemicViewing v : X→Y:

• takes an input episteme X and produces an output episteme Y,
• preserves the value filling EntityOfConcernSlot (entityOfConcernRef(Y) = entityOfConcernRef(X)),
• may refine or re‑express content : U.ClaimGraph, viewpointRef, representationSchemeRef, and referenceScheme,
• is effect-free and conservative (no new commitments about the EntityOfConcern),
• and composes functorially with other epistemic viewings.

In C.2.1 terms U.EpistemicViewing behaves like a lens/optic over the episteme slot graph: it focuses on some SlotKinds (typically ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot) while preserving EntityOfConcernSlot (and usually GroundingHolonSlot).

#Signature (A.6.0 / A.6.5 alignment)

Signature header. U.EpistemicViewing is a Morphism‑kind under A.6.0:

SubjectBlock
  SubjectKind    = U.EpistemicViewing
  BaseType       = ⟨X:U.Episteme, Y:U.Episteme⟩      // domain/codomain episteme pair
  Quantification = SliceSet := U.ContextSliceSet;
                   ExtentRule := admissible view morphisms
  ResultKind     = U.Morphism                        // an instance v

Vocabulary (re‑uses A.6.2).

• Types. U.Episteme, U.SubjectRef, U.Morphism, U.EpistemicViewing.
• Operators.
  • id : U.Morphism(X→X)
  • compose(g,f) : U.Morphism(X→Z) where f:X→Y, g:Y→Z
  • apply(v, x:U.Episteme) : U.Episteme
  • dom(v), cod(v) : U.Episteme
  • subjectRef(-) : U.SubjectRef SlotKind-specific discipline. Domain and codomain epistemes are instances of some U.Episteme species (typically U.EpistemeCard, U.EpistemeView, or U.EpistemePublication) whose episteme kinds each provide SlotSpecs (A.6.5) including at least:
  • EntityOfConcernSlot (ValueKind U.Entity, RefKind U.EntityRef),
  • GroundingHolonSlot? (ValueKind U.Holon, RefKind U.HolonRef),
  • ClaimGraphSlot (ValueKind U.ClaimGraph, by‑value),
  • ViewpointSlot? (ValueKind U.Viewpoint, RefKind U.ViewpointRef),
  • ReferenceSchemeSlot (ValueKind U.ReferenceScheme, by‑value),
  • and, where C.2.1+ is in use, RepresentationSchemeSlot, ViewSlot and related slots.

Practical species of EpistemicViewing will very often take X and Y from the same U.EpistemeKind, but the pattern itself only requires that the SlotSpecs of the domain and codomain kinds be compatible in the sense of A.6.5, not literally identical.

Relation to EFEM.

• Every U.EpistemicViewing is an EFEM morphism with entityOfConcernChangeMode = preserve in the sense of A.6.2/C.2.1.
• It inherits P0–P5 from A.6.2, specialised to the case where the value filling EntityOfConcernSlot is unchanged.

#Invariants (EV-0...EV-6, over C.2.1 components)

All invariants below are in addition to A.6.2 EFEM invariants P0-P5 and SHALL be read directly against C.2.1 components and A.6.5 SlotSpecs.

EV‑0 - Species & EntityOfConcernChangeMode.

• Any morphism v:X→Y declared as U.EpistemicViewing MUST:
  • be a species of U.EffectFreeEpistemicMorphing (A.6.2), and
  • declare entityOfConcernChangeMode(v) = preserve.
• Consequently:
  • EntityOfConcernSlot has the same ValueKind and RefKind in the episteme kind of X and Y (same EntityOfConcernClass ⊑ U.Entity);
  • entityOfConcernRef(Y) = entityOfConcernRef(X) by definition of the species.

EV‑1 - Typed domain/codomain & DescriptionContext behaviour.

For any v:X→Y in U.EpistemicViewing:

1. X and Y are instances of U.Episteme species whose episteme kinds both realise at least the core C.2.1 slots (EntityOfConcernSlot, GroundingHolonSlot?, ClaimGraphSlot, ViewpointSlot?, ReferenceSchemeSlot) and obey A.6.5. Many practical species of EpistemicViewing will take X and Y from the same U.EpistemeKind, but the A.6.3 pattern only requires SlotSpec compatibility between domain and codomain kinds (in the sense of A.6.5), not literal kind equality.

2. In the SlotKind-specific read/write discipline:

   • EntityOfConcernSlot is read‑only (no change in entityOfConcernRef).
   • GroundingHolonSlot, if present, is:
     • either preserved exactly, or
     • changed only within an explicitly declared grounding context (e.g. normalising identifiers for the same plant or runtime), justified via a Bridge in the same ReferencePlane.
   • ViewpointSlot, if present, is:
     • either preserved (internal normalisation under the same viewpoint), or
     • changed only to another U.ViewpointRef within a declared U.MultiViewDescribing family (E.17.0), with a CorrespondenceModel providing witnesses.

3. For any episteme that is a …Description/…Spec (E.10.D2), subjectRef decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩. EpistemicViewing MUST:

   • preserve EntityOfConcernRef,
   • preserve BoundedContextRef (unless a Bridge is explicitly cited),
   • treat ViewpointRef as in (2) above.

EV‑2 - Effect‑free boundary (over EpistemeSlotGraph). EpistemicViewing remains pure in the EFEM sense:

• It may change only C.2.1 components of the codomain episteme:
  • content : U.ClaimGraph (e.g. filtering, aggregation, normalisation),
  • viewpointRef (under the constraints in EV‑1),
  • representationSchemeRef and ReferenceScheme (within a fixed representation family or under a declared CorrespondenceModel),
  • meta‑components (edition, provenance, status flags).
• It MUST NOT:
  • invoke U.Mechanism or U.WorkEnactment (measure, execute, actuate),
  • create or modify U.PresentationCarrier (no direct publication rendering or carrier writing),
  • cross ReferencePlanes implicitly (plane crossings go through Bridges with CL penalties in Part F).

Any operational machinery (e.g. SAT/SMT solving, simulation, LLM tool‑use) MUST be modelled as a separate U.Mechanism that produces input epistemes or auxiliary epistemes or carriers consumed by the EpistemicViewing morphism.

EV-3 - No new commitments about the EntityOfConcern.

Let X and Y = apply(v,X) with:

• content_X, referenceScheme_X,
• content_Y, referenceScheme_Y,
• shared entityOfConcernRef and (typically) groundingHolonRef.

Then:

• The set of claims about <entityOfConcernRef, groundingHolonRef> obtained by interpreting content_Y through referenceScheme_Y MUST NOT strictly extend what is already entailed, in KD‑CAL/LOG‑CAL, by content_X interpreted through referenceScheme_X under the same ReferencePlane and context.
• Admissible changes:
  • re‑expression (changing representation, not truth conditions),
  • aggregation (e.g. summarising multiple claims into an explicitly derivable macro‑claim),
  • dropping some information (lossy projection), provided no new atomic commitments about the EntityOfConcern are introduced.
• Any deliberate strengthening of behavioural or structural commitments about the same EntityOfConcern is not a valid EpistemicViewing; it must be modelled either as:
  • a new or changed EntityOfConcern claim with its own Description epistemes, including Description epistemes admitted for specification use under A.7 and E.10.D2, or
  • an A.6.4 U.EpistemicRetargeting plus a new EntityOfConcern claim.

EV‑4 - Functoriality & correspondence alignment.

EpistemicViewing inherits EFEM functoriality and specialises it:

1. Direct EpistemicViewing (same representation scheme). Where representationSchemeRef and ReferenceScheme of X and Y are the same (up to declared normal forms), EpistemicViewing acts as a strict functor on ClaimGraphs:

   • apply(id, X) = X,
   • apply(g ∘ f, X) = apply(g, apply(f, X)),
   • content transformation corresponds to a structural ClaimGraph function.

2. Correspondence‑based EpistemicViewing (representation changes). When viewing relies on a CorrespondenceModel between epistemes or representation schemes:

   • the viewing morphism MUST reference that CorrespondenceModel,
   • compositions involving such viewings MUST publish witnesses (epistemes or proof epistemes or proof records) that squares commute up to declared isomorphism (oplax naturality is allowed, but corrections are deterministic and reproducible),
   • entityOfConcernRef and groundingHolonRef remain as in EV‑1; any transfer across contexts or planes goes via Bridges, not via hidden behaviour of the viewing.

EV‑5 - Idempotency & determinism on fixed configuration.

For any v:X→Y in U.EpistemicViewing, with fixed:

• entityOfConcernRef,
• groundingHolonRef,
• viewpointRef,
• representationSchemeRef,
• referenceScheme,
• and fixed CorrespondenceModel (if used),

the following MUST hold:

• Idempotency. apply(v, apply(v, X)) is isomorphic to apply(v, X):
  • same EntityOfConcern and grounding holon,
  • same viewpoint and representation scheme,
  • ClaimGraphs differ, at most, by declared structural equivalence (e.g. normal form vs source form).
• Determinism. For fixed input and configuration, the result is uniquely determined (modulo declared equivalence). Any source of non‑determinism (random seeds, timing, external service state) MUST either:
  • be exposed as part of content / meta of X, or
  • be moved into a Mechanism outside the viewing morphism.