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

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

#Content

#Signature Stack & Boundary Discipline

Type: Architectural (A) Status: Stable Normativity: Mixed (normative only where explicitly marked; routing semantics live normatively in A.6.B) Placement: Part A → A.6.* (cluster overview; coordinates A.6.0 / A.6.1 / A.6.3 / A.6.B / A.6.5 / A.6.6 / A.6.7) Builds on: E.8 (authoring template), A.6.B (Boundary Norm Square — quadrant semantics & link discipline), A.6.0 (U.Signature), A.6.1 (U.Mechanism), A.6.3 (U.EpistemicViewing — views as episteme-level projections under viewpoints), E.17.0 (U.MultiViewDescribing), E.17 (MVPK — fixed face kinds & “no new semantics” publication), A.7 (Object≠Description≠Carrier), F.18 (promise/utterance/commitment), E.10.D2 (I/D/S vs Surface), E.10/L‑SURF (Surface token discipline) Purpose (one line): Keep boundary claims evolvable by routing each statement to the right layer of the Signature Stack and the right quadrant of the Boundary Norm Square (A.6.B).

Mint/reuse (terminology): Mints “Signature Stack”, “Boundary Discipline Matrix”, and “Claim Register” as local authoring aids; reuses existing FPF meanings of U.View/U.Viewpoint (E.17.0/A.6.3) and reserves “Surface” for PublicationSurface/InteropSurface (L‑SURF). The labels L/A/D/E used below are routing 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 routed claim set. If anything in this overview conflicts with A.6.B, A.6.B is authoritative.

Start here when. The dominant burden is API, protocol, contract, compliance, SLO/SLA, connector, or interface language that is mixing runtime behaviour, governance, and evidence into one undifferentiated boundary story.

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

Typical next owners. A.6.B for the quadrant law, A.6.C for contract unpacking, A.6.P, A.6.Q, or A.6.A for later lexical repair, and E.17 faces for audience-specific publication of the same routed claim set.

Common wrong escalations / reroutes. If the real burden is still cue preservation or route-bearing early articulation, reroute to A.16 / A.16.1; if you are already repairing qualified relation, quality-term, or action-invitation language, continue into A.6.P, A.6.Q, or A.6.A; if agent duties are being mixed into one contract sentence, split them through A.6.B rather than minting one more contract-soup paragraph.

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

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

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

#Problem frame

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

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

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

This cluster overview makes one disciplined move:

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

Terminology note (informative): In this pattern:

• Layer names a stratum in the boundary stack (Signature → Mechanism → Work/Evidence carriers → Publication).
• View (U.View) is an episteme‑level projection, not a file/document.
• Viewpoint (U.Viewpoint) is an intensional accountability spec that constrains views.
• Face (MVPK sense) is a named publication view kind (PlainView, TechCard, InteropCard, AssuranceLane) whose rendering lives on a PublicationSurface (carrier). Do not coin “signature/mechanism …Surface” terms; “Surface” is reserved for publication surfaces (L‑SURF).

#Problem

When boundaries are described without a routing discipline, four confusions dominate:

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

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

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

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

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

#Forces

#Solution — A stack + a routing matrix

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

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

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

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

The Signature Stack (as used in this cluster) is the ordered family of canonical claim layers for a boundary package. Each layer is a stable “landing zone” for one quadrant of statements (L/A/D/E), with a canonical home in the boundary’s artefacts/sections:

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

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

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

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

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

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

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

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

#AssuranceLane skeleton (informative)

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

Minimal content (suggested):

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

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

Example (conceptual, no tools):

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

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

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

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

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

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

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

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

Normative source. The canonical 2×2 square (axes, 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 not strong enough, because real sentences reuse the same surface words (“must”, “guarantees”, “valid”) across different logical roles. A 2×2 matrix is stronger because it arises from crossing two independent distinctions:

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

Operational summary (quadrant → canonical home in the stack):

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

Atomicity rule:

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

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

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

Informative example. Example rewrite (mixed → atomic):

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

After (routeable + lintable):

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

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

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

After (routeable + adjudicable):

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

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

#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 Surface token discipline (L‑SURF).

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 routed claim set (the authoritative L-* / A-* / D-* / 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 routed 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 / L‑SURF (face‑kind closure), a publication package that claims MVPK alignment MUST NOT mint additional MVPK face kinds (e.g., “EvidenceCard”, “NormsCard”) as if they were first‑class kinds; if you need local headings, keep them as sections within the canonical face kinds.

#“Contract” unpacking: avoid assigning agency to epistemes

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

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

In A.6 terms:

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

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

#Where statements go (routing examples)

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

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

Notes:

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

#Routing sanity rules (informative, concept-level)

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

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

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

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

#Tell (universal rule)

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

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

System: A “Payment Authorize” service.

• Signature layer (A.6.0).

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

• Mechanism layer (A.6.1).

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

• Realization/work layer.

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

• Publication faces (MVPK).

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

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

Routing example:

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

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

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

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

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

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

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

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

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

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

#Bias‑Annotation

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

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

#Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#Consequences

#Rationale

A boundary is simultaneously:

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

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

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

#SoTA‑Echoing (post‑2015 practice alignment)

Informative. Alignment notes; not normative requirements.

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

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

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

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

• Adapt — DDD bounded contexts / microservice contracts. Modern architecture practice keeps meaning local and makes crossings explicit. A.6’s stack and routing discipline provide a precise placement scheme for what is “inside the context contract” vs “at the entry gate” vs “governance duties” vs “observability evidence”.

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

• 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 contract 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 Object≠Description≠Carrier discipline: Uses A.7 to prevent category mistakes; ties evidence to carriers and publication faces to descriptions.
• Operationalises view/viewpoint accountability: Uses MVPK / U.MultiViewDescribing (E.17.0) so each face is a projection under a viewpoint, not a viewpoint‑free snapshot.
• Unpacks “contract” talk: Reuses F.18’s promise/utterance/commitment separation to keep agency and responsibility explicit.
• Connects to signature engineering patterns: A.6.5 (slot discipline) and A.6.6 (anchor/base discipline) can be read as “constructor/enabling” operations that help build well‑formed signatures by disciplined unpacking and grounding (they belong in the same stack discipline because they govern boundary construction).

#A.6: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 (Object≠Description≠Carrier), F.18 (promise/utterance/commitment), E.10.D2 (I/D/S vs Surface), E.10/L‑SURF (Surface token discipline) Purpose (one line): Provide a canonical 2×2 norm square that classifies boundary statements (L/A/D/E), constrains how each quadrant is written, and defines explicit cross‑quadrant reference rules so boundaries remain evolvable and audit‑ready.

#A.6.B:0 — Conventions

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

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

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

These labels are routing labels for statements, not MVPK face kinds and not pattern identifiers.

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

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

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

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

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

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

Modality family. A claim is either:

• Truth‑conditional: definitions, invariants, typing rules (“is”, “iff”, “∀”).
• Governance: permissions, prohibitions, obligations, commitments (“MUST/SHOULD/MAY”, “is permitted”, “is forbidden”, “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, Object≠Description≠Carrier, views under viewpoints). What is still needed is a single, reusable routing primitive that any boundary text can apply consistently and that other patterns can cite as a stable authoring module.

#A.6.B:2 — Problem

When authors cannot reliably answer two questions—

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

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

A boundary needs a minimal, stable classification that:

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

#A.6.B:3 — Forces

#Solution — the Boundary Norm Square

#Two independent distinctions

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

1. Modality family: Truth‑conditional vs Governance
2. Adjudication locus: 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 agent/role governance (duties, commitments, prohibitions).
• A is mechanism governance (permission/admission predicates: what the mechanism admits at application time). A-* is not an obligation on an actor; obligations belong in D-* and may reference A-*.

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

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

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

The quadrants have canonical “homes” 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 permission predicates).
• D → Norms & commitments layer: role‑anchored duties, commitments, publication/accountability duties (often rendered inside MVPK TechCard).
• E → Evidence bindings layer: work‑adjudicated effects tied to carriers and measurement conditions (authored canonically in an Evidence/Carriers section; commonly rendered inside MVPK AssuranceLane as a projection).

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

#A.6.B:5 — Quadrant specifications

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

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

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

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

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

Prohibitions.

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

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

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

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

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

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

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

Canonical form. Predicate style, e.g.:

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

Prohibitions.

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

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

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

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

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

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

Canonical form. A deontic statement MUST have an accountable subject (agent/role), e.g.:

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

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

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

Prohibitions.

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

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

Required references (explicit).

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

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

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

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

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

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

Prohibitions.

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

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

Required references (explicit).

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

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

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

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

If a claim’s meaning materially depends on another routed 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 allowed (and common). The square becomes operational when these links are used systematically.

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

When governance requires someone to comply with a gate:

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

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

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

When gate decisions must be observable:

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

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

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

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

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

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

#(A/E → L) Semantic grounding linkage

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

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

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

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

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

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

This keeps governance text from accidentally redefining semantics in prose.

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

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

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

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

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

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

Normative rule (no upward dependencies).

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

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

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

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

Guidance (informative):

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

#Archetypal Grounding (Tell–Show–Show)

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

#Tell (universal rule)

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

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

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

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

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

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

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

• L: metric definitions and invariants (e.g., what counts as AUROC; data partition invariants).
• A: admissibility gates (dataset license constraints; pinned environment constraints; seed policy).
• D: reviewer and author duties (publish required faces; use declared dataset version; retention duties for run artifacts).
• 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 license matches” (A), and both separate from “a run produced report carrier R with hash h” (E).

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

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

#Goal

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

1. atomic routed 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 forbid / flag).

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

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

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

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

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

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

Note (routing 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. Allowed directions (no upward deps):

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

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

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

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

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

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

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

#Anti-pattern (quick)

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

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

#Draft sentence (non-conformant)

“This API guarantees p95 latency < 200ms.”

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

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

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

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

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

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

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

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

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

#Triangle decomposition (explicit)

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

#Readable recomposition

Tech recomposition (contract bundle, short):

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

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

#Example 2 — Mechanical engineering (fit / coaxiality)

#Draft sentence (non-conformant)

“This fit ensures coaxiality.”

#Atomize + Route

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

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

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

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

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

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

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

#Readable recomposition

Tech bundle:

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

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

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

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Route

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

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

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

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

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

#Readable recomposition

Tech bundle:

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

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

#A compact “recomposition pattern” you can reuse verbatim

#Tech register (2–5 lines)

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

#Plain register (1 paragraph)

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

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

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

• Arch bias: favors explicit separation and explicit references; mitigated by allowing narrative faces while keeping commitments routed and referenced by ID.
• Gov bias: makes accountability explicit (D) and auditability explicit (E); mitigated by keeping evidence conceptual and carrier‑anchored rather than tool‑specific.
• Onto/Epist bias: insists on Object≠Description≠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 along two axes that are otherwise routinely conflated:

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

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

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

Informative. Alignment notes; not normative requirements.

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

• ISO/IEC/IEEE 42010:2022 (view/viewpoint discipline).

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

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

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

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

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

#A.6.B:15 — Relations

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

#A.6.B:End

#A.6.C — Contract Unpacking for Boundaries

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

#A.6.C:1 — Problem frame

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

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

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

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

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

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

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

#A.6.C:2 — Problem

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

1. Agency is not misattributed to descriptions (signatures, docs, specs, “interfaces”),
2. Governance statements (obligations/commitments) are distinguishable from admissibility gates and from semantic laws,
3. Operational “guarantees” become adjudicable via explicit evidence expectations, without smuggling evidence into semantics,
4. Multi-view publication (MVPK faces) does not create “multiple contracts” 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 so it becomes routable under A.6.B.

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

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

1. Promise Content (Promise content)

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

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

2. Utterance Package (speech act + published descriptions)

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

3. Commitment (Deontic accountability relation)

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

4. Work + Evidence (Adjudication substrate)

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

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

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

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

A helpful rewrite rule:

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

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

Treat “guarantee” as ambiguous until routed:

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

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

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

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

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

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

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

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

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

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

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

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

#A.6.C:5.1 — Tell

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

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

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

(A) Software API boundary

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

Unpack + route:

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

(B) Hardware interface boundary

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

Unpack + route:

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

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

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

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

Unpack + route:

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

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

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

Unpack + route:

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

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

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

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

#A.6.C:7 — Conformance Checklist

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

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

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

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

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

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

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

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

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

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

#A.6.C:9 — Consequences

Benefits

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

Trade-offs / mitigations

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

#A.6.C:10 — Rationale

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

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

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

Informative. Alignment notes; not normative requirements.

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

#A.6.C:12 — Relations

• Uses / is used by

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

• Coordinates with

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

#A.6.C:End

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

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

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

#Problem frame

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

• similar constructs proliferate under incompatible names;
• readers cannot tell what is declared (intension & laws) versus what is implemented (specification);
• cross‑context reuse lacks a canonical place to state applicability and lawful vocabularies.

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

#Problem

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

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

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

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

#Forces

#Solution — Define U.Signature once, reuse everywhere

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

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

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

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

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

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

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

#The Signature Block (universal form)

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

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

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

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

   Semantic roles of the SubjectBlock kinds (informative)

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

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

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

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

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

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

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

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

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

SlotSpec_i := ⟨SlotKind_i, ValueKind_i, refMode_i⟩

where:

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

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

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

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

An authorial SlotSpec table then reads:

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

#Profile specialisations (normative; structure‑preserving)

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

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

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

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

#Effect‑discipline vs handler semantics (normative split)

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

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

• I/D/S separation. A signature states intension and laws; Realizations (if any) carry specifications. Do not mix tutorial text or operational recipes into the Block. Do not include AdmissibilityConditions or run‑time admissions here.

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

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

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

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

#SignatureManifest (imports/provides; normative)

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

SignatureManifest fields (conceptual; concrete syntax is editorial):

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

Norms (boundary hygiene):

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

The A.6.0 four‑row Block remains the source of truth for meaning (Vocabulary/Laws/Applicability). The manifest only declares dependency edges and exported names.

• Token hygiene. Do not mint new U.* tokens inside a Signature without a DRR; prefer referencing existing Kernel/Extension U.Types.

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

#Specialisation knobs (for downstream patterns)

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

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

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

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

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

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

#Archetypal Grounding (Tell–Show–Show)

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

#Bias‑Annotation (lenses & defaults)

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

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

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

#Conformance Checklist (normative)

#Consequences

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

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

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

#Rationale

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

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

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

#Relations

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

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

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

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

#A.6.0:End

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

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

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

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

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

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

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

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

#Problem frame

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

#Problem

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

#Forces

Locality vs transport. Semantics are context‑local; crossing contexts is Bridge‑only (Part F/B.3); penalties hit R/R_eff; F/G invariant.

Expressivity vs legality. Rich operators vs CHR legality and CG‑Spec (no ordinal averages; lawful unit alignment).

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

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

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

#Solution

#Mechanism Intension

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

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

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

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

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

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

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

• LawSet. Equations/invariants (no proofs here). Admissions/eligibility tests belong under AdmissibilityConditions, not here. Laws MUST be compatible with CHR legality where numeric comparison/aggregation is induced. Examples: • USM: serial intersection; SpanUnion only where a named independence assumption is satisfied (state features/axes, validity window, evidence class); translate uses declared Bridges; Γ_time is mandatory.
  • UNM: scale‑appropriate transforms — ratio→positive‑scalar; interval→affine; ordinal→monotone; nominal→categorical; tabular:LUT(+uncertainty).
  (A conformant U.Mechanism publication MUST NOT mint a new Kernel token for “certificate”; if such a type is later required, it MUST follow DRR/LEX minting.)

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

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

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

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

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

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

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

• Compatibility with A.6.* A.6.1 is a strict specialisation of A.6.0: the canonical four‑row Signature Block remains the source of truth; additional Mechanism fields (algebra, carriers, evidence) must not introduce new semantic rows or shadow the signature’s imports/provides.

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

Intent. Provide structure‑preserving relations & constructors between mechanisms.
Definitions.

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

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

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

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

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

#Multi-level specialisation ladders (normative)

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

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

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

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

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

5. No upward leakage. A top‑level mechanism in a ladder SHOULD mention only the most general ValueKinds required by its SlotSpecs and Laws. Domain‑specific artefacts (e.g., decision‑theory policies, OEE generators, evaluation packs) belong in specialised mechanisms that refine slots and/or add operations.

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

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

#U.MechAuthoring - Instantiation template

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

#MechFamilyDescription & MechInstanceDescription

• MechFamilyDescription: {Mechanism.Intension, Realizationα, Realizationβ, …} — each Realization may tighten (never relax) Laws (Liskov‑style).

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

#Defaults

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

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

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

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

#60‑second didactic script

“To mint a mechanism, fill a Mechanism.Intension: declare SubjectBlock (SubjectKind, BaseType, SliceSet, ExtentRule, ResultKind?) and SlotSpecs (use a SignatureManifest if it is reusable); then OperationAlgebra/Laws/AdmissibilityConditions and Γ_time; define Transport (Bridge/CL with penalties to R only), and Audit (UTS + Path pins). USM and UNM are already such mechanisms; the same template births comparison, scoring, and publication mechanisms—safely bound to CG‑Spec—without leaving the kernel grammar.”

#Quick “builder’s” checklist (author‑facing)

1. Draft a run↔design charter: why this Mechanism, which guard surfaces and comparability are in scope; which DesignRunTag/CtxState.locus boundary it mediates; is a Γ_m (CAL) builder needed?

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

• Bind CHR legality & CG‑Spec when comparing/aggregating (ComparatorSet, ScaleComplianceProfile (SCP), MinimalEvidence, Γ‑fold).

Ship UTS + G.10; wire G.11 telemetry (PathSlice‑keyed); ensure penalties route to R_eff only.

#Archetypal Grounding

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

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

#Bias-Annotation (informative)

This pattern intentionally biases Mechanism authoring toward explicit contracts, context-local semantics, and auditable reuse.

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

#Conformance Checklist (normative)

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

#Consequences (informative)

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

#Rationale (informative)

Anchoring mechanisms in an explicit Signature → Realization discipline (A.6.0 SignatureManifest + CC‑UM.2 monotonicity/opacity) keeps reuse safe: signatures are the contract; realizations may vary but cannot relax laws. It also makes cross‑context (Bridge) crossings explicit and costed on R_eff (never F/G).

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

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

#Contemporary references (post-2015 sources)

SoTA binding note (E.8:11). No dedicated SoTA‑Pack(Mechanisms) (G.2) is registered at the time of writing; until one exists, this section cites primary post‑2015 sources directly and SHOULD later be reduced to ClaimSheet/CorpusLedger/BridgeMatrix ids (to avoid forking untracked SoTA narrative).

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

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

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

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

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

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

#Alignment with A.6.1 fields and concepts

#Adopt / Adapt / Reject summary

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

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

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

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

#Holonic repeatability

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

#Relations (quick pointers)

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

#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‑governed morphisms between epistemes. An EFEM morphism rewrites episteme components (ClaimGraph, describedEntityRef, 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 DescribedEntitySlot (DescribedEntityChangeMode ∈ {preserve, retarget}) as defined by C.2.1 U.EpistemeSlotGraph.

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

Builds on. A.6.0 U.Signature (subject/vocabulary/laws/applicability); A.6.1 U.Mechanism; A.6.5 U.RelationSlotDiscipline; C.2.1 U.Episteme — Epistemes and their slot graph; E.10.D2 (I/D/S discipline); C.3.* (Kind‑CAL / KindBridge for described‑entity classes).

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

#Problem frame

FPF has many operations that transform knowledge artifacts without directly doing work in the world:

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

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

Without a universal pattern for such morphisms:

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

#Problem

Concretely, without EFEM:

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

2. Described entity 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 DescribedEntityChangeMode discipline we get silent breaks in “describedEntity”: an operation that looks like a harmless format change may in fact surreptitiously change the entity‑of‑interest.

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

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

The result: engineers and tool builders can no longer tell when they are allowed to transform epistemes without changing what is being claimed about the world, nor what needs to be witnessed by Bridges and CL‑penalties when describedEntity 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 describedEntity‑preserving; reinterpretation along a KindBridge is describedEntity‑retargenting. Both are important, but they must be distinguished and witnessed differently.

• Conservativity vs usefulness. EFEM should be conservative: no new intensional commitments beyond what input epistemes already entail. At the same time, we need transformations that can factor, aggregate, or normalise content, which may drop some information or change its representation.

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

• I/D/S strict distinction. Intension (I) is not itself an episteme; …Description and …Spec are epistemes with a DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. EFEM must support operations on D/S epistemes while keeping the I/D/S layering intact (A.7, E.10.D2).

#Solution — define U.EffectFreeEpistemicMorphing once

#Informal definition

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

• operate only on the components of an episteme as fixed in C.2.1 U.EpistemeSlotGraph (ClaimGraph, slots for described entity, grounding holon, viewpoint, representation/reference schemes, meta);
• are effect‑free (no Work, no Mechanism application, no mutation of systems or carriers);
• are conservative in what they claim about the described entity (no new intensional commitments beyond logical consequences under the declared ReferenceScheme);
• are functorial (identities and composition behave as expected on the category of epistemes);
• declare an explicit DescribedEntityChangeMode ∈ {preserve, retarget}, controlling how DescribedEntitySlot (and associated subjectRef) behaves.

The 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 DescribedEntityChangeMode = preserve.
• U.EpistemicRetargeting (A.6.4) — EFEM with DescribedEntityChangeMode = 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⟩        // carrier 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 (subject reference; for D/S epistemes this is DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ per IDS‑13 (DescriptionContext discipline; C.2.1 §6.1 / E.10.D2)).
  • U.Morphism (arrow in Ep).
  • U.DescribedEntityChangeMode = {preserve, retarget} (enumeration; no new Kernel type for “DescribedEntity”).

• 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.
  • describedEntityChangeMode(f) : U.DescribedEntityChangeMode // 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 (DescribedEntitySlot, 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 normative: any morphism advertised as an instance of U.EffectFreeEpistemicMorphing SHALL satisfy them.

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

For any EFEM morphism f : X→Y:

1. Typed objects. 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 DescribedEntitySlot, 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);
   • describedEntityRef(E) : U.EntityRef — value of the RefKind for DescribedEntitySlot;
   • 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 DescribedEntityChangeMode. Each EFEM species declares a fixed DescribedEntityChangeMode ∈ {preserve, retarget}. At the level of individual morphisms:

   • if describedEntityChangeMode(f) = preserve, then describedEntityRef(Y) = describedEntityRef(X) (and usually groundingHolonRef(Y) = groundingHolonRef(X) unless an explicit Grounding Bridge is declared);
   • if describedEntityChangeMode(f) = retarget, then describedEntityRef(Y) ≠ describedEntityRef(X) in general and a KindBridge between the two described entities MUST be named (A.6.4 / F.9).

4. SubjectRef compatibility. For D/S epistemes (…Description / …Spec), subjectRef(E) is a DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ (E.10.D2). EFEM species SHALL state how subjectRef transforms in terms of these components (usually: preserve or explicitly adjust ViewpointRef while preserving DescribedEntityRef 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 SHALL be modelled as a U.Mechanism/U.Work that produces new epistemes, which may then be related by EFEM morphisms.

#P2 — Conservativity (no new intensional commitments)

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

The set of claims about the described entities that can be read from Y SHALL NOT introduce new atomic commitments beyond those that are logical consequences of the claims read 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 described entities 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 describedEntityChangeMode(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 the object it describes (value of DescribedEntitySlot, i.e. describedEntityRef(E)) as in the mathematical layer for epistemes. EFEM instances with describedEntityChangeMode(f) = preserve are vertical morphisms for α (α(f) = id), while those with describedEntityChangeMode(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, describedEntityRef, 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))
   describedEntityChangeMode(h) = combine(describedEntityChangeMode(f), describedEntityChangeMode(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 MUST respect 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, DescribedEntityChangeMode 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 MUST itself be specified as an EFEM morphism and the composite be idempotent.

#P5 — Applicability, scope & compatibility

Each EFEM species publishes an Applicability clause:

• EoI / described entity class. A constraint on the allowed ValueKind of DescribedEntitySlot (via EoIClass ⊑ 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 supported RepresentationScheme/ReferenceScheme pairs and any required CorrespondenceModels.

• Viewpoint discipline. For Descr/Spec epistemes, EFEM SHALL specify which U.Viewpoints (E.17.0) it supports 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 EoIClass, missing grounding holon, incompatible Viewpoint) is non‑conformant: a conformant implementation MUST reject such attempts or model 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 I/D/S and Viewpoint/MVPK layers.

#Typed formalisation Specify_DS : D→S (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 describedEntityRef(X) : U.MethodRef, content(X) : U.ClaimGraph_D, viewpointRef(X) an engineering viewpoint (TEVB), ReferenceScheme_D.
• Codomain: Y = U.MethodSpec episteme with the same describedEntityRef(Y) = describedEntityRef(X), viewpointRef(Y) = viewpointRef(X), more structured content(Y) : U.ClaimGraph_S, stronger ReferenceScheme (explicit pre/post, obligations).

Specify_DS is a species of EFEM:

• describedEntityChangeMode(Specify_DS) = 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 underlying Method Intension; if the spec makes stronger claims, that is modelled as creating a new Intension with its own D/S pair, 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/E.10.D2 strict distinction: I→D (Describe_ID) is not itself an episteme→episteme morphism, but Specify_DS is; EFEM supplies its laws.

#Internal normalisation of a View (species of EFEM, describedEntityChangeMode = 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:

• describedEntityRef(X) = describedEntityRef(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 describedEntityChangeMode(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, describedEntityChangeMode = retarget)

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

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

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

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

#Worked SlotSpec example (engineering SystemDescription episteme kind)

(informative)

To make the SlotKind/ValueKind/RefKind discipline and EFEM laws concrete, consider a simple engineering U.EpistemeKind for system descriptions over EoIClass ⊑ U.Entity with EoIClass = 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 DescribedEntitySlot/GroundingHolonSlot are preserved.

Two typical EFEM species over this kind are:

• Specify_DS_Sys : SystemDescription → SystemSpec — a DescribedEntityChangeMode = preserve species that:

  • reads DescribedEntitySlot, 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 Intension (A.7/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 DescribedEntityChangeMode = 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 described system.

In later A.6.3/A.6.4/E.17.* patterns, concrete EpistemeKinds (for specific engineering description/specification 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 DescribedEntitySlot, GroundingHolonSlot, etc., and their ValueKind/RefKind, as per A.6.5 and C.2.1; they never use unnamed tuple positions or “role 1/2/3”. 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.

• I/D/S respect. EFEM never collapses Intension with Description/Spec: I→D and D→S operations are typed explicitly and either (i) conform to EFEM laws where they are episteme→episteme, or (ii) remain separate morphism classes (A.7) while being described as EFEM‑conformant.

#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 described entity) 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 artefacts, across KD‑CAL, MVPK, E.TGA, discipline packs, can now be defined as species of EFEM, instead of each family re‑inventing its own law set.

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

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

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

• Better didactics. The old “semantic triangle” becomes a didactic projection of EFEM over the EpistemeSlotGraph: EFEM + C.2.1 explain precisely what the triangle was trying to gesture at (symbol, concept, object), 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 a legal episteme→episteme transform is.

Why insist on DescribedEntityChangeMode?

Because almost all subtle errors in multi‑view reasoning show up as silent retargeting: a transform that appears to keep the same object‑of‑talk 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 (describedEntity‑preserving EFEM) and A.6.4 U.EpistemicRetargeting (describedEntity‑retargering EFEM).

• Constrained by. A.6.5 U.RelationSlotDiscipline (SlotKind/ValueKind/RefKind); C.2.1 U.EpistemeSlotGraph (episteme components, ReferencePlane); E.10.D2 (I/D/S discipline); 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 D/S epistemes under Viewpoints); E.17 (MVPK — publication as species of Viewing/EFEM); E.18 (E.TGA StructuralReinterpretation and other transductions over epistemes); KD‑CAL/LOG‑CAL rules that reason about episteme transforms categorically.

#A.6.2:End

#U.EpistemicViewing — describedEntity‑preserving morphism

One‑line summary. U.EpistemicViewing is the describedEntity‑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 occupant of DescribedEntitySlot in C.2.1).

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/E.10.D2 (I/D/S discipline, DescriptionContext); C.2.1 U.Episteme — Epistemes and their slot graph; C.2 (KD‑CAL/LOG‑CAL, subjectRef, ReferencePlane).

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

#Problem frame

Engineers and researchers constantly need views of the same knowledge artefact:

• 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/specification;
• 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 which intend to:

• keep the DescribedEntity fixed (DescribedEntitySlot 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 entity and grounding holon.

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

• effect‑free (no Work/Mechanism side‑effects),
• describedEntity‑preserving (no silent retargeting),
• conservative (no new intensional commitments about the same entity),
• and functorial (compose cleanly in multi‑step pipelines).

#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 object‑of‑talk (retargeting). A Fourier‑style transform or a StructuralReinterpretation in E.TGA can quietly drift from “view of S” into “view of a different S′”, without declaring a KindBridge.

2. “View” vs “viewpoint” vs “surface” 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 surface (rendered document or GUI). Without a clear episteme‑level notion of viewing, MVPK and E.17.0 cannot cleanly separate these layers.

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

   • change describedEntityRef (switching to a subsystem or a function),
   • change groundingHolonRef (different plant or runtime),
   • or smuggle in new intensional claims. Without explicit laws on 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 over the same described entity (α : 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 support degrade.

#Forces

• Same entity, different concerns. Stakeholders want different slices of the same description/specification, sometimes under different viewpoints, without re‑identifying the entity (system, method, role, service) being described.

• 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 must be supported, but with different obligations.

• Conservativity vs expressivity. A view must not introduce new commitments about the described entity, 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.

• I/D/S strictness. …Description and …Spec are epistemes with DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. Viewing must work over these DescriptionContexts without collapsing Intension (I) into episteme or confusing D/S with publication surfaces.

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

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

#Informal definition

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

• takes an input episteme X and produces an output episteme Y,
• preserves the occupant of DescribedEntitySlot (describedEntityRef(Y) = describedEntityRef(X)),
• may refine or re‑express content : U.ClaimGraph, viewpointRef, representationSchemeRef, and referenceScheme,
• is effect‑free and conservative (no new intensional claims about the same described entity),
• and composes functorially with other epistemic viewings.

In C.2.1 terms U.EpistemicViewing behaves like a lens/optic over the episteme slot graph: it focuses on some SlotKinds (typically ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot) while preserving DescribedEntitySlot (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⟩      // carrier 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 Slot‑level 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:
  • DescribedEntitySlot (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 describedEntityChangeMode = 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 occupant of DescribedEntitySlot is unchanged.

#Laws (EV‑0…EV‑6, over C.2.1 components)

All laws below are in addition to A.6.2’s EFEM laws P0–P5 and SHALL be read directly against C.2.1 components and A.6.5 SlotSpecs.

EV‑0 - Species & DescribedEntityChangeMode.

• Any morphism v:X→Y declared as U.EpistemicViewing MUST:
  • be a species of U.EffectFreeEpistemicMorphing (A.6.2), and
  • declare describedEntityChangeMode(v) = preserve.
• Consequently:
  • DescribedEntitySlot has the same ValueKind and RefKind in the episteme kind of X and Y (same EoIClass ⊑ U.Entity);
  • describedEntityRef(Y) = describedEntityRef(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 (DescribedEntitySlot, 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. At the SlotKind level:

   • DescribedEntitySlot is read‑only (no change in describedEntityRef).
   • 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 = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. EpistemicViewing MUST:

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

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

• It may change only C.2.1 components of the codomain episteme:
  • content : U.ClaimGraph (e.g. filtering, aggregation, normalisation),
  • viewpointRef (under the constraints in EV‑1),
  • representationSchemeRef and ReferenceScheme (within a fixed representation family or under a declared CorrespondenceModel),
  • meta‑components (edition, provenance, status flags).
• It MUST NOT:
  • invoke U.Mechanism or U.WorkEnactment (measure, execute, actuate),
  • create or modify U.PresentationCarrier (no direct publishing to surfaces),
  • 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 artefacts consumed by the EpistemicViewing morphism.

EV‑3 - No new intensional claims about the same DescribedEntity.

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

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

Then:

• The set of claims about <describedEntityRef, groundingHolonRef> obtained by reading content_Y through referenceScheme_Y MUST NOT strictly extend what is already entailed, in KD‑CAL/LOG‑CAL, by content_X read 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 same described entity are introduced.
• Any intended strengthening of behavioural or structural commitments about the same entity is not a valid EpistemicViewing; it must be modelled either as:
  • a change in Intension (new D/S pair under A.7/E.10.D2), or
  • an A.6.4 U.EpistemicRetargeting plus a new Intension.

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 objects) that squares commute up to declared isomorphism (oplax naturality is allowed, but corrections are deterministic and reproducible),
   • describedEntityRef and groundingHolonRef remain as in EV‑1; any transfer across contexts/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:

• describedEntityRef,
• 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 DescribedEntity 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 EoIClass ⊑ U.Entity (ValueKind of DescribedEntitySlot),
   • permitted groundingHolonRef classes and ReferencePlanes,
   • admissible viewpointRef ranges (possibly a named U.ViewpointBundle),
   • supported representationSchemeRef families.
2. For D/S epistemes in a U.MultiViewDescribing family (E.17.0):
   • preserve DescribedEntityRef 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 DescribedEntity (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 describedEntityRef 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‑level artefact, 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 constructions of new Intensions.

#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:
  • describedEntityRef(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:
  • describedEntityRef(Y) = describedEntityRef(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:

• describedEntityChangeMode = 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 describedEntityRef (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 laws.

#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 describedEntityRef 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:
  • describedEntityRef(Y) = describedEntityRef(R) = describedEntityRef(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 EpistemeSlotGraph.

#Consequences

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

  • “view of the same entity” 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 I/D/S discipline.

• Slot‑level 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 DescribedEntitySlot is preserved. This removes ambiguity around “subject/object” changes and supports 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‑interest;
  • 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 described entities Ref via α : Ep → Ref. EpistemicViewing corresponds to vertical morphisms that preserve α. Their behaviour closely tracks profunctor optics: the DescribedEntitySlot 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 laws 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 artefacts, 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 in intensional terms (no new commitments),
  • any strengthening or change of described entity is explicitly modelled as retargeting or Intension 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 laws.

#Conformance checklist (normative)

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

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

CC‑A.6.3‑2 - Slot‑level read/write discipline. For each species of EpistemicViewing, authors MUST:

• list the SlotKinds it reads (typically DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot),
• list the SlotKinds it writes (typically ClaimGraphSlot, optionally ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot, and meta),
• assert explicitly that DescribedEntitySlot 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 D/S epistemes). When domain/codomain epistemes are …Description/…Spec:

• viewing laws SHALL be phrased in terms of DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩,
• DescribedEntityRef 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, authoring SHALL provide:

• a clear statement of what counts as a new intensional claim in the relevant discipline,
• and a sketch of how conservativity (EV‑3) is checked or approximated (e.g. via KD‑CAL entailment, proof obligations, 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 describedEntityRef 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 authors)

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

1. Same described entity? Does describedEntityRef 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 DescribedEntitySlot is read‑only?

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

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 EoIClass for DescribedEntitySlot,
   • the contexts/ReferencePlanes you assume,
   • and the viewpoint bundle (if any) you operate under?

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

#A.6.3:End

#ConservativeRetextualization — same-described-entity textual re-expression

Placement. Specialization under A.6.3 U.EpistemicViewing for same-described-entity textual re-expression.
Builds on. A.6.3 U.EpistemicViewing; A.6.2 U.EffectFreeEpistemicMorphing; A.7; E.10.D2; E.17.0; E.17; F.9; F.18; E.10.
Coordinates with. ExplanationFaithfulnessProfile; RepresentationTransduction; E.17.ID.CR ComparativeReading; A.6.4 U.EpistemicRetargeting; B.5.2; A.15.

One-line summary. ConservativeRetextualization is a same-described-entity textual re-expression of an episteme that stays inside A.6.3 U.EpistemicViewing: it may shorten, reorder, filter, translate, or restate claims, but it does not silently change describedEntityRef, add new claims about that entity, or hide bridge work.

#Problem frame

Teams constantly need a second textual form of the same episteme:

• an internal technical statement rewritten as an engineer-manager-readable report;
• a longer source note rewritten as a shorter working summary;
• a source-language statement rewritten into another natural language;
• a dense claim set rewritten as a filtered report that keeps only one declared slice.

These transforms are often treated as harmless editing. In practice they can quietly drift into hidden reinterpretation, hidden bridge work, hidden explanation, or even hidden retargeting. FPF already has A.6.3 for same-described-entity conservative viewing. What is still needed is a focused named pattern that states when a textual rewrite remains only a conservative viewing case under A.6.3.

#Problem

Without a dedicated pattern for conservative textual re-expression:

1. report, summary, translation, and filtered rewrite cases are handled ad hoc;
2. authors treat textual simplification as if it were automatically conservative;
3. the boundary to explanation-facing surfaces stays blurry;
4. correspondence-mediated rewrites are not distinguished from direct rewrites;
5. later reviewers cannot tell whether the result is still a view of the same described entity or a new interpretive artefact.

#Forces

• Same entity, different wording. Readers need different textual forms without reopening the described entity.
• Compression vs loss visibility. Shorter or plainer forms are often useful, but omission and attenuation must stay explicit.
• Direct vs correspondence-mediated rewrites. Some rewrites read from one source episteme; others depend on a declared CorrespondenceModel.
• Textual focus vs family creep. The pattern should cover same-entity textual re-expression, not explanation, not representation-wide shifts, and not retargeting.
• Publication discipline. Admissible faces and surfaces still matter even when the transform looks like "just a rewrite."

#Solution — same-described-entity textual re-expression under A.6.3

#Informal definition

ConservativeRetextualization is a named pattern specialized under A.6.3 U.EpistemicViewing for textual re-expression of the same described entity.

It preserves describedEntityRef, keeps the transform effect-free, and allows only claim-preserving or explicitly loss-declared rewriting of already available content.

It may change register, ordering, textual density, language, emphasis, or local wording. It may not silently introduce new claims, new bridge licences, new downstream authority, or a changed object-of-talk.

#Pattern, case, and publication distinction

ConservativeRetextualization is an intensional pattern and a named specialization under A.6.3. Concrete same-described-entity rewrites are passive episteme-level cases or publication texts reviewed under this pattern; the pattern itself does not act, decide, or publish.

This distinction matters because the pattern governs how a rewrite is recognised, justified, and checked. It does not require every short report paragraph, summary line, or translation sentence to carry a giant standalone record.

#Local working vocabulary

This pattern repeatedly uses a small working vocabulary.

• Source slice = the already available pinned or otherwise reviewable textual material being restated.
• Published slice = the resulting textual rendering that remains under same-described-entity discipline.
• Ordinary case = a reviewable same-entity rewrite where source tether, omission notes, and reroute conditions stay readable without a heavyweight review record.
• Load-bearing case = a case where dispute, policy, assurance, correspondence burden, or cross-context reliance makes a fuller record worth publishing.

These terms are only local reading aids. They do not create new owners, new publication faces, or a second semantic layer.

#Scope and exclusions

In scope

• same-described-entity report rewrite;
• same-described-entity summary;
• same-described-entity translation between natural-language surfaces;
• declared filtering or foregrounding of already-present claims in textual form.

Out of scope

• any change of describedEntityRef or hidden change of object-of-talk (A.6.4);
• explanation surfaces whose main purpose is explanatory rendering rather than same-entity rewrite (ExplanationFaithfulnessProfile);
• representation-regime changes such as text→table, text→diagram, or text→latent form (RepresentationTransduction);
• abductive, bridge-mediated, or route-bearing work that introduces new claims rather than restating available ones.

#Reader guidance

Use this pattern when the object-of-talk stays fixed and the published result still remains textual.

• If the main change is explanatory, move to ExplanationFaithfulnessProfile.
• If the main change is a representation-scheme shift, move to RepresentationTransduction.
• If the described entity changes, move to A.6.4.

#What a reviewer checks first

A reviewer usually does not begin by filling every field name. The first useful questions are simpler:

1. Is the published result still about the same described entity?
2. Is the result still textual, or has it become explanation or representation change?
3. Can the reader see what was omitted, softened, or foregrounded?
4. If correspondence is doing work, is that burden visible rather than hidden in fluent prose?
5. If any answer is doubtful, is the reroute path explicit?

Only after these questions are answered does a fuller load-bearing review record usually become worth writing.

#Working-model first; explicit review record only when the case is load-bearing

Most same-described-entity textual rewrites should stay human-usable. This pattern therefore follows E.14’s working-model-first discipline: ordinary report, summary, or translation cases do not need a giant inline metadata block. What they do need is enough explicitness that a reviewer can still tell what stayed the same, what was omitted, and where the case would have to reroute.

Ordinary case (default). For everyday same-described-entity rewrites, it is usually enough that the text or its surrounding publication keeps explicit:

• which source material is being re-expressed;
• that describedEntityRef remains preserved;
• whether the case is direct or correspondence-mediated when that is not obvious;
• what omissions or attenuation matter for the reader;
• where the case exits if it has turned into explanation, representation shift, retargeting, or world/gate-bearing material.

Explicit review record (only for load-bearing cases). A fuller record is warranted when the case is assurance-facing, gate-adjacent, cross-context, correspondence-heavy, policy-bearing, or likely to be disputed. The record may inherit host ids and already-pinned metadata instead of restating them inline. When published, that record normally captures:

• transform placement (landingForm = specialization under A.6.3, hostOwner, sourceForm, targetForm, changeLocus);
• preservation context (describedEntityPolicy = preserve, boundedContextPolicy, viewpointPolicy, referenceSchemePolicy, representationSchemePolicy, groundingPolicy, referencePlanePolicy);
• claim and publication discipline (claimPolicy, claimScopePolicy, publicationScopePolicy, reliabilityTransportPolicy, pinningPolicy, provenancePolicy, lossProfile);
• continuity and bridge discipline (claimContinuityClass, microtheoryContinuityClass, onticContinuityClass, bridgeRequirement, conservativityWitness);
• downstream and admissibility discipline (worldContactPolicy, evidencePolicy, gatePolicy, workCrossing, upstreamOwner, downstreamOwner, admissibleFaces, admissibleSurfaces, compositionLaw, reopenCondition);
• naming and presentation discipline (publicNamePolicy).

The point of this record is not bureaucratic completion for every paragraph. It is to make load-bearing cases reviewable without hiding meaning in style, topic familiarity, or editor intuition.

#Ordinary admissibility defaults

Default admissibility for ordinary same-described-entity textual cases:

• primary admissible faces are Plain and Tech;
• bounded report-only use is lawful when source pins, provenance, loss notes, and same-described-entity conservativity remain visible;
• Interop use is lawful only when the host explicitly permits source-pinned, text-preserving export without added semantics;
• Assurance or gate-bearing use is not default and requires host-explicit policy plus source-pinned conservativity without hidden strengthening.

#Direct and correspondence-mediated profiles

Direct ConservativeRetextualization

• source and target are textual re-expressions of one source episteme;
• no CorrespondenceModelRef is needed;
• the main burden is explicit loss/provenance discipline.

CorrespondenceConservativeRetextualization

• the target text is derived from a declared correspondence between epistemes or views of the same described entity;
• CorrespondenceModelRef is required;
• the result remains under A.6.3 only if the correspondence supports same-described-entity conservativity and no new claims are imported beyond the declared witness set.

Cross-language translation is not automatically direct. If the translation depends on declared correspondence, reference-scheme mediation, or bounded equivalence notes, it must be treated as correspondence-mediated rather than disguised direct rewriting.

#Recurring same-entity textual moves

The pattern covers a small family of recurring textual moves as long as the same described entity remains explicit:

• Register shift — a technical statement is rewritten into plainer engineer-manager prose without changing what is being said about the same entity.
• Summary or filtered restatement — a source note is shortened or focused on one declared slice, with omissions stated rather than hidden.
• Cross-language restatement — the same source claim is restated in another natural language while the same source tether and same-entity line remain explicit.
• Correspondence-supported textual synthesis — one textual rendering is produced from declared same-entity correspondences without importing extra bridge or substitution burden.

These are recurring move shapes, not separate owners. The host relation remains the same: same-described-entity textual re-expression under A.6.3.

#Shared conservative retextualization law packet

#A.6.3.CR:4.5.a. Preservation law

A case under ConservativeRetextualization preserves the same described-entity line, the declared bounded context, and the already available claim-bearing source while changing wording, register, language, ordering, or density. It states what remains preserved about claim scope, publication scope, pins, provenance, grounding, and ontic scaffold, and it says whether the case is Direct or Correspondence.

#A.6.3.CR:4.5.b. Loss and reliability law

A reviewed case makes explicit what is omitted, shortened, foregrounded, or attenuated by the rewrite. Reliability transport may remain source-bounded or be explicitly downgraded, but it must never be silently strengthened by cleaner prose, stronger rhetoric, or management-facing polish.

#A.6.3.CR:4.5.c. Authority and handoff law

A case reviewed under this pattern stays same-entity and episteme-level. It does not own explanation governance, bridge stance, retargeting, gate authority, or work enactment. If the rewrite becomes explanatory, bridge-bearing, gate-bearing, or world-facing, the case must hand off to the appropriate downstream owner and say so explicitly.

#A.6.3.CR:4.5.d. Composition and reopen law

Repeated direct rewrite over the same source line may be idempotent, but heterogeneous rewrites and correspondence-mediated rewrites are generally order-sensitive. A reviewed case must reopen whenever correspondence support, source pins, provenance, admissible-face assumptions, or same-described-entity conservativity stop being explicit.

#A.6.3.CR:4.5.e. Non-collapse note for correspondence

Correspondence-mediated retextualization does not by itself grant bridge licence, substitution licence, or comparative-reading licence. If the case needs those burdens, they must be declared separately rather than being smuggled in through correspondence language.

#A.6.3.CR:4.5.f. Local conservativity witness for borderline textual cases

For borderline textual rewrites, a reviewer treats the case as no longer conservative under this pattern unless each point below remains visibly preserved or is explicitly loss-declared with the reroute path stated.

• Modality and force. A rewrite may not silently turn possibility, uncertainty, bounded scope, or hypothesis language into stronger commitment.
• Caveats and qualifications. A rewrite may not quietly remove conditions, exception notes, uncertainty markers, or temporal qualifiers that still matter for reading the same source.
• Reliability posture. Cleaner prose, better ordering, or manager-facing polish may not silently raise confidence, warrant strength, or readiness for action.
• Bridge and substitution burden. Same-entity textual fluency may not import cross-context equivalence, substitution, or comparative-reading licence unless that burden is declared elsewhere.
• Alternative preservation. A rewrite may not collapse open alternatives, rival hypotheses, or declared plurality into one apparently settled reading unless the loss is stated and still lawful under this pattern.

This witness is local to ConservativeRetextualization. It does not replace the broader conservativity laws of A.6.3; it makes them inspectable for textual rewrites where fluent prose can otherwise hide strengthening.

#Archetypal Grounding

#Same-described-entity report rewrite

Source note slice. Service S exceeded the latency threshold in the evening batch window. Trace T-44 and dashboard pin D-17 show the spike. Two low-confidence hypotheses remain open.

Published report slice. Evening-batch latency for Service S exceeded the threshold. Source pins: Trace T-44, Dashboard D-17. Low-confidence hypotheses are omitted here and remain in the pinned source note.

This is a lawful direct ConservativeRetextualization because the described entity stays fixed, the report remains textual, and the omission is stated rather than hidden. In ordinary internal use, this often needs only source pins plus visible omission notes rather than a full explicit review record.

#Ordinary inherited-pin summary

Pinned source cluster. Incident note N-14, trace T-44, and dashboard card D-17 are already published together under one incident review bundle.

Published stand-up slice. Evening-batch latency again exceeded the threshold for Service S. See N-14 / T-44 / D-17 for the pinned source cluster.

This is still a lawful ordinary case even though the short stand-up slice does not restate every pin and qualifier inline. The didactic point is that lightweight use may inherit already-published pins and provenance when the tether stays visible to the reader.

#Same-described-entity rewrite via declared correspondence

Source design slice. Cooling loop CL-2 preserves safe temperature margins during standard load.

Source safety slice. Cooling loop CL-2 maintains the temperature condition required for hazard-control claim HC-7 during standard load.

Published joint-review slice. For standard load, Cooling loop CL-2 is described in both the design and safety views as maintaining the required temperature condition. This summary relies on CorrespondenceModel CM-12 and does not add claims beyond that declared overlap.

The synthesis may stay in this pattern only if the source relation remains explicit and the text does not silently strengthen claims beyond the declared correspondence-supported overlap. Because correspondence support is load-bearing here, a fuller explicit review record is usually warranted.

#Cross-language re-expression without hidden bridge work

Source slice. The backup controller stays in passive watch mode until the primary loop fails two consecutive heartbeat checks.

Published slice. Резервный контроллер остаётся в режиме пассивного наблюдения, пока основной контур не пропустит две последовательные проверки heartbeat.

This remains in ConservativeRetextualization only if the translation is still tethered to the same source claim, preserves the same described entity, and does not quietly add cross-tradition bridge claims such as "equivalent architecture role" or "same operational guarantee" beyond what the source actually states.

#Boundary to explanation surfaces

A text is rewritten not mainly to restate the same source, but to explain why it matters, simplify reasoning for a learner, or narrate a mechanism. That move should leave ConservativeRetextualization and be reviewed under ExplanationFaithfulnessProfile.

#Boundary to representation transduction

A prose note is rewritten as a table, matrix, diagram, or latent/distributed representation. Even if the described entity stays fixed, this is not only a textual rewrite; it belongs with RepresentationTransduction.

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Prag, Did. This pattern intentionally biases toward same-entity conservativity and away from explanation or retargeting inflation. The main mitigation is explicit reroute discipline to ExplanationFaithfulnessProfile, RepresentationTransduction, A.6.4, and later downstream owners when the same-entity textual reading stops being honest.

#Conformance Checklist

1. CC-CR-1 — Same described entity remains explicit. The case preserves describedEntityRef without special pleading.
2. CC-CR-2 — Textual re-expression remains the right family. The result stays a textual re-expression rather than explanation or representation shift.
3. CC-CR-3 — Loss / provenance / pinning / reliability are explicit or inherited by pinned reference. The case states these explicitly or inherits them through already-pinned host material that remains visible to review.
4. CC-CR-4 — Direct vs correspondence split is explicit. The Direct / Correspondence split is explicit and justified.
5. CC-CR-5 — Correspondence support is named where needed. If correspondence-mediated, CorrespondenceModelRef is declared.
6. CC-CR-6 — Local conservativity witness remains satisfied. The reviewed case does not silently strengthen modality, remove caveats, raise reliability posture, import bridge or substitution licence, or collapse declared alternatives beyond stated loss notes.
7. CC-CR-7 — Reroute path is explicit on failure. If the case fails any of the checks above, the reroute path is explicit (ExplanationFaithfulnessProfile, RepresentationTransduction, A.6.4, B.5.2, or another owner).
8. CC-CR-8 — Working-model first remains intact. Ordinary same-entity rewrites stay lightweight; fuller explicit review records are reserved for load-bearing cases.

#Common Anti-Patterns and How to Avoid Them

#Consequences

• Textual same-entity rewrites get a lawful place without inventing a new heavy owner.
• Direct and correspondence-mediated variants stay visibly separated.
• Loss, provenance, and reliability transport become explicit instead of implicit editorial judgement.
• Ordinary working-model use stays lightweight, while load-bearing cases get a fuller explicit review record when risk warrants it.
• The pattern remains safely bounded by A.6.3, A.6.4, explanation-facing work, and representation-shift work.

#Rationale

This pattern is worth splitting out because same-entity textual re-expression is common, useful, and safer than many neighboring transform families when it stays explicitly conservative. Keeping it under A.6.3 as a named specialization preserves owner integrity while making a recurring authoring move easier to review, while still respecting E.14’s working-model-first discipline for ordinary cases.

#SoTA-Echoing

SoTA note. This section does not mint an independent second rule layer. It is a load-bearing alignment surface: the Solution, Conformance Checklist, boundary rules, and Relations of this pattern must match the stance stated here or explicitly justify any divergence.

Traditions covered. This pattern binds itself to architecture-description governance, summarization factuality, translation-quality governance, and plain-language rewrite practice.

Architecture-description governance. A.6.3.CR adopts the discipline that rendered text must stay visibly tied to a declared source/view line. It therefore rejects same-topic textual polish as sufficient evidence of same-described-entity conservativity.

Summarization factuality. A.6.3.CR adapts modern factuality concerns into a local conservativity witness: unsupported strengthening, hidden omission, and rhetorical uplift are treated as load-bearing failures, not as style noise.

Translation and plain-language traditions. A.6.3.CR adopts the reader-oriented value of translation and plain rewrite, but rejects the still-popular habit of treating cross-language or plain-language textual fluency as automatic proof that no new claim has been introduced.

Local stance. Best-known current practice supports a narrow rule: same-described-entity textual restatement is lawful only when source tether, loss, provenance, and same-entity bounds remain explicit enough that the reader can still tell what was preserved, what was omitted, and when the case must exit to another owner.

#Relations

• Builds on: A.6.3, A.6.2, A.7, E.10.D2, E.17.0, E.17, F.9, F.18, E.10
• Coordinates with: ExplanationFaithfulnessProfile, RepresentationTransduction, E.17.ID.CR ComparativeReading, A.6.4, B.5.2, A.15
• Impact radius: primary touch A.6.3; secondary review surfaces E.17.0, E.17, F.9; failed conservativity exits to A.6.4, B.5.2, or A.15
• Boundary notes: explanation-facing cases exit to ExplanationFaithfulnessProfile; representation-regime shifts exit to RepresentationTransduction; bounded comparative review units exit to E.17.ID.CR ComparativeReading; described-entity changes exit to A.6.4.

#A.6.3.CR:End

#RepresentationTransduction — same-described-entity representation-scheme transition

Placement. Specialization under A.6.3 U.EpistemicViewing for same-described-entity representation-scheme transition.
Builds on. A.6.3 U.EpistemicViewing; A.6.2 U.EffectFreeEpistemicMorphing; A.7; E.10.D2; C.2.7; E.17.0; E.17; F.9; F.18.
Coordinates with. ConservativeRetextualization; ExplanationFaithfulnessProfile; E.17.ID.CR ComparativeReading; A.6.4 U.EpistemicRetargeting; A.15; A.20; A.21; explicit decoding-access review.

One-line summary. RepresentationTransduction is a same-described-entity shift in representation scheme that stays inside A.6.3 U.EpistemicViewing: it may move between prose, table, diagram, structured notation, or another declared representation regime, but it does not silently change describedEntityRef, promote geometry or notation into ontology-by-default, or hide decode-mediated recoverability behind surface fluency.

#Problem frame

The same described entity often needs to be carried across more than one representation regime:

• prose into a table that makes comparison or coverage clearer;
• a table into a diagram that foregrounds dependency or topology;
• a diagram into a structured notation suitable for replay or technical review;
• a source representation into another regime that changes reasoning affordances without changing the underlying object-of-talk.

In practice these shifts are often treated as harmless reformatting. But some representation changes alter reasoning affordances, weaken recoverability, or quietly change what appears to be present in the source. FPF already has A.6.3 for same-described-entity conservative viewing. This pattern names the recurring same-described-entity case where the published result changes representation scheme while the case still remains inside A.6.3.

#Problem

Without a dedicated named pattern for representation-scheme transitions:

1. teams treat text-to-table, table-to-diagram, and notation shifts as if they were all the same kind of harmless rewrite;
2. changes in reasoning medium and recoverability remain implicit;
3. latent/distributed cases tempt authors to treat geometry or feature clusters as ontology-by-default;
4. reviewers cannot tell when a case is still same-entity viewing and when it has become retargeting, explanation, carrier work, or decode-mediated reconstruction;
5. representation factors owned near C.2.7 are discussed rhetorically rather than as explicit deltas.

#Forces

• Same entity, different reasoning medium. Teams need different representational forms without silently changing the described entity.
• Legibility vs recoverability. A clearer representation is useful only if readers can still recover how it relates to source claims, anchors, and pins.
• Representation change vs ontology drift. A new notation or geometry can make structure more visible, but it must not silently become a new object-of-talk.
• Recoverability before decode ambition. Start from cases where recoverability can be reviewed directly before leaning on decode-mediated reconstruction.
• Owner restraint. This pattern must stay under A.6.3, not swallow explanation governance, retargeting, bridge work, or carrier work.

#Solution — same-described-entity representation-scheme transition under A.6.3

#Informal definition

RepresentationTransduction is a named pattern specialized under A.6.3 U.EpistemicViewing for same-described-entity transitions across declared representation schemes.

It preserves describedEntityRef, keeps the transform effect-free, and makes explicit what changes in representation factors, reasoning medium, recoverability, and loss profile.

It may move between prose, table, diagram, structured notation, or another declared representation regime. It may not silently change the described entity, silently import bridge semantics, or treat decode-mediated structure as if it were directly given.

#Pattern, case, and published rendering distinction

RepresentationTransduction is an intensional pattern and a named specialization under A.6.3. Concrete same-described-entity representation changes are passive episteme-level cases or published renderings reviewed under this pattern; the pattern itself does not act, decide, or publish.

This distinction matters because the pattern governs how a representation change is recognised, justified, and checked. It does not turn every table, diagram, or structured notation into a giant standalone review object, and it does not reduce review to a mechanical reformatting step.

#Local working vocabulary

This pattern uses a small local vocabulary for review.

• Representation scheme = the published form in which the same entity is rendered (for example prose, table, diagram, or structured notation).
• Reasoning medium = the form-specific affordances readers actually use when inspecting the published material.
• Semiotic mode = what kind of meaning-bearing support is doing the main work in the rendering, such as structural likeness, trace/index, conventional code, model-mediated correspondence, or decode-mediated recoverability.
• Factor delta = the explicit change in representation factors that matters for review.
• Source tether = the visible link back to pinned or otherwise reviewable source material that keeps same-entity support honest.
• Decode-mediated case = a case where explicit access to the target representation depends on a declared decoding route rather than direct reading from already published source material.

These terms are local review aids. They do not create a new face family or a new ontology owner.

#Scope and exclusions

In scope

• text-to-table shift over the same described entity;
• table-to-diagram shift over the same described entity;
• diagram-to-structured-notation shift where the represented entity and claim-bearing material stay preserved;
• other same-entity representation-scheme changes with explicit recoverability discipline.

Out of scope

• any change of describedEntityRef or hidden change of object-of-talk (A.6.4);
• explanation-facing renderings whose main purpose is didactic or explanatory surface work (ExplanationFaithfulnessProfile);
• purely textual rewrites that stay inside one representation regime (ConservativeRetextualization);
• carrier work such as rendering, export, upload, serialization, or OCR/parsing-like extraction;
• latent/distributed use without explicit decode route and recoverability evidence.

#Reader guidance

Use this pattern when the object-of-talk stays fixed but the published result changes representation scheme or reasoning medium.

• If only wording changes, stay in ConservativeRetextualization.
• If the target mainly teaches, narrates, or explains, move to ExplanationFaithfulnessProfile.
• If same-entity support fails, move to A.6.4.

#What a reviewer checks first

A reviewer usually starts with five questions:

1. Is the described entity still the same, or has the object-of-talk shifted?
2. What changed in representation scheme and reasoning medium?
3. Can the target still be tethered back to source-bearing material strongly enough for same-entity reading?
4. Has the case quietly become explanation, bridge-bearing comparison, retargeting, or carrier work?
5. If decoding is involved, is the evidence class strong enough for the intended face and use?

Only after these questions are answered clearly does a fuller load-bearing review record normally become necessary.

#Working-model first; explicit review record only when the case is load-bearing

Most same-described-entity representation shifts should stay human-usable and reviewable without turning every table, diagram, or structured rendering into a giant metadata block. This pattern therefore follows E.14's working-model-first discipline: ordinary non-latent cases need enough explicitness to show what stayed the same, what changed in representation and reasoning medium, what was lost or foregrounded, and where the case would have to reroute.

Ordinary case (default). For everyday same-described-entity representation shifts, it is usually enough that the rendering or its surrounding publication keeps explicit:

• which source material is being re-expressed in a different representation regime;
• that describedEntityRef remains preserved;
• what changed in representation scheme or reasoning medium;
• what losses, foregrounding choices, or recoverability limits matter for the reader;
• where the case exits if it has turned into explanation, retargeting, bridge-bearing comparison, carrier work, or decode-mediated reconstruction with insufficient support.

Explicit review record (only for load-bearing cases). A fuller record is warranted when the case is assurance-facing, gate-adjacent, cross-context, correspondence-heavy, decode-mediated, policy-bearing, or likely to be disputed. The record may inherit host ids and already-pinned metadata instead of restating them inline. When published, that record normally captures:

• transform placement (landingForm = specialization under A.6.3, hostOwner, sourceForm, targetForm, changeLocus);
• preservation context (describedEntityPolicy = preserve, boundedContextPolicy, viewpointPolicy, referenceSchemePolicy, representationSchemePolicy, groundingPolicy, referencePlanePolicy);
• claim and publication discipline (claimPolicy, claimScopePolicy, publicationScopePolicy, reliabilityTransportPolicy, pinningPolicy, provenancePolicy, lossProfile);
• continuity and bridge discipline (claimContinuityClass, microtheoryContinuityClass, onticContinuityClass, bridgeRequirement);
• downstream and admissibility discipline (worldContactPolicy, evidencePolicy, gatePolicy, workCrossing, upstreamOwner, downstreamOwner, admissibleFaces, admissibleSurfaces, compositionLaw, reopenCondition);
• representation and recoverability discipline (representationFactorDelta, inferenceRegimeDelta, semioticModePrimary?, semioticModeSupport?, semioticModeShift?, modeOverreadRisk?, salienceShift?, topologyShift?, actionabilityShift?, calibrationShift?, interactivityShift?, onticScaffoldPreservation, onticRecoverabilityClass, onticRecoverabilityMode, RecoverabilityEvidenceClass, decodeMechanismRef, CorrespondenceModelRef? where needed);
• naming and presentation discipline (publicNamePolicy).

#Working admissibility defaults

By default in this pattern:

• primary admissible faces for non-latent cases are Plain and Tech;
• bounded report-only use is lawful when source pins, provenance, loss notes, and same-described-entity support remain visible;
• Interop use is lawful only when the host explicitly permits source-pinned, structure-preserving export without added semantics;
• Assurance or gate-bearing use is not default and requires host-explicit policy plus source-pinned same-entity support;
• latent/distributed variants remain bounded until explicit recoverability evidence and decode-route discipline are published.

#Direct and correspondence-mediated profiles

Direct RepresentationTransduction

• source and target are representation-scheme variants over one same-described-entity source line;
• no CorrespondenceModelRef is required;
• the main burden is explicit factor delta, reasoning-medium delta, and recoverability discipline.

CorrespondenceRepresentationTransduction

• the target representation is derived through a declared correspondence between epistemes or views of the same described entity;
• CorrespondenceModelRef is required;
• the result remains under A.6.3 only if same-entity conservativity is still supportable and the correspondence does not silently import extra claims.

Correspondence-mediated representation work does not by itself grant bridge licence, substitution licence, or comparative-reading licence. If the case needs those burdens, they must be declared separately rather than hidden inside representation language.

#Recurring same-entity representation moves

Recurring same-entity moves under this pattern include:

• Tabulation — prose or dispersed claims are rendered into a table that exposes comparison or coverage more clearly.
• Diagramming — a table or prose relation set is rendered into a diagram that foregrounds structure while remaining source-tethered.
• Structured notation shift — prose, table, or diagram material is rendered into a notation better suited for disciplined replay or technical inspection.
• Correspondence-supported representation shift — the target representation depends on declared same-entity correspondence support without thereby becoming a bridge case.

These are recurring move shapes under one host relation. They are not separate owners and they do not override E.17 face discipline.

#How a reviewer reads representation-factor and reasoning-medium change

A reviewer should be able to say, in one short paragraph, what changed in representational shape, what changed in reasoning medium, and whether the primary change is also a semioticModeShift rather than only a scheme change. Typical read-outs are: "the table foregrounds comparability across rows", "the diagram foregrounds dependency shape", or "the notation foregrounds explicit argument positions."

When the case is more demanding, that paragraph should also name whether salience, topology, actionability, calibration, or interactivity materially changed. If the author cannot name those shifts without slipping into new ontology, hidden bridge work, or a changed described entity, the case is not yet ready to stay here. Use semioarchitecture-representation-delta-review-crib-sheet.md and semioarchitecture-semiotic-mode-axis-note.md when the deltas need a more normalized read-out.

#Shared representation law packet

#A.6.3.RT:4.5.a. Preservation law

RepresentationTransduction preserves the same described-entity line, bounded context, and declared claim-bearing source while changing the representation scheme and, often, the reasoning medium. It must state what remains preserved about the ontic scaffold, claim scope, publication scope, pins, provenance, and grounding. It must also state whether the case remains direct or correspondence-mediated.

#A.6.3.RT:4.5.a.1. Local conservativity witness

For this pattern, a new intensional claim is introduced when the target rendering:

• upgrades a source-visible relation into a stronger relation theory or stronger dependency semantics;
• turns geometry, notation, embedding proximity, or decoder output into ontology-by-default;
• adds bridge, substitution, comparative-reading, or mechanism claims not already licensed by the source line or declared correspondence;
• collapses source alternatives, uncertainty, or bounded scope into one stronger commitment;
• or treats decode-mediated recoverability as if it were direct givenness.

Conservativity is approximated here by checking, together, describedEntityPolicy = preserve, source-tether strength, factor delta, reasoning-medium delta, loss profile, ontic scaffold preservation, and whether each target-side connective can be pointed back to pinned source material or declared same-entity correspondence support.

#A.6.3.RT:4.5.b. Loss and reliability law

A reviewed case under this pattern makes explicit which distinctions, affordances, or local cues are lost, foregrounded, or rearranged by the shift in representation regime. Reliability transport may remain source-bounded or be explicitly downgraded, but it must never be silently strengthened just because the target form looks clearer, more structured, or more formal.

#A.6.3.RT:4.5.c. Authority and handoff law

A case reviewed under this pattern stays same-entity and episteme-level. It does not own retargeting, bridge stance, explanation governance, executable docking, gate authority, or work enactment. If the shift depends on decode-mediated recovery, intervention-backed extraction, or world/gate consequences, those dependencies must stay explicit and may restrict the target to exploratory or report-only use.

#A.6.3.RT:4.5.c.1. Same-entity entry condition for decode-mediated cases

A decode-mediated case may stay here only when the target rendering is tethered back to already pinned and provenance-bearing source material for the same described entity. A decode-mediated result alone does not establish the same described entity strongly enough for this pattern.

#A.6.3.RT:4.5.d. Composition and reopen law

Repeated same-regime normalization may be idempotent, but heterogeneous regime shifts are generally order-sensitive. The case must reopen whenever recoverability assumptions, pins, provenance, correspondence support, or target-face admissibility change. A representation shift also reopens if what looked like one same-entity line turns out to require a new described entity or a decode route stronger than currently declared.

#Hard boundary rules

A case reviewed under this pattern keeps the following explicit:

• describedEntityPolicy = preserve is mandatory;
• any change of DescribedEntityRef exits to A.6.4;
• purely textual rewrite cases stay with ConservativeRetextualization;
• explanation-facing cases stay with ExplanationFaithfulnessProfile;
• carrier work stays outside this pattern;
• geometry, notation, embedding space, or feature clustering must not become ontology-by-default;
• the family changes representation scheme, not face ownership, and it therefore stays under existing E.17.0 / E.17 face discipline rather than creating a new publication family.

If recoverability depends on decoding, probing, or intervention, the evidence class must bound admissible use; otherwise the case stays exploratory, report-only, or outside the admissible same-described-entity path under A.6.3.RT. Low-evidence decode-mediated results are not weaker canonical publications; they are bounded exploratory or report-only renderings. Non-latent cases remain the default entry path until decode-mediated recoverability is made explicit.

#Archetypal grounding

#Same-entity text-to-table shift

Source slice. Service S showed three recurring latency spikes in the evening batch window. Trace T-44 and dashboard pin D-17 identify the same service and time window.

Published table slice. | Service | Window | Spike count | Source pins | | Service S | Evening batch | 3 | T-44, D-17 |

This is a lawful direct RepresentationTransduction if no new claims are introduced, the same described entity stays explicit, and the representation-factor delta is declared. In ordinary engineering use, this usually needs a visible source tether, explicit loss notes if anything was omitted, and a clear statement that the table is still about the same service occurrence rather than a new derived object.

#Same-entity table-to-diagram shift

Source table slice. | Node | Depends on | | CoolingLoop | Sensor A | | CoolingLoop | Valve B |

Published diagram slice. CoolingLoop -> Sensor A; CoolingLoop -> Valve B

The move stays in this pattern only if the described entity is preserved, the diagram does not silently add new semantic commitments, and reasoning-medium change is declared. If the diagram starts asserting a stronger dependency theory than the source table actually states, the case must reopen and may leave this pattern.

#Correspondence-mediated text-to-table shift

Source prose slice. In the safety view, CL-2 maintains the required temperature condition during standard load.

Published table slice. | View | Entity | Condition | Correspondence model | | Safety | CL-2 | required temperature condition during standard load | CM-12 |

The move stays in this pattern only if the correspondence remains explicit, the described entity stays preserved, and the resulting table does not quietly import bridge semantics or a changed object-of-talk. Because the correspondence burden is doing real work here, a fuller review record is often warranted instead of relying only on the rendered table.

#Same-entity diagram-to-structured-notation shift

Source diagram slice. CoolingLoop -> Sensor A; CoolingLoop -> Valve B

Published notation slice. dependsOn(CoolingLoop, SensorA) dependsOn(CoolingLoop, ValveB)

This remains under RepresentationTransduction when the notation stays tethered to the same relation line already visible in the diagram, the described entity remains preserved, and no stronger dependency theory is silently imported by the notational rendering.

#Boundary to textual rewrite

A source prose note is shortened, reordered, or translated but remains essentially textual. That case stays with ConservativeRetextualization, not this pattern.

#Boundary to explanation surfaces

A representation shift is performed mainly to teach or narrate rather than to publish another same-entity representation regime. That case should leave this pattern and be reviewed under explanation governance.

#Boundary to bridge-bearing comparison

Source slice. Local reliability note: Pump P-2 remained within operating range during test window W-3.

Published comparative slice. Pump P-2 in W-3 behaves like Unit U-7 in Plant B and can therefore be treated as operationally equivalent for this comparison.

This does not stay in RepresentationTransduction. The rendering has moved from a same-described-entity representation shift to comparative or bridge-bearing reading across contexts. Once the publication starts asserting cross-context equivalence, substitution, or comparative licence, the case must leave this pattern and move to explicit bridge-governed review.

#Boundary to carrier/export work

Source rendering slice. | Service | Window | Spike count | Source pins |

Published export slice. latency-report.csv and dashboard PNG generated from the same table.

This also stays outside RepresentationTransduction. The representation scheme was already chosen; what follows is carrier formatting, export, packaging, or rendering work on that representation. The didactic point is that not every change in visible form is a new same-described-entity representation transition.

#Boundary to decode-mediated latent cases

A reviewer or decode path tries to restate a latent region or distributed feature cluster as explicit object/relation content. This stays outside the admissible same-described-entity path under A.6.3.RT unless an explicit decoding-access profile, RecoverabilityEvidenceClass, and an explicit decode route are already present. Readable decode output alone is not enough.

#Guarded decode-mediated readout

Pinned source cluster. Probe run P-8 is tied to model-state log M-12 and evaluation bundle EV-4 for the same diagnostic case.

Published exploratory slice. A decode-mediated readout suggests a cluster that may correspond to the same failure episode already pinned in P-8 / M-12 / EV-4. This rendering stays exploratory and report-only until stronger recoverability evidence is published.

This example remains guarded-open rather than green. The didactic point is that a decode-mediated rendering may still be useful, but it does not become a normal same-entity publication merely because the result looks readable.

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Prag, Did. This pattern intentionally biases toward same-entity representation shifts and away from hidden retargeting, explanation inflation, or ontology-by-default through notation or geometry. The main mitigation is explicit recoverability discipline, preserve-vs-retarget escape rules, and directly reviewable entry cases before decode-mediated ones.

#Conformance Checklist

1. CC-RT-1 — Same described entity remains explicit. The case preserves describedEntityRef without special pleading.
2. CC-RT-2 — Representation shift is the right family. The result is genuinely a representation-scheme shift rather than mere textual rewrite or explanation work.
3. CC-RT-3 — Factor, reasoning-medium, and mode deltas are explicit. representationFactorDelta, inferenceRegimeDelta, and any load-bearing semioticModeShift are explicit.
4. CC-RT-4 — Extended delta axes are explicit when load-bearing. salienceShift, topologyShift, actionabilityShift, calibrationShift, and interactivityShift are named whenever they materially shape review or misuse risk.
5. CC-RT-5 — Recoverability is explicit. Recoverability is stated explicitly through onticRecoverabilityClass and onticRecoverabilityMode.
6. CC-RT-6 — Decode-mediated cases carry stronger evidence. If the case is decode-mediated or latent/distributed, RecoverabilityEvidenceClass and decode route are explicit.
7. CC-RT-7 — Loss / provenance / pinning / reliability are explicit. Losses, provenance, pinning, and reliability transport are explicit.
8. CC-RT-8 — Preserve-vs-retarget reroute is explicit. If the case fails any of the checks above, the reroute path is explicit (ConservativeRetextualization, ExplanationFaithfulnessProfile, A.6.4, or another owner).
9. CC-RT-9 — Direct vs correspondence split is explicit. The case states whether it is direct or correspondence-mediated; if correspondence-mediated, CorrespondenceModelRef is explicit.
10. CC-RT-10 — Non-default face/surface admissibility is explicit. Any Interop, Assurance, gate-bearing, or decode-bounded use states host-explicit admissibility and keeps same-entity support visible.
11. CC-RT-11 — Decode-mediated same-entity entry tether is explicit. A decode-mediated case states how the target rendering is tethered back to already pinned and provenance-bearing source material for the same described entity.
12. CC-RT-12 — No hidden bridge or face-family inflation. The case makes clear that representation work does not by itself grant bridge, substitution, or comparative-reading licence and does not create a new face family.
13. CC-RT-13 — Reopen triggers are explicit when recoverability, admissibility, or primary mode changes. If recoverability assumptions, pins, provenance, correspondence support, target-face admissibility, or the primary semiotic mode change, the case records the reopen trigger explicitly.

#Common Anti-Patterns and How to Avoid Them

#Consequences

• Same-entity representation shifts get a lawful place without inventing a new heavy owner.
• Representation-factor and reasoning-medium changes become explicit rather than rhetorical.
• Recoverability and decode dependence become reviewable instead of hidden behind cleaner surfaces.
• The pattern remains safely bounded by A.6.3, A.6.4, explanation governance, and carrier work.

#Rationale

This pattern is worth splitting out because representation changes are already happening in practice and they are not well served by treating every such case as either mere rewriting or full retargeting. Keeping the family under A.6.3 preserves owner safety while making representation-factor and recoverability burdens explicit.

#SoTA-Echoing

SoTA note. This section does not mint an independent second rule layer. It is a load-bearing alignment surface: the Solution, Conformance Checklist, boundary rules, and Relations of this pattern must match the stance stated here or explicitly justify any divergence.

Claim 1. Best-known current architecture-description and model-based practice treats views, representation schemes, and reasoning media as load-bearing rather than as decorative formatting. Practice / source / alignment / adoption. ISO/IEC/IEEE 42010:2022 and current SysML v2 view practice treat viewpoint, view, model kind, and rendering discipline as explicit review objects rather than mere layout choices. This pattern adopts explicit representation-scheme review, adapts it to same-described-entity viewing under A.6.3, and rejects the shortcut where a clearer table, diagram, or notation is treated as if it had automatically earned stronger ontology or authority.

Claim 2. Best-known contemporary notation-and-reasoning practice treats tables, diagrams, and structured notations as reasoning media with different affordances, not as neutral surface restyling. Practice / source / alignment / adoption. Post-2015 model-based and notation-sensitive review practice treats representational form as something that changes what readers can inspect, compare, or replay. This pattern adopts reasoning-medium review, adapts it through explicit factor and medium deltas, and rejects hidden dependency-theory uplift or silent semantic strengthening by prose-to-diagram or diagram-to-notation moves.

Claim 3. Best-known representation-aware AI practice treats latent geometry and decode-mediated structure as evidence-bounded interpretation rather than ontology-by-default. Practice / source / alignment / adoption. Byte Latent Transformer (2024) and Large Concept Model (2024) both reinforce that representation regime matters, but neither licenses silent promotion from geometry, cluster structure, or decoder output to canonical object/relation ontology. This pattern adopts representation-aware review, adapts it through RecoverabilityEvidenceClass, decode-route explicitness, and same-entity source tethering, and rejects the popular shortcut where readable decode output is treated as if it were direct givenness.

Local stance. The load-bearing SoTA claim for this pattern is narrow: representation regime and reasoning medium are lawful review targets, but geometry, notation, or a decode-mediated result do not become ontology-by-default.

#Relations

• Builds on: A.6.3, A.6.2, A.7, E.10.D2, C.2.7, E.17.0, E.17, F.9, F.18
• Coordinates with: ConservativeRetextualization, ExplanationFaithfulnessProfile, E.17.ID.CR ComparativeReading, A.6.4, A.15, A.20, A.21, explicit decoding-access review
• Impact radius: primary touch A.6.3; secondary review surfaces C.2.7, E.17.0, E.17, F.9, decode-mediated recoverability review; failed same-entity or recoverability conditions exit to A.6.4, explanation governance, or later world/gate owners
• Boundary notes: textual same-regime rewrites stay with ConservativeRetextualization; explanation-facing renderings stay with ExplanationFaithfulnessProfile; bounded comparative review units exit to E.17.ID.CR ComparativeReading; described-entity changes exit to A.6.4; decode-mediated world/gate consequences remain bounded by explicit evidence and downstream handoff.

#A.6.3.RT:End

#U.EpistemicRetargeting — describedEntity‑retargeting morphism

One‑line summary. U.EpistemicRetargeting is the describedEntity‑retargetning species of U.EffectFreeEpistemicMorphing: an effect‑free episteme→episteme morphism that intentionally changes what the episteme is about (the occupant of DescribedEntitySlot in C.2.1) under a declared KindBridge and invariant, while remaining conservative with respect to that invariant.

Placement. After A.6.3 U.EpistemicViewing, before A.6.5 U.RelationSlotDiscipline.

Builds on. A.6.0 U.Signature; A.6.2 U.EffectFreeEpistemicMorphing; A.6.3 U.EpistemicViewing; A.6.5 U.RelationSlotDiscipline; A.7/E.10.D2 (I/D/S discipline, DescriptionContext); C.2.1 U.Episteme — Epistemes and their slot graph; C.2/C.3 (KD‑CAL/LOG‑CAL, ReferencePlane, Kind‑level reasoning); F.9 (Bridges, KindBridge, CL/CL^plane, SquareLaw witnesses).

Used by. E.18 (E.TGA StructuralReinterpretation and other reinterpretation nodes); discipline packs for signal/spectrum transforms, data↔model retargetings, abstraction/refinement under kind‑invariants; KD‑CAL/LOG‑CAL retargeting rules; future species for architecture and governance reinterpretations.

#Problem frame

Many important operations on descriptions change the object‑of‑talk while preserving a structural or behavioural invariant:

• Physical vs functional reinterpretation. An episteme about a physical module (cabinet, rack, device) is re‑interpreted as an episteme about a function‑holon it realises. This is precisely what StructuralReinterpretation nodes in E.TGA attempt to do.

• Signal vs spectrum. A time‑domain signal description is re‑targeted to a description of its frequency‑domain spectrum. The underlying invariant (typically energy or inner‑product) is preserved, but the “thing we talk about” changes from time→value trajectories to frequency→amplitude/phase distributions.

• Data vs model. An episteme about raw observations (dataset) is turned into an episteme about a learned or estimated model, keeping an invariant such as likelihood, sufficient statistics, or predictive performance.

All of these are Ep→Ep transforms that:

• do not change the Intension (I) directly (they operate on descriptions/specifications),
• do not merely slice or re‑express an episteme of the same entity (that would be EpistemicViewing, A.6.3),
• but do change the DescribedEntity‑bundle (DescribedEntitySlot and usually GroundingHolonSlot) under a formal bridge between kinds.

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

• effect‑free at the level of Work/Mechanism (EFEM discipline),
• describedEntity‑retargeotating in a controlled way,
• invariant‑conservative (no violation of the declared invariant between kinds),
• and functorial (retargetings compose cleanly and align with Bridges).

#Problem

Without a dedicated pattern for EpistemicRetargeting:

1. Retargeting is silently confused with viewing. Structural reinterpretations (e.g., component→function, signal→spectrum, data→model) can be mistakenly treated as “just another view” of the same entity, even though they change describedEntityRef. This hides the fact that the object‑of‑talk has changed and that a KindBridge and invariant are required.

2. Invariants float untyped. Fourier‑style moves, structural reinterpretations, and abstraction/refinement steps are often justified by “energy is preserved”, “this component realises that function”, or “this model summarises those data” — but these invariants are not connected to the episteme morphism class. Without a dedicated species:

   • invariants live only in text,
   • CL‑penalties and ReferencePlane crossings cannot be tracked systematically (Part F).

3. Cross‑kind reasoning has no canonical morphism. A general EFEM (A.6.2) can change describedEntityRef by setting describedEntityChangeMode = retarget, but:

   • nothing states what that means at the level of kinds (Kind(describedEntityRef(X)) vs Kind(describedEntityRef(Y))),
   • nothing connects these moves to KindBridge and ReferencePlane policies.

4. StructuralReinterpretation is ad‑hoc. E.TGA currently hosts StructuralReinterpretation as a special node, but its semantics are much closer to a generic “retargeting under a bridge” pattern than to something specific to graph‑based architectures. Without a core pattern:

   • StructuralReinterpretation risks duplicating retargeting logic,
   • other discipline packs may reinvent their own ad‑hoc re‑targetings.

5. I/D/S discipline is left underspecified. For descriptions/specifications (…Description / …Spec), retargeting changes DescribedEntityRef in DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ (E.10.D2), but must say what happens to context and viewpoint. Without an explicit pattern, these decisions get scattered across different E‑patterns instead of being governed centrally.

#Forces

• Changing the object‑of‑talk vs constructing something new. Retargeting should express “talking about a different but bridge‑related entity”, not arbitrary construction of a new Intension/episteme. The invariant lives across the pair of entities, not inside a single episteme.

• Invariants may be lossy but must be explicit. A retargeting is often lossy (e.g. data→model, signal→spectrum, structural→functional view), but:

  • it must preserve an explicitly declared invariant (energy, behaviour, statistics),
  • any additional strengthening must be modelled as a change of Intension plus new D/S, not as a hidden side‑effect.

• Bridges and CL‑penalties. Retargeting often crosses:

  • Kind‑planes (different Kind(U.Entity)),
  • ReferencePlanes (different observability or abstraction regimes). Part F already has KindBridge, plane Bridges and CL‑penalties; EpistemicRetargeting must re‑use them instead of introducing its own notion of “link”.

• Functors over α : Ep → Ref. In the fibred view of epistemes (C.2 / A.6.2), α : Ep → Ref maps each episteme to its described entity. EpistemicViewing preserves α (α(v) = id). Retargeting must:

  • change α in a controlled way (α(r) = b : R₁→R₂ in Ref),
  • align with KindBridge and plane Bridges used for those base arrows.

• Slot discipline and modularity. C.2.1 and A.6.5 give epistemes a precise SlotKind/ValueKind/RefKind structure, including DescribedEntitySlot and GroundingHolonSlot. Retargeting laws must be stated at the slot level, not on ad‑hoc “fields”, so they can be reused across E.TGA, MVPK, and discipline packs.

#Solution — U.EpistemicRetargeting as EFEM profile (describedEntityChangeMode = retarget)

#Informal definition

Definition (informal). U.EpistemicRetargeting is the describedEntity‑retargeting species of U.EffectFreeEpistemicMorphing. A U.EpistemicRetargeting r : X→Y:

• takes an input episteme X and produces an output episteme Y,
• changes the occupant of DescribedEntitySlot (describedEntityRef(Y) ≠ describedEntityRef(X)),
• relates the kinds of the old and new described entities via an explicit KindBridge in the appropriate ReferencePlane,
• preserves a declared invariant across the pair of entities (e.g. energy, behaviour, sufficient statistics),
• is effect‑free at the level of Work/Mechanism (EFEM discipline),
• and composes functorially with other retargetings and viewings.