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

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

#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 Description-episteme 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), A.6.C, A.2.3, A.2.8, and A.2.9 for promise-content, commitment, speech-act, and work-and-evidence unpacking, F.18 only when recovered boundary terms need durable naming, E.10.D2 (EntityOfConcern and Description-episteme boundary; specification use and 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 and U.Viewpoint (E.17.0/A.6.3) and uses publication face, publication form, or interop publication form terms for publication-use questions. 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 or 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 unresolved 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 duties, commitments, promise content, work effects, and evidence are being mixed into one contract sentence, split them through A.6.B and A.6.C 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-use 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 result. 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 substantiate 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 governing A.6.B, A.2.8, A.2.9, A.2.1, or A.21 source named by value.

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 classified 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, and should in explanatory prose is descriptive, not normative.

Statement identifiers (recommended): Adopt the quadrant‑prefixed ID scheme from A.6.B:0 for classifiable statements: L-* (law or definition), A-* (admissibility gate), D-* (deontic or commitment), E-* (effect or 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” identifiers (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, and 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 and evidence story.

This cluster overview makes one disciplined move:

1. Treat a boundary as a stack of boundary layers (Signature → Mechanism → work and evidence carriers) plus publication views and faces, and
2. Provide a boundary discipline matrix (2×2) that classifies statements by boundary 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 and evidence carriers → Publication).
• View (U.View) is a Description-episteme projection under a viewpoint, not a publication file or 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 or mechanism ...Surface” terms; use publication face, form, unit, carrier, and rendering terms only when publication use 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 or 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 accountable role assignment or admitted acting system is obligated to satisfy or 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. The RFC keywords MUST, SHOULD, and MAY are used both for role-assignment or acting-system obligations and for world‑state admissibility predicates. E.8 already demands keeping deontics distinct from admissibility and definitions and recommends predicate‑style constraints for admissibility rather than RFC keywords.

3. Contract talk category errors. “The interface promises…” is a metaphor. Promise content, speech act, commitment, and delivered work are different FPF objects: promise content is governed by A.2.3, a speech act is work governed by A.2.9, a commitment is a deontic binding governed by A.2.8, and a running service is delivered work with evidence. A.6.C unpacks the boundary case; F.18 only names recovered terms when durable naming is current.

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 role-assignment commitments into “laws”.

#Forces

#Solution — A stack + a classification matrix

#Why “stack”: what is stacked, and what “higher and 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 and 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 canonical placement 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 or 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 and 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 and observability block defines the required semantics of an observability and evidence interface (carrier classes and required fields, correlation keys, exposure interface). Retention, access, and enforcement are D‑claims (role-assignment or acting-system duties) that reference the same carrier classes by ID. An MVPK AssuranceLane is a projection for auditors that explains how to adjudicate the evidence interface. This is a special case of CC‑A.6.6: the AssuranceLane face references the Mechanism section and the relevant claim IDs rather than restating semantics.

3. Norms & commitments layer (D: duties or commitments). Deontic statements are bound to accountable role assignments, role values, or admitted acting systems (authors, implementers, operators, providers, reviewers). Canonical placement is a Norms-and-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 and evidence). E-* claims bind observed behaviour to carrier classes and measurement conditions. Canonical placement is an Evidence-and-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 faces or publication 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 and files live on carriers (publication face or publication 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 and spans, logs and 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 and observability semantics.

Minimal content (suggested):

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

No new semantics reminder. The AssuranceLane face may include procedural adjudication guidance (queries, joins, dashboards) as informative text. Any normative thresholds or criteria that would change the boundary’s commitments MUST be authored as E-* claims in the canonical Evidence-and-carriers section and cited by ID, rather than being introduced only inside AssuranceLane face 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 and auditor pipeline"
        correlation: ["traceId", "requestId"]
      adjudication:
        check: "query audit stream for code=NotAdmissible and join to traceId"
        criteriaRef: "E-OBS-1 (pass or fail criteria live canonically in the E-claim)"
      references: [A-AC-1, D-RET-1, Mechanism.AuditObservability]

Default placements (quadrant → stack layer / section):

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

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

• A.6.1 ↔ A‑quadrant: U.Mechanism.AdmissibilityConditions is the canonical claim layer for A-* gate and admissibility claims.
• A.10 / B.3 ↔ E‑quadrant: E-* claims should cite evidence carriers and provenance (A.10); without an explicit evidence-carrier reference they are treated as AssuranceLevel:L0 (Unsubstantiated) in the Trust & Assurance calculus (B.3).
• A.2.3 and 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 E-* by ID when needed.

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: classify 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, and commitments).
• Adjudication substrate: in‑description vs in‑work (whether satisfaction is decided from the description alone or requires observing executed work and 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-and-commitments (role-assignment, U.Role, or admitted acting-system duties and commitments; may be audited via E-*)
• E (Work‑Effects & Evidence) → Evidence-and-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 classifiable 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 → Classify → Place → Bind to EntityOfConcern, Description, or carrier → 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 (role assignments, role values, or admitted acting systems 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 assignment or 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-and-commitments): “Client implementers MUST satisfy A-AC-1.”
• E-OBS-1 (Quadrant E, Evidence-and-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 and SLA): “Provider SHALL meet E-SLA-AVAIL-1 and E-SLA-LAT-1 under the stated exclusions.”
• E-SLA-AVAIL-1 (Quadrant E, Evidence-and-carriers): “availability ≥ 0.999 over calendar month T, measured by carrier UptimeProbeSeries from viewpoint VP.ExternalMonitor.”
• E-SLA-LAT-1 (Quadrant E, Evidence-and-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-and-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 and publication-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 governing split is the A.6.C Contract Bundle: promise content, utterance package or speech act, commitment, and work plus evidence. Boundary engineering keeps that split inside the L/A/D/E claim set:

• 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 and published and versioned (signature or mechanism descriptions plus MVPK faces), plus the U.SpeechAct <: U.Work that published or approved it when provenance matters (A.2.9).
• Commitment (deontic binding; U.Commitment, A.2.8): what an accountable role assignment, U.Role, or admitted acting system 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 and 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, role values, or admitted acting systems 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 classified as either L (truth‑conditional law), D (role-assignment or acting-system 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 (classification examples)

Informative. Classification 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 classification 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 role assignment, U.Role, or admitted acting system (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.

#Classification 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, or 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 and mechanism → view-fork (make it informative only, or move the commitment to the underlying signature or mechanism publication).
• “The system or service SHALL …” where no accountable role assignment or admitted acting system is named → likely misclassified deontic (rewrite as E-* behavior + D-* duty on implementers and 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 classified by the boundary discipline matrix to its proper layer (Laws, Admissibility, Deontics and commitments, Effects and 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 and observability: specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their semantics (fields, correlation IDs, retention class).

• Realization and 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 or 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 and access duties by reference).

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

Classification example:

• “Defined iff tokenValid” belongs in Quadrant A (admissibility gate).
• “Clients MUST include Idempotency‑Key” belongs in Quadrant D (role-assignment or acting-system 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 and 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 a role-assignment or acting-system commitment).

• Effects and 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-and-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, Ontological and Epistemic, 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.
• Ontological and Epistemic bias: Treats signatures and 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 boundary signature (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 classification 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 and 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 and behavioural types for protocol boundaries. Post‑2015 practice in behavioural typing treats boundaries as typed interaction protocols with progress and safety properties. A.6’s classification matrix makes “protocol laws” (Quadrant L) explicit and separates entry gates (Quadrant A) from role-assignment or acting-system duties (Quadrant D) and runtime evidence (Quadrant E), reducing ambiguity.

• Adapt — categorical optics, lenses, and bidirectional transformations. Contemporary lenses treat boundaries as paired transformations with coherence laws; this mirrors the signature or 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 and 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, and 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 references for this split: the wording is not the decision. A.6 keeps policy, API, or schema wording in classified 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, and 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: Uses A.6.C, A.2.3, A.2.8, and A.2.9 to keep promise content, utterance or speech act, deontic commitment, accountable subject, and work and evidence adjudication explicit.
• Connects to signature engineering patterns: A.6.5 (slot discipline) and A.6.6 (anchor and base discipline) can be read as “constructor and 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-use evidence or a causal-use verdict 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 classified 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 governing source named by value: 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-claim classification 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 classification:

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 when coupling words become reusable relation candidates, plus F.18 only when the recovered relation term itself needs durable naming.

#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), A.2.3 (promise content when contract language is current), A.2.8 (U.Commitment), A.2.9 (U.SpeechAct), E.10.D2 (EntityOfConcern and Description-episteme boundary; specification-use and 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, and should in explanatory prose is descriptive, not normative.

Quadrant labels. This pattern uses the classification 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). Classifiable 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; 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 classifiable under exactly one quadrant. If a sentence mixes roles, it is not atomic and MUST be split before it can be classified.

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

• In-description or in-theory: satisfaction is decided from the description alone (e.g., proof or 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, inspecting carriers produced in work, or both.

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 classification distinction.

Modality family. A claim is either:

• Truth‑conditional: definitions, invariants, typing rules (“is”, “iff”, “∀”).
• Governance: governance conditions, obligations, commitments, and exclusions (the RFC keywords MUST, SHOULD, and 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, and carrier, views under viewpoints). What is still needed is a single, reusable classification 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:

• classifies every atomic statement into 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 role-assignment, U.Role, or admitted acting-system 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 classifiable under 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-bound duties, commitments, publication and 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-and-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 and 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, or MAY) as operators inside the law or 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 EntityOfConcern binding. L-* claims are Descriptions: they specify semantics of the signature or 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 and 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 EntityOfConcern binding. 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 role assignments, role values, or admitted acting systems.

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 (role assignment, U.Role, or admitted acting system), 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 and 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 assignment or 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 or provenance matters.

Prohibitions.

• A D-* statement MUST NOT use “the system, service, interface, or specification” as the grammatical subject unless the accountable role assignment or admitted acting system is explicitly named (so the statement is representable as a U.Commitment with an explicit subject, A.2.8). Use A.6.C when contract, promise, utterance, or agreement-like boundary language is live.
• 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 EntityOfConcern binding. D-* claims are primarily about Objects (accountable role assignments or admitted acting systems and their duties) or about Carriers (retention and 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, and metrics, produced reports, measurement outcomes.

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

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

1. Observation and measurement conditions (when, where, and how observed; workload, window, and triggers)
2. Evidence carrier or record reference under A.7, A.10, or G.6 as applicable for the evidence relation or source basis
3. Viewpoint and 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 and 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 or commitment is intended, express it as D-* referencing the E-*.

A.7 EntityOfConcern binding. E-* claims are primarily carrier-referenced: they assert what carriers exist and how they relate to observed work.

Required references (explicit).

• If the effect or evidence claim 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 or 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 or acceptance due to A-*, carrier C is produced or observable under conditions …”

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

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

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

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

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

#(A/E → L) Semantic grounding linkage

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

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

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

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

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

• D-* references L-* that define the terms or 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 or enforce it, and (iii) an observability expectation into the three quadrants:

• A: admissibility predicate (A-*)
• D: duty or 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 or invariants.)
• E-* claims MUST NOT depend on or reference D-* claims. (E-* may reference A-* for conditioning and L-* for metric or term meanings.)
• D-* claims MAY reference L-*, A-*, and E-* claims when 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 classifiable statement verbatim with classification metadata. It is not a new meaning authority.

Guidance (informative):

• The Statement cell should contain the normative text as authored (copied by value), 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-and-commitments, Evidence-and-carriers} to make classification 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 or 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 classified under 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 and implementer duties; SLAs).
• E: ties “what happened” to observable carriers (traces, logs, metrics, and 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 classification:

• 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 classification, 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 → Classify → Triangle → Link → Bind References → Recompose)

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

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

• L if the claim is truth‑conditional and adjudicable in‑description (inspection, proof or type validation, or model reasoning over declared assumptions): definitions, invariants, typing and 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 or 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 or enforcement (that is D-*). (Do not confuse this with Signature.Applicability: applicability scopes intended meaning and intended use; it is not a runtime entry gate.)
• D if it assigns duties or commitments to an accountable role assignment, U.Role, or admitted acting system (RFC keywords belong here; “the interface or 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 and evidence: what carriers exist, under what observation conditions, or both. Minimum fields (recommended): (1) observation and measurement conditions, (2) carrier-class and carrier-schema reference, and (3) viewpoint and 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, or expose …”, classify 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 or commitment, and (iii) an observability expectation (a common failure mode with “guarantee, ensure, approved, or 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 or ensuring the predicate,
• E → A: what evidence or 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 — Bind references (minimal A.7 discipline).

• Place L claims in Signature.Laws (and mechanism-local semantic laws if present), and A claims in Mechanism.AdmissibilityConditions.
• Bind D claims to accountable role assignments or admitted acting systems and prefer ID references (no restatement of L-* / A-* content in new words).
• Bind E claims to carriers and observation conditions and SHOULD include viewpoint and consumer (minimum: conditions + carrier class and schema + consumer and 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 recompositions:

• Tech recomposition: a short L/A/D/E-classified claim bundle (sometimes called a “claim skeleton”) listing L/A/D/E claims and ID references.
• Plain recomposition: 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 or 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 or definitions” (L) instead of A-*.
• AP-5 Adjective smuggling. “fast, secure, approved, or aligned” used instead of qualifiers or 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, and related RFC keywords”) 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 + Classify (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 and 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 IDs and 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 and configuration pins, and computation method reference (L-API-01). Viewpoint and consumer (minimum): the role assignment, viewpoint, or consumer that uses the carriers to adjudicate the gate, audit commitments, or both (e.g., SRE or performance-reviewer). (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 or 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 or envelope.
• E-API-01 → A-API-01 binds adjudication (carriers used to decide the gate or commitment).
• D-API-03 → E-API-01 expresses retention and 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 and 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 and 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 or 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 + Classify

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 and 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 or 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 and 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 and 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 or aligned”)

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Classify

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 or 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 or 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 or value is E-….”

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

Lenses tested: Gov, Arch, Ontological and Epistemic, Prag, Did. Scope: Universal for boundary descriptions.

• Arch bias: favors explicit separation and explicit references; mitigated by allowing narrative faces while keeping commitments classified and referenced by ID.
• Gov bias: makes accountability explicit (D) and auditability explicit (E); mitigated by keeping evidence conceptual and carrier-referenced rather than tool-specific.
• Ontological and Epistemic bias: insists on EntityOfConcern, Description episteme, and 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 or 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 classified, 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, and metrics).

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

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

• SRE and observability discipline: treating traces, logs, and metrics as evidence carriers (E) and separating evidence semantics from retention and 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 classified as E-* with carrier references.
• Requires A.7: binds 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 classification

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 classification:

1. Copy the boundary sentence being used for a decision.
2. Split it into atomic claims before judging it: definition or law claim, admissibility or use-condition claim, role commitment, and work-and-evidence effect claim.
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 to reusable relation words; use F.18 only when recovered terms need durable names; apply A.10 to evidence; apply B.3 to assurance; apply C.16 to measurement; apply C.26.1 to any remaining probe-coupled state-reading claim.
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 quantum-like probe-coupled state-reading claim remains;
• a C.26.1 classify only for the remaining probe-coupled state-reading part;
• an A.10/B.3/C.16/F.9 classification when evidence, assurance, measurement, or bridge work is the actual claim being made.

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 + classification intent), A.6.B (L/A/D/E), A.6.8 (RPR‑SERV) (service‑cluster polysemy unpacking), A.7 (EntityOfConcern, Description episteme, and carrier separation), A.2.3 (U.PromiseContent), A.2.8 (U.Commitment), A.2.9 (U.SpeechAct), A.15.1 (U.Work), A.10 and B.3 (evidence and assurance use), E.10 (L-SERV and LEX-BUNDLE), E.17 (MVPK “no new semantics” faces), F.12 (service acceptance and evidence discipline) Naming boundary: F.18 may provide durable names for recovered terms when naming is current; it does not govern the promise-content, speech-act, commitment, work, evidence, or boundary ontology. Mint or reuse (terminology): Reuses “contract”, “SLA”, and “guarantee” as Plain-level boundary shorthand; mints Contract Bundle as an unpacking lens (not a new entity kind), plus optional register columns (bundleId, bundlePart, and 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, performed work, and carrier-referenced evidence as adjudication basis, then classifying 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 and 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, and 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” classifiable into those objects or 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 and 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”, or “interface agreement” language, unpack it into four parts:

1. Promise Content (Promise content)

   • The promised value or 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, and 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.
• Claim-classification discipline: keep the semantics and 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-* and E-* claims as needed).

2. Utterance Package (speech act + published descriptions)

   • The work occurrence of stating, publishing, or 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 or update commitments, but only under an explicit context policy that recognizes that actType as having such institutional force.
   • The published utterance descriptions (signature or mechanism descriptions plus MVPK faces) carry L/A/D/E-classified claims. The act is not “the contract”; it is the work occurrence that created or 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 or Approve U.SpeechAct. Publication creates or updates utterance descriptions and MAY institute publication claims or 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 or 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 role assignment, U.Role, or admitted acting system 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 or party; never an episteme),
     • modality (normalized deontic token from the BCP-14 family),
     • scope (U.ClaimScope) and validityWindow (U.QualificationWindow),
     • referents (by reference or ID: promise content IDs like SVC-*, plus L-*, A-*, MethodDescriptionRef(...), or PromiseContentRef(...) as needed),
     • optional owedTo (beneficiary or counterparty),
     • optional adjudication.evidenceRefs when the commitment is meant to be auditable (point to E-*),
     • optional source when authority or 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 and A.2.8).

4. Performed work and evidence (Adjudication substrate)

   • The executed work and the observable carriers and traces that can adjudicate whether a commitment was met.
   • This is E quadrant: “what evidence is produced, exposed, or 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-referenced E-* claims, evidence paths, witness relations, or assurance claims governed by A.10, B.3, or the direct evidence pattern named by value.

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

After unpacking, classify 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 and definitions).
  • Put “eligible, covered, or valid iff …” predicates as A (A-* admissibility or gate predicates), not as deontic obligations.
• Commitment → D (who is accountable).
  • Put “MUST, SHALL, or commits to …” statements as D (D-*), preferably as U.Commitment payloads (A.2.8).
  • If compliance requires satisfying or 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.
• Performed work and evidence → E (how we can tell).
  • Put observable traces, audit records, measurement windows, and carrier semantics as E (E-*) with explicit carrier and observation or 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 or 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 or 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 classified:

• Semantic guarantee → L (“by definition or invariant”).
• Governance guarantee → D (“provider commits or 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 or 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 or 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, and canonical location). 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 or specification” as an acting system. Instead:

1. Identify the promise content (promise content) being promised,
2. Identify the accountable Commitment holder(s) (accountable role assignments or admitted acting systems),
3. Identify the Utterance surfaces that publish the boundary (signature or mechanism descriptions plus MVPK views),
4. Identify the Performed work and evidence carriers that could adjudicate whether commitments were met,
5. Classify 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 + classify:

• Utterance: signature or 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 and exclusions). (Name the committing role; do not say “the API commits”.)
• E: evidence expectations: audit and 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 + classify:

• Utterance: published interface spec (pinout, electrical ranges, handshake procedure).
• L: electrical invariants and 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 or 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 and session-type motif)

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

Unpack + classify:

• Utterance: protocol description (could be a type spec or protocol spec plus explanatory views).
• L: safety and progress properties as laws over the protocol model (truth-conditional, within the theory).
• A: admissibility: when an interaction trace is considered valid or admissible (e.g., runtime checks; compilation checks; gating conditions for entering a session).
• D: obligations on implementers or 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 + classify:

• 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, Ontological and Epistemic, 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.
• Ontological and Epistemic bias: enforces EntityOfConcern, Description episteme, and 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”, or “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), Performed work and evidence (adjudication).

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

3. CC‑A.6.C‑3 (Classify contract-language statements via A.6.B). Contract-language statements SHALL be classifiable 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 or observed SHALL be expressed as E claims about work, evidence, and 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 and 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, with the evidence carrier or evidence claim named when current.

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, or 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 or 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 and mitigations

• Additional authoring effort; mitigated by applying the unpacking only when contract-language appears or when a claim is used for decision or 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 and evidence layers. Contract-language is a high-frequency linguistic entry point that collapses these layers unless a disciplined unpacking is applied.

F.18 may supply durable names for recovered terms when naming is current, but it does not provide the ontology. A.6.C makes the boundary split operational: promise content, speech act or utterance package, deontic commitment, performed work, and carrier-referenced evidence as the adjudication basis. This keeps “contract” language classifiable 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 or L).
• Adopt — behavioural and session types for protocol boundaries (post‑2015 practice). Protocols as typed interactions emphasize separating safety and progress properties (L) from runtime admission (A) and from implementer obligations (D), with trace-based evidence (E).
• Adopt or adapt — algebraic effects and handlers plus effect systems. The “operation signature vs handler semantics” split mirrors “utterance substrate vs work and 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 and 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 or 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, and 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: Stable

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

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

#Use and boundary

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

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

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

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

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

#Problem frame

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

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

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

#Problem

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

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

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

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

#Forces

#Solution — Define U.Signature once, reuse everywhere

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

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

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

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

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

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

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

#The Signature Block (universal form)

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

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

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

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

   Semantic functions of the SubjectBlock kinds (informative)

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

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

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

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

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

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

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

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

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

SlotSpec_i := ⟨SlotKind_i, ValueKind_i, refMode_i⟩

where:

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

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

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

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

A SlotSpec table then states:

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

#Profile specialisations (normative; structure‑preserving)

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

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

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

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

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

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

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

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

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

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

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

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

#SignatureManifest (imports and provides; normative)

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

SignatureManifest fields (conceptual; concrete syntax is editorial):

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

Norms (boundary hygiene):

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

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

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

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

#Specialisation knobs (for downstream patterns)

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

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

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

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

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

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

#Archetypal Grounding (Tell–Show–Show)

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

#Near-miss and anti-cases

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

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

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

#Bias-Annotation (lenses and defaults)

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

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

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

#Conformance Checklist (normative)

#Consequences

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

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

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

#Rationale

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

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

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

#Relations

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

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

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

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

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

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

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

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

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

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

#P2W PrincipleFrame Input Order

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

#PrincipleFrame And CHR Observability Relation

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

#PrincipleFrame Name And Profile Boundary For P2W

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

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

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

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

#Lowering, repair, and refresh conditions

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

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

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

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

#A.6.0:End

#U.Mechanism: Law-Governed Operation Algebra over a Subject Kind

Type: Definitional pattern Status: Stable Normativity: Normative

#Problem frame

Use this pattern when a reusable declaration must do more than name a signature. Use it when the project needs to declare a law-governed operation algebra, admissibility predicates, context-local applicability, cross-context transport, and realization discipline for a U.Mechanism.

Use it when the working question is:

• which SubjectKind and BaseType the mechanism ranges over;
• which operations are available and which SlotSpecs those operations publish;
• which laws and invariants govern the operations;
• which admissibility predicates fail closed before an operation can be used;
• which bridge, reference-plane, and reliability-penalty relation governs cross-context or cross-plane use;
• whether a realization tightens the mechanism without relaxing its laws.

Primary EntityOfConcern. The EntityOfConcern is U.Mechanism: a specialization of U.Signature whose vocabulary is an OperationAlgebra, whose laws are a LawSet, and whose additional fields declare admissibility, applicability, transport, time policy, plane policy, audit surface, and monotone realization relation.

First useful move. Write the mechanism as an A.6.0 Signature Block, then add only the mechanism-specific fields: OperationAlgebra, LawSet, AdmissibilityConditions, Transport, GammaTimePolicy, PlaneRegime, and Audit. If cross-context use is current, name the Bridge and the Reliability penalty relation before any reuse claim is made.

What goes wrong if missed. An implementation recipe, method name, policy rule, telemetry package, or cross-context reuse habit can masquerade as mechanism law. Downstream work then cannot tell which operations are admitted, which predicates fail closed, which realization is monotone, and which losses affect Reliability rather than Formality or Guarantee.

What this buys in practice. Scope mechanisms, normalization mechanisms, selector mechanisms, scoring mechanisms, publication mechanisms, and comparison mechanisms can be compared, refined, extended, transported, and realized without hiding law, guard, time, plane, or Reliability assumptions.

Not this pattern when. If the claim is only a reusable declaration with no operation algebra and no admissibility predicates, use A.6.0. If the claim is a semantic way of doing, use A.3.1. If the claim is an episteme describing that way, use A.3.2. If the claim is planned or dated work, use A.15.2 or A.15.1. If the claim is evidence, assurance, gate authority, publication use, or result acceptance, use the governing pattern for that claim.

#Problem

Without a kernel mechanism pattern, scope, normalization, selection, comparison, and publication constructs proliferate with incompatible algebras, hidden guard predicates, and ungoverned reuse. Cross-context use loses its Bridge and Reliability penalty relation. Numeric comparison drifts into scale-incompatible scalarization. Realizations begin to relax laws rather than safely implement them.

FPF already has the A.6.0 Signature discipline, bridge and reference-plane patterns, characteristic-space and measurement rules, and work or evidence patterns. What is missing without U.Mechanism is one kernel kind for reusable law-governed operation algebras with admissibility, transport, audit, and monotone realization.

#Forces

#Solution

#Definition

U.Mechanism is a specialization of U.Signature. A mechanism publication includes the universal four-row Signature Block:

Mechanism-only additions are AdmissibilityConditions, Transport, GammaTimePolicy, PlaneRegime, and Audit. They extend the Signature without creating a fifth Signature row.

#Mechanism declaration

MechanismDeclaration:
  DeclarationHeader:
  Imports:
  SubjectBlock:
    SubjectKind:
    BaseType:
    SliceSet:
    ExtentRule:
    ResultKind:
  SlotIndex:
  OperationAlgebra:
  LawSet:
  AdmissibilityConditions:
  Applicability:
  Transport:
  GammaTimePolicy:
  PlaneRegime:
  Audit:

DeclarationHeader states id, version, and publication state. If the mechanism is intended to be imported or reused, it includes a SignatureManifest; DeclarationHeader.id, DeclarationHeader.version, publication state, imports, and public symbols must match the manifest.

Imports names signatures that supply non-kernel symbols used by the Signature Block or operation algebra. Imports are acyclic. Imported signatures are opaque: reference only their provided symbols and ClaimIds.

SubjectKind names the EntityOfConcern kind acted upon. BaseType references an existing U.Type. A mechanism publication does not define a new core type inside the mechanism definition.

SlotIndex is a derived index over SlotSpecs used by OperationAlgebra and guard-only SlotSpecs used by AdmissibilityConditions. It does not replace per-operator SlotSpecs and does not relax A.6.0 argument discipline.

OperationAlgebra names operations whose signatures use SlotKinds from the SlotIndex. Each operation publishes SlotSpec triples for argument positions; numeric indices are presentation only.

LawSet states equations and invariants. Admission and eligibility tests belong under AdmissibilityConditions, not under LawSet.

AdmissibilityConditions are deterministic, context-local guard predicates that fail closed. Unknowns become degrade or abstain; they are not coerced to zero or false.

Applicability binds the mechanism to a U.BoundedContext with plane, time, and comparison-compliance notes.

Transport is a declarative policy surface for cross-context or cross-plane use. It names the Bridge, channel, and ReferencePlane relation; when planes differ it names the plane-loss policy. It does not introduce a U.Transfer edge and does not restate CL, Phi, Psi, or plane-policy tables. Penalties are recorded in Reliability or effective Reliability only; Formality and Guarantee stay invariant.

GammaTimePolicy states point, window, or policy. There is no implicit latest.

PlaneRegime declares reference-plane treatment when values, operations, or comparisons cross planes.

Audit is a conceptual audit surface. It cites policy ids, crossing records, and edition pins by reference rather than embedding telemetry details or tool-specific execution details in the kernel pattern.

#Kernel-token declarations

This pattern defines these kernel tokens:

• U.Mechanism
• U.MechMorph
• U.MechanismDeclarationTemplate
• MechanismDescription
• MechFamilyDescription
• MechInstanceDescription

It reuses U.Signature, U.Type, U.BoundedContext, Bridge, ReferencePlane, characteristic-space, measurement, and reliability-channel terms without changing their governing patterns.

#Method and mechanism positions

Do not decide the method and mechanism question by vocabulary. When a source expression names changing, producing, selecting, deriving, controlling, or maintaining an EntityOfConcern, use E.10.ARCH:3.1 to recover the project concern first and then assign separately governed typed FPF values.

For this host, keep the local question thin: is the current claim a law-governed mechanism declaration or realization over a SubjectKind and BaseType? If the source label also raises method, method-description, formal-substrate, work-plan, dated-work, evidence, source, gate, result, publication, or temporal claims, keep those values linked only by explicit relation positions and apply their own governing patterns.

U.Method governs the context-local way of doing a transformation or enactment. U.Mechanism governs a law-governed declaration over a SubjectKind and BaseType: operation algebra, laws, admissibility predicates, applicability, transport, audit surface, and monotone realization relation.

A solver-selection scheme can be a U.Method in one bounded context; a selector mechanism can declare operations over candidate methods; a selected method can fill a mechanism slot; and a mechanism realization can be implemented through a method description and enacted in dated work. Those links do not make A.3.1 sufficient for a mechanism claim or A.6.1 sufficient for a method claim.

Do not assign the same typed value as both U.Method and U.Mechanism unless a governing pattern explicitly admits such dual typing. Slot-position labels do not create alternate ontology.

#Morphisms and constructors

U.MechMorph provides structure-preserving relations and constructors between mechanisms:

For specialization chains:

• name the parent and the morphism kind;
• keep inherited SlotKinds invariant;
• allow ValueKind narrowing and guard strengthening in Refinement;
• introduce extra required inputs only through new operations or adapter mechanisms;
• keep root mechanisms general and domain-specific policies in specialized mechanisms.

#Description records

MechanismDescription is the ordinary description episteme for a mechanism declaration. It can show:

Mechanism:
  Imports:
  SubjectBlock:
  SlotSpecs:
  OperationAlgebra:
  LawSet:
  AdmissibilityConditions:
  Transport:
  GammaTimePolicy:
  PlaneRegime:
  Audit:

MechFamilyDescription groups one MechanismDeclaration with multiple realizations. Each realization may tighten laws or guards and must not relax them.

MechInstanceDescription records a mechanism declaration in one context with windows, named regimes, and BridgeIds. It is a conceptual instance description, not an operational telemetry record.

#Defaults

• Local-first semantics: judgments are context-local; crossings are explicit and costed in Reliability.
• Comparison compliance: numeric comparison or aggregation uses comparison, measurement, and characteristic-space rules; partial orders return sets.
• Tri-state guard discipline: unknown guard results become degrade or abstain.
• Reliability-only penalties: Bridge, kind, scope, and plane losses affect Reliability or effective Reliability, not Formality or Guarantee.
• Opaque imports: imported signatures are referenced by provided symbols and ClaimIds.

#USM and UNM as mechanism instances

USM can be represented as a U.Mechanism over U.ContextSliceSet with operations such as membership, subset, intersection, span union, translate, widen, narrow, and refit. Its laws include serial intersection, span union only under a named independence assumption, and mandatory time policy.

UNM can be represented as a U.Mechanism for normalization classes and normalization equivalence. It uses normalize-then-compare discipline, scale-appropriate transforms, and comparison-compliance rules.

These examples are informative. They show that scope, normalization, comparison, scoring, and publication mechanisms can share one kernel mechanism shape without changing their own governing patterns.

#Archetypal Grounding

#Selector mechanism

A team needs to select one method from candidate methods. The selection method can be U.Method; the selector mechanism declares operations over candidate sets, criteria, comparison results, context, and selected value. It states admissibility predicates for candidate completeness, comparison availability, and time window. The selected method remains a method value; the selector mechanism is not the selected method.

#Scope mechanism

A project uses context slices to decide where a claim applies. USM declares the slice set, operations, laws, admissibility predicates, bridge policy, and time policy. A source statement such as "scope covers target slice" is admissible only if the guard predicate can be evaluated in the bounded context.

#Normalization mechanism

A benchmark group normalizes scores before comparing systems. UNM declares admissible normalization methods, equivalence, transforms by scale type, and comparison-compliance conditions. Ordinal averaging is rejected because the mechanism cannot make scale-incompatible arithmetic admissible.

#Publication mechanism

A publication mechanism emits selector-ready packs, refresh cues, and crossing records. The mechanism declares operations and admissibility predicates; actual publication work, telemetry, evidence, and gate decisions stay with their governing patterns.

#Bias-Annotation

Typical biases:

• implementation-as-law bias: code, workflow diagrams, or recipes are treated as mechanism law;
• method-as-mechanism bias: a way of doing is treated as an operation algebra with laws and admissibility predicates;
• transport-by-habit bias: cross-context reuse happens without Bridge, ReferencePlane, and Reliability penalty relation;
• scalarization bias: partial orders, ordinal scales, or cross-unit values are forced into one number;
• slot-position bias: parameter positions substitute for named SlotKinds and SlotSpecs;
• tool-binding bias: evaluator, vendor, CI, or telemetry details are put into kernel mechanism semantics.

#Conformance Checklist

CC-UM.0 (A.6.0 alignment). A conforming U.Mechanism publication includes the four-row U.Signature Block. OperationAlgebra is the Vocabulary row, LawSet is the Laws row, and Applicability is the Applicability row. SlotIndex is a derived index, not a fifth Signature row.

CC-UM.1 (Complete declaration). A conforming publication includes DeclarationHeader, Imports, SubjectBlock, SlotIndex, OperationAlgebra, LawSet, AdmissibilityConditions, Applicability, Transport, GammaTimePolicy, PlaneRegime, and Audit.

CC-UM.2 (Manifest coupling). If imported or reused, the mechanism includes a SignatureManifest consistent with DeclarationHeader, imports, and provided symbols.

CC-UM.3 (Monotone realization). A realization satisfies the mechanism LawSet and imported laws. It may tighten laws or guards and must not relax them.

CC-UM.4 (Opaque imports). Realizations and mechanisms treat imported signatures as opaque. They reference only provided symbols and ClaimIds.

CC-UM.5 (Bridge-only transport). Cross-context or cross-plane use names BridgeId, channel, ReferencePlane, and plane policy when needed. Transport does not create a U.Transfer edge.

CC-UM.6 (Reliability-only penalties). Scope, kind, bridge, or plane penalties are recorded in Reliability or effective Reliability only. Formality and Guarantee stay invariant.

CC-UM.7 (Comparison compliance). Numeric comparison or aggregation binds to characteristic-space, measurement, scale, and comparison rules. Partial orders remain set-valued unless a declared scorer governs the reduction.

CC-UM.8 (Tri-state guards). Guard predicates are deterministic, context-local, and fail closed. Unknowns become degrade or abstain, not zero or false.

CC-UM.9 (SlotIndex as view). SlotIndex is mechanically derivable from per-operator SlotSpecs plus guard-only SlotSpecs. Didactic ValueKind projections do not replace SlotSpecs.

CC-UM.10 (Specialization chains). A mechanism specialization names its parent and morphism kind, preserves inherited SlotKinds, narrows ValueKinds only in Refinement, and avoids new mandatory inputs to inherited operations.

CC-UM.11 (No in-place type definition). BaseType references an existing U.Type. Any new U.Type requires a separate accepted naming and kind decision.

CC-UM.12 (Method-position separation). A mechanism publication does not close a method, method-description, work-plan, dated-work, evidence, gate, publication-use, or result claim. Linked values are named by their governing patterns.

CC-UM.13 (No tool binding). Kernel mechanism narrative does not depend on vendor names, CI hooks, telemetry fields, or tool-specific evaluator semantics. Such details are outside the mechanism unless another governing pattern admits them.

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Quick use cards

• Mechanism = operation algebra plus laws. Add guards, transport, time, plane, audit, and realization discipline.
• Method is not mechanism. A method can use or fill a mechanism slot; it does not become the mechanism by name.
• Guards fail closed. Unknown guard results become degrade or abstain.
• Transport is Bridge-only. Crossings need Bridge, ReferencePlane, and Reliability penalty relation.
• SlotKinds travel. Positional parameters do not replace SlotSpecs.
• Realizations tighten. A realization may specialize but not relax mechanism laws.

#Rationale

Mechanisms need a kernel shape because many FPF practices declare reusable operation families: scope operations, normalization operations, selector operations, comparison operations, publication operations, and scoring operations. Without one shape, each practice invents local vocabulary for operations, laws, guards, reuse, and realization.

Binding mechanisms to A.6.0 Signature discipline keeps declaration and realization separate. The Signature carries boundary semantics; realization varies under monotonicity. Bridge-only transport and Reliability-only penalties keep cross-context losses visible without mutating Formality or Guarantee.

#SoTA-Echoing

Refresh this pattern when current work on effect systems, typed semantic translation, policy-as-code, safety standards, protocol types, calibrated uncertainty, characteristic-space comparison, or FPF's own signature, method, work, evidence, gate, and transport patterns changes the governing distinction.

#Relations

• Builds on: A.6.0 U.Signature; A.1.1 U.BoundedContext; SlotSpec and argument-discipline patterns; Bridge and ReferencePlane patterns.
• Coordinates with: A.3.1 U.Method; A.3.2 U.MethodDescription; A.15.2 U.WorkPlan; A.15.1 U.Work; A.19; C.16; C.29; A.10; B.3; A.20; A.21; E.18; E.20.
• Separates from: direct method choice, implementation recipe, telemetry publication, evidence record, gate decision, result certification, and realization work.
• Uses for precision restoration: E.10, E.10.ARCH, and F.18; use E.10.ARCH:3.1 when source labels such as algorithm, program, workflow, process, procedure, recipe, solver, or control strategy hide the current relation position.

#P2W mechanism-use relation

When E.18.1 reaches a mechanism cue, A.6.1 carries the mechanism meaning: operation algebra, LawSet, AdmissibilityConditions, realization relation 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 E.20 when mechanism-governing-definition assignment is current. 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, GammaTimePolicy, PlaneRegime, and Audit relations remain recoverable and monotone with respect to A.6.0.

Repair the mechanism, or define 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, loss policy, or Reliability penalty relation;
• a numeric comparison or aggregation is no longer compliant with the governing characteristic-space, measurement, scale, or comparison patterns;
• a GammaTimePolicy, applicability window, or implicit latest assumption changes an admissibility result;
• a current SoTA change in effect systems, protocol 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 neighboring 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.EpistemeSlotRelation.

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 relation; 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 (structural reinterpretation over transformation-flow structure).

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.18, 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.18 structural reinterpretation 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.18 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.EpistemeSlotRelation 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.EpistemeSlotRelation (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.18 structural reinterpretation 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 and E.18; 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 an exact specification use/refinement gate.

#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.18, 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.18 structural reinterpretation) 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 EpistemeSlotRelation (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 EpistemeSlotRelation: 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.EpistemeSlotRelation (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 (structural reinterpretation and other transformation-flow relations 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 relation; 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 structural reinterpretation in E.18 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 relation: 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 EpistemeSlotRelation). 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.

EV‑6 - Applicability & MultiViewDescribing alignment.

Each species of U.EpistemicViewing MUST:

1. Declare an Applicability profile (A.6.0) specifying:
   • permitted EntityOfConcernClass ⊑ U.Entity (ValueKind of EntityOfConcernSlot),
   • permitted groundingHolonRef classes and ReferencePlanes,
   • admissible viewpointRef ranges (possibly a named U.ViewpointBundle),
   • admissible representationSchemeRef families.
2. For Description epistemes, including Description epistemes admitted for specification use in a U.MultiViewDescribing family (E.17.0):
   • preserve EntityOfConcernRef of DescriptionContext,
   • either preserve ViewpointRef or change it within the declared viewpoint bundle, with any additional constraints recorded in the family’s CorrespondenceModel,
   • never widen ClaimScope beyond what EV‑3 permits.
3. Treat any change of EntityOfConcern (even if “intuitively minor”, such as moving from subsystem to system) as out of scope for A.6.3; such moves belong to A.6.4 U.EpistemicRetargeting.

#Profiles: U.DirectEpistemicViewing and U.CorrespondenceEpistemicViewing

U.EpistemicViewing is further structured into two important species; both inherit EV‑0…EV‑6.

1. U.DirectEpistemicViewing — self‑contained views.

   • Domain and codomain epistemes share:
     • the same representationSchemeRef (up to declared normalisation),
     • the same ReferenceScheme (or a refinement which is conservative and structurally documented).
   • No external CorrespondenceModel is needed: the view is computed solely from the input episteme and, optionally, fixed configuration.
   • Typical cases:
     • internal normalisation (sorting, rewriting) of an engineering view;
     • filtering U.ClaimGraph to keep only safety‑relevant claims;
     • simplifying a proof‑oriented specification to a more operational form under the same semantics.

2. U.CorrespondenceEpistemicViewing — views relying on correspondence models.

   • Viewing depends on:
     • one or more subject epistemes (e.g. requirements and design),
     • an explicit CorrespondenceModel that relates their ClaimGraphs and representation schemes.
   • The result is an episteme (often an U.EpistemeView) whose entityOfConcernRef matches that of the primary episteme, but whose content is computed through the correspondence links.
   • Typical cases:
     • ISO 42010‑style correspondences between architectural descriptions;
     • cross‑model views in model‑based systems engineering (MBSE), where view content is computed from multiple model fragments;
     • traceability‑based views aggregating requirements, design elements, and tests.

In both profiles:

• CorrespondenceModel remains an episteme-lane publication, not a new kernel‑type hidden inside A.6.3.
• U.EpistemicViewing stays view‑like: it reveals what is already there under the correspondence; it does not perform Γ-style construction of new EntityOfConcern claims.

#Common same-entity specialization notes

Two recurring EntityOfConcern-preserving families can be read as specializations governed by A.6.3, provided that EV‑0…EV‑6 remain explicit.

1. ConservativeRetextualization. Use this when the receiving item remains textual and the main change is wording, density, ordering, language, or bounded filtering of already available content. It stays in A.6.3 only if entityOfConcernRef is preserved, no new claims about that entity are minted, and correspondence use does not collapse into bridge or substitution licence.

2. RepresentationSchemeTransition. Use this when the receiving item changes representation scheme or reasoning medium while still preserving the same EntityOfConcern. It stays in A.6.3 only if representation-factor delta, recoverability, loss, and preserve-vs-retarget boundaries remain explicit. Purely textual rewrites belong with ConservativeRetextualization; any change of EntityOfConcernRef belongs with A.6.4.

These notes do not create new governing patterns. They mark recurring same-entity specialization boundaries that remain subordinate to U.DirectEpistemicViewing / U.CorrespondenceEpistemicViewing and to the general A.6.3 invariants.

#Archetypal grounding (Tell–Show–Show)

#Engineering system description → safety officer view (DirectEpistemicViewing)

Context. A system team maintains a rich SystemDescription episteme for a plant holon S under an engineering viewpoint from TEVB. A safety officer needs a concise view showing only safety‑critical components, hazards, and mitigations.

Shape.

• Domain X. X : U.SystemDescription with:
  • entityOfConcernRef(X) : U.SystemRef (the plant S),
  • groundingHolonRef(X) : U.HolonRef (runtime environment),
  • viewpointRef(X) : U.ViewpointRef (engineering TEVB viewpoint),
  • content(X) : U.ClaimGraph (full behavioural & structural claims).
• Codomain Y. Y : U.EpistemeView with:
  • entityOfConcernRef(Y) = entityOfConcernRef(X),
  • groundingHolonRef(Y) = groundingHolonRef(X),
  • viewpointRef(Y) either equal to or a refinement of the original engineering viewpoint (TEVB safety sub‑viewpoint),
  • content(Y) containing only safety‑relevant claims, plus explicit aggregation nodes (e.g. hazard summaries).

SafetyView : X→Y is a DirectEpistemicViewing:

• entityOfConcernChangeMode = preserve,
• only content, viewpointRef (within TEVB) and meta change,
• KD‑CAL/LOG‑CAL checks show that every hazard/mitigation claim in Y is entailed by X,
• view is idempotent and deterministic given X and the selected safety profile.

This is the canonical “engineering view” archetype that later species in E.17.2/TEVB refer back to.

#MVPK publication view normalisation (DirectEpistemicViewing)

Context. MVPK emits a TechCard view V_raw for an arrow f in a morphism class (e.g. a gate-checked, crossing-visible service with OperationalGate(profile) + DecisionLog). The publication pipeline wants a normalised view V_norm where:

• arrows are ordered canonically,
• units and names follow a fixed naming discipline,
• redundant cells are removed.

Shape.

• X = V_raw, Y = V_norm, both U.EpistemeView instances with:
  • same entityOfConcernRef (the morphism’s arrow or capability),
  • same groundingHolonRef (runtime/plant),
  • same viewpointRef (publication viewpoint),
  • same representationSchemeRef (TechCard schema).

NormalizeTechCard : X→Y is a DirectEpistemicViewing:

• changes only content and meta (e.g. “normalised at edition E”),
• is pure and idempotent (two passes give the same normal form),
• is conservative: no new claims about the arrow f appear; information is only reordered or discarded.

MVPK can rely on this as an A.6.3‑conformant step without restating EFEM invariants.

#Cross‑model consistency view (CorrespondenceEpistemicViewing)

Context. A system has:

• a requirements episteme R (“what the system should do”), and
• a design episteme D (“how the system does it”),

both with entityOfConcernRef pointing to the same system holon S, but living in different notations and contexts. A systems engineer wants a view that shows only those requirements that currently have design coverage.

Shape.

• R : U.SystemRequirementsDescription with ClaimGraph C_R.
• D : U.SystemDesignDescription with ClaimGraph C_D.
• CM : U.CorrespondenceModel relating requirements to design elements.
• Y : U.EpistemeView with:
  • entityOfConcernRef(Y) = entityOfConcernRef(R) = entityOfConcernRef(D) = S,
  • groundingHolonRef(Y) inherited from R/D or declared via a Bridge,
  • content(Y) aggregating only those requirements in C_R for which CM records coverage in C_D.

CoveredRequirementsView(R,D,CM) : X→Y (with X a compound episteme or a bundle episteme over R,D,CM) is a CorrespondenceEpistemicViewing:

• relies essentially on CM (without it, the view is undefined — fail‑closed),
• must publish witnesses that two different ways of composing local correspondences give the same result up to declared equivalence,
• remains conservative: it does not assert that any requirement is covered unless that fact is recorded in CM and justified in D.

This archetype mirrors post‑2015 work on model synchronisation and bidirectional transformations, but anchored in the EpistemeSlotRelation.

#Consequences

• Clear separation of viewing vs retargeting. U.EpistemicViewing and U.EpistemicRetargeting (A.6.4) now cleanly separate:

  • “view of the same EntityOfConcern” vs “description of a different entity under a bridge”, and
  • vertical morphisms (α fixed) vs retargeting morphisms (α changes under KindBridge).

• Stable backbone for multi‑view patterns. Multi‑view description (E.17.0), viewpoint bundle libraries (E.17.1/E.17.2), and MVPK publication now share a single notion of view morphism, aligned with C.2.1 slots and the EntityOfConcern and Description-episteme boundary and specification use/refinement discipline.

• SlotKind-specific discipline for tools. Tools implementing views (queries, projections, report generators, LLM‑based summarisation) must declare:

  • which SlotKinds they read,
  • which SlotKinds they may write,
  • and that EntityOfConcernSlot is preserved. This removes ambiguity around subject/EntityOfConcern changes and enables robust static checking.

• Alignment with modern view/query practices. The pattern aligns with:

  • ISO 42010:2011/2022 and its focus on viewpoints, views, and correspondences over an entity of concern;
  • SysML v2 “views‑as‑queries” paradigm, where views are queries over a stable model, not new models;
  • post‑2015 work on optics and displayed categories, treating views as structured projections over a fibred category of epistemes.

#Rationale & SoTA‑echoing (informative)

• Optics and displayed categories. In categorical terms, epistemes form a category Ep fibred over a category of EntityOfConcern references Ref via α : Ep → Ref. EpistemicViewing corresponds to vertical morphisms that preserve α. Their behaviour closely tracks profunctor optics: the EntityOfConcernSlot plays the role of the “focus index”, while ClaimGraphs and representation schemes act as the data being transformed. Recent work on optics (2018‑onwards) provides compositional invariants that FPF leverages without committing to a specific optic calculus.

• Multi‑view modelling and viewpoint libraries. ISO 42010 and its successors, as well as MBSE practice from ~2015 onwards, have refined the separation between viewpoints (families of concerns, stakeholders, and notations) and views (instances under those viewpoints). U.EpistemicViewing gives FPF a substrate‑agnostic notion of “view” that can be instantiated for architecture descriptions, safety cases, or even research epistemes/publications, while TEVB and E.17.0 specialise it to engineering holons.

• Bidirectional transformations and consistency management. Modern BX research treats views and consistency restoration as structured transformations between models, with consistency relations acting as correspondences. U.CorrespondenceEpistemicViewing echoes this practice but insists that:

  • viewing is non-creative for EntityOfConcern commitments,
  • any strengthening or change of EntityOfConcern is explicitly modelled as retargeting or EntityOfConcern-claim change.

• Hybrid symbolic/latent representations. Contemporary work on LLMs and neurosymbolic systems often toggles between:

  • symbolic specifications (logical, tabular, diagrammatic), and
  • distributed or latent representations used for computation. By treating U.RepresentationScheme and U.RepresentationOperation as first‑class episteme components, FPF allows EpistemicViewing to range over:
  • purely symbolic projections,
  • latent‑space projections,
  • or hybrids that invoke external mechanisms before applying a pure view, without changing the core invariants.

#Conformance checklist (normative)

CC‑A.6.3‑1 - EFEM species and EntityOfConcernChangeMode. Any pattern that claims to define U.EpistemicViewing SHALL:

• declare itself a species of U.EffectFreeEpistemicMorphing (A.6.2),
• fix entityOfConcernChangeMode = preserve,
• and state its Applicability profile (EntityOfConcernClass, contexts, viewpoints, representation schemes).

CC-A.6.3-2 - SlotKind-specific read/write discipline. For each species of EpistemicViewing, the definition MUST:

• list the SlotKinds it reads (typically EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot),
• list the SlotKinds it writes (typically ClaimGraphSlot, optionally ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot, and meta),
• assert explicitly that EntityOfConcernSlot is read‑only,
• and state any constraints on GroundingHolonSlot / ViewpointSlot changes.

This satisfies A.6.5 and C.2.1 checkpoint CC‑C.2.1‑5.

CC‑A.6.3‑3 - DescriptionContext discipline (for Description epistemes, including Description epistemes admitted for specification use). When domain/codomain epistemes are …Description/…Spec:

• viewing invariants SHALL be phrased in terms of DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩,
• EntityOfConcernRef MUST be preserved,
• BoundedContextRef MUST be preserved unless a Bridge is explicitly cited,
• ViewpointRef MUST either be preserved or changed within a declared U.ViewpointBundle.

CC‑A.6.3‑4 - Conservativity witness. For each species, the definition SHALL provide:

• a clear statement of what counts as a new commitment about the EntityOfConcern in the relevant discipline,
• and a sketch of how conservativity (EV‑3) is checked or approximated (e.g. via KD‑CAL entailment, proof or structural invariants).

CC‑A.6.3‑5 - Profile classification.

• Species that do not require a CorrespondenceModel MUST be marked as U.DirectEpistemicViewing.
• Species that do require such a model MUST be marked as U.CorrespondenceEpistemicViewing and SHALL:
  • document the shape of the CorrespondenceModel,
  • describe how witness epistemes ensure oplax naturality of compositions.

CC‑A.6.3‑6 - Separation from Retargeting and Mechanisms.

• Any species that may change entityOfConcernRef is not a conformant EpistemicViewing; it MUST be treated as U.EpistemicRetargeting (A.6.4) or as a different pattern.
• Any species that performs measurements, actuation, or other side‑effects MUST be declared as U.Mechanism/U.WorkEnactment and cannot be an EpistemicViewing.

#Mini-checklist (for defining a view)

When you introduce a new “view” in FPF, check:

1. Same EntityOfConcern? Does entityOfConcernRef stay the same? If not, this is Retargeting, not Viewing.

2. Which slots move? Have you listed exactly which SlotKinds you read/write, and shown that EntityOfConcernSlot is read‑only?

3. Conservative? Can you explain, in your discipline’s terms, why the view does not introduce new claims about the same EntityOfConcern?

4. Profile? Is this a self‑contained projection (U.DirectEpistemicViewing) or does it depend on a CorrespondenceModel (U.CorrespondenceEpistemicViewing)?

5. Context & viewpoint? Have you stated:

   • the EntityOfConcernClass for EntityOfConcernSlot,
   • the contexts/ReferencePlanes you assume,
   • and the viewpoint bundle (if any) you operate under?

If all answers are crisp and the invariants EV-0...EV-6 are satisfied, the pattern is a good candidate for U.EpistemicViewing.

#A.6.3:End

#Controlled Semantic Coarsening

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Placement. Controlled Semantic Coarsening is a specialization under A.6.3 U.EpistemicViewing for same-lineage coarsening from one source-bearing side into one coarsened rendering, whether the coarsening was planned before publication or discovered during review of a coarsened rendering that can be retained only under a narrower-use card. That source-bearing side may be one source episteme that remains governing, source publication, or declared source set with a stable source-set identifier and bounded membership; it is not an open corpus.

Builds on. A.6.3, A.6.3.CR, A.6.3.RT, E.17.EFP, A.6.P, E.8, E.10, E.19, and F.18.

Coordinates with. E.17.ID.CR, F.9, F.9.1, A.15, A.6.4, A.20, and A.21.

#Problem frame

EntityOfConcern preservation discipline. Controlled coarsening stays under entityOfConcernRef-preserving viewing only when the C.2.1 entityOfConcernRef remains stable. When the source-bearing side is a declared source set, its membership, loss account, and reopen condition must also be bounded; that source-set discipline does not substitute for same-EntityOfConcern preservation. Any entityOfConcernRef shift leaves this pattern for A.6.4.

Use this when. A summary, briefing, redaction, dashboard tile, lookup handle, didactic compression, or other readable coarsened rendering coarsens one source-bearing side by dropping or narrowing distinctions, recoverability, reliability transport, or admissible-use value, or when review discovers that the readable item can be retained only as a coarsened rendering.

Plain recognition line. A short version is useful only while the reader can still see what it came from, what it leaves out, and when to go back.

Controlled Semantic Coarsening governs one coarsened rendering that remains useful only because the source-bearing side stays identifiable, the admissible use is narrower, downstream use is non-admissible from the coarsened rendering alone, and escalation reopens that source-bearing side. It is the FPF governing pattern for that source-to-rendering relation. It is not a tag, token, U.* kind, publication face, carrier, bridge card, stance overlay, work plan, approval, or gate.