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

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

#What this page is

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

#Methodology

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

#Content

#Signature Stack & Boundary Discipline

Type: Architectural (A) Status: Stable Normativity: Mixed (normative only where explicitly marked; claim-classification semantics live normatively in A.6.B) Placement: Part A → A.6.* (cluster overview; coordinates A.6.0 / A.6.1 / A.6.3 / A.6.B / A.6.5 / A.6.6 / A.6.7) Builds on: E.8 (authoring template), A.6.B (Boundary Norm Square — quadrant semantics & link discipline), A.6.0 (U.Signature), A.6.1 (U.Mechanism), A.6.3 (optional source-to-receiving episteme construction), E.17.0 (viewpoint conformance and U.View membership), E.17 (MVPK — fixed face kinds & “no new semantics” publication), A.7 (EntityOfConcern and Description-episteme boundary; specification use and publication-carrier distinction), A.6.C, A.2.3, A.2.8, A.2.8.PER, and A.2.9 for promise-content, commitment, permission, speech-act, and dated-Work and separate result, delivery, acceptance, and evidence unpacking, F.18 only when recovered boundary terms need durable naming, E.10.D2 (EntityOfConcern and Description-episteme boundary; specification use and refinement discipline), E.10 publication face, form, unit, and carrier discipline Purpose (one line): Keep boundary claims evolvable by classifying each statement under the right layer of the Signature Stack and the right quadrant of the Boundary Norm Square (A.6.B).

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

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

Use this pattern when. Use A.6 when a boundary package, API, protocol, contract, compliance statement, SLO/SLA, connector, interface, or publication boundary mixes definitions, admissibility predicates, duties, evidence, and work effects into one account.

What goes wrong if missed. Boundary prose starts doing too many jobs at once: invariants become permissions, permissions become duties, evidence becomes gate passage, and publication faces start acting as if they were the governed boundary object.

What this buys. The project gets an L/A/D/E-classified claim set with stable claim IDs, source references, stack placement, and publication-face citations, so work, reliance, evidence, commitment, and gate uses can return to their subject patterns.

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

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

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

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

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

Causal/deontic split. In “deploy because it would reduce harm”, C.28 decides what the causal evidence supports; A.6.B separately classifies the boundary claims. If any atomic claim is permission-looking, choose one A6-AW-* row below. A causal-use record supplies none of those boundary claims.

Authority-word branch (subordinate boundary-claim stress case). When “approved”, “allowed”, “authorized”, “permitted”, or similar wording matters to action or reliance, choose one row by the claim being made—not by the visible word. These A6-AW-* labels are local claim-routing IDs, not new kinds.

Concrete API/credential case. A dashboard badge saying “API-7 approved for production” starts at A6-AW-SOURCE. It reaches A6-AW-NORM-GRANT only if a named policy-valid act instituted a current grant for a beneficiary and deployment action; the admission endpoint is separately A6-AW-GATE. Do not claim A6-AW-EXERCISE until a dated deployment Work occurrence matches that grant.

When the wording is agreement-like, use A.6.C to separate promise content, the instituting speech act, governance, Work, consequence, and evidence. For “recommended”, use A.16/A.6.A for a cue, A6-AW-GATE for an entry criterion, or A.2.8 only for recommendation-as-duty. Before any branch guides action or reliance, use A.15 to return to its exact governing claim.

Positive repaired result. The reader can identify the L/A/D/E job, select at most one A6-AW-* row for each permission-looking atomic claim, and reach the named subject pattern before acting or relying.

Credential-currentness boundary. A displayed credential supports only its issuer, holder, verifier, status, and currentness claims through A.10. Treat it as A6-AW-SOURCE; move to another row only when that row's direct object and ground are independently present.

Register-backed status boundary. A pass, dashboard cell, API response, or certificate view may be only a publication of a register entry. Start at A6-AW-SOURCE; if the governing entry has institutional force, select the one row whose object it actually creates or changes and cite that row's subject pattern. Otherwise keep only source-finding or currentness support under A.10.

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

Adversarial wording guard. Intentionally ambiguous authority wording does not choose a quadrant or repair destination. Split the sentence, select one A6-AW-* row per permission-looking claim, and keep every other work, evidence, gate, or assurance use with its own source.

Lint trigger. In boundary, API, schema, or policy text, authority-looking wording triggers the A6-AW-* table. A conforming repair names the selected row and source before the claim guides work or reliance.

Boundary and source repair assignment. If the split exposes a missing claim or source, give that exact claim ID or selected A6-AW-* branch to the identified boundary or source maintainer. Keep only cue use, source-finding, or a bounded reversible probe until the source is exposed or repaired.

Practitioner prompts for boundary wording use:

Recurring boundary ambiguity repair. If the same wording repeatedly needs the same split, repair the boundary package: replace the misleading label, expose the L/A/D/E claim IDs, and cite the source for the selected A6-AW-* branch. Repetition is a source defect, not a normal per-use burden.

Display guidance for boundary wording: a publication face, API page, or credential display should expose the relevant L/A/D/E claim IDs and the source for the selected A6-AW-* branch. If it cannot, keep the wording at A6-AW-SOURCE or repair the boundary package.

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

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

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

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

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

#Problem frame

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

• U.Signature as a public, law‑governed declaration (with Vocabulary, Laws, Applicability).
• U.Mechanism as a specialization that introduces operational “entry gates” (AdmissibilityConditions) and additional operational blocks (Transport, Audit, etc.).
• Multi-view describing through E.17.0 MultiViewDescribing, plus separate E.17 publication discipline for selected epistemes, face uses, forms, and carriers.
• Strict separation of EntityOfConcern vs Description episteme vs publication carrier so we do not accidentally attribute agency or work to an episteme, or treat a file as the entity, claim, work, evidence, or decision.

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

This cluster overview makes one disciplined move:

1. Treat a boundary as a stack of boundary layers (Signature → Mechanism → actual occurrences and their separately governed consequences/evidence) plus publication views and faces, and
2. Provide a boundary discipline matrix (2×2) that classifies statements by boundary layer, so evolution remains controlled and substitutions are possible.

Terminology note (informative): In this pattern:

• Layer names a stratum in the boundary stack (Signature → Mechanism → actual occurrences, separately governed consequences/evidence → Publication).
• View (U.View) is the same C.2.1 episteme individual when E.17.0 conformance to at least one exact viewpoint episteme obtains; it is not a projection operation, publication file, or document.
• Viewpoint (U.Viewpoint) is the same C.2.1 episteme individual when the fixed E.17.0 viewpoint-convention conditions obtain; its accountability use does not replace those membership conditions.
• Face (MVPK sense) is one named publication-use class (PlainView, TechCard, InteropCard, or AssuranceLane). A face may select an episteme that independently has U.View membership, but the face, publication form, rendering, and carrier are not that view. Do not coin “signature or mechanism ...Surface” terms; use publication face, form, unit, carrier, and rendering terms only when publication use is live.

#Problem

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

1. Laws vs admissibility. Authors encode runtime gate predicates as “laws”, or write invariants using RFC‑style deontic verbs, blurring “what is true or defined” with “what is allowed to be applied”. FPF explicitly separates these: operational guard predicates belong to mechanisms (A.6.1), not signatures (A.6.0). Common mistake #0 — Applicability ≠ Admissibility (informative): Signature Applicability scopes declared admissible use and bounded context; it is not a runtime entry gate. Runtime entry checks belong in U.Mechanism.AdmissibilityConditions as A-*. Such a predicate may consume the direct object selected by one A6-AW-* row as input, but it neither creates that object nor proves gate passage. A generic prescription states what one exact policy or other normative episteme requires; it does not create an individual duty bearer or commitment occurrence. A claim that one actual System or separately governed party has that duty instead cites one separately obtaining A.2.8 U.Commitment. Either branch can reference the A-* gate ID without becoming the gate.

2. Admissibility vs deontics. MUST, SHOULD, MAY, and authority-looking words do not reveal whether a statement is a duty, one A6-AW-* permission branch, or an entry predicate. Classify the claim by its job; neither the word, selected subject pattern, nor kind of direct object decides the quadrant.

3. Contract talk category errors. “The interface promises…” is a metaphor. Use A.2.3 for promise content, A.2.9 for the instituting speech-act Work, A.2.8 and A.2.8.PER for the commitment or grant, and A.15.1 only to identify the dated Work occurrence. An application result, production, delivery/transfer, acceptance, and evidence use each follows its own row in A.15.1:4.6 and is omitted when that claim is absent. A.6.C unpacks the boundary case; F.18 only names recovered terms when durable naming is current.

4. Effect claims without an actual occurrence. A description, diagram, log, or metric can state or support an effect claim, but none creates the effect. Ground the actual occurrence first. Use U.Work only when each exact actual performer has its A.13 core and A.15.1 independently identifies the Work, Method, time, and containing System. Add F.6 only when the receiving boundary claim expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. Use A.3 and A.3.4, or the pattern that defines the interaction or causal claim, for natural, spontaneous, formal, or other non-Work change. Then name the observation and A.10 evidence path needed for reliance.

These confusions destroy evolvability: you cannot swap implementations behind a stable signature if the signature already smuggles mechanism gates, audit logistics, individual commitments, or assignment-based applicability conditions into “laws”.

#Forces

#Solution — A stack + a classification matrix

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

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

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

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

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

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

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

   Audit vs AssuranceLane (avoid duplication): the Mechanism’s Audit and observability block defines the required semantics of an observability and evidence interface: carrier classes and required fields, correlation keys, and exposure interface. Retention, access, and enforcement are D-claims. A general prescription remains a claim-bearing episteme; one obtaining individual duty cites the exact A.2.8 U.Commitment, its actual bearer, and its direct predicate. A system-role kind or assignment may be an applicability ground but is neither bearer nor commitment. An MVPK AssuranceLane is a projection for auditors that explains how to adjudicate the evidence interface. This is a special case of CC-A.6.6: the AssuranceLane face references the Mechanism section and the relevant claim IDs rather than restating semantics.

3. Deontic layer (D: duties, commitments, and grants). Put here a general prescription or a claim about an exact individual duty, recommendation-as-duty, prohibition, commitment, or A6-AW-NORM-GRANT. For an individual duty, cite the exact A.2.8 U.Commitment, actual bearer, constitutive rule, required instituting basis, and direct predicate. Test any responsibility claim separately through its domain predicate or return the exact missing governor. Other A6-AW-* claims keep their own placement. Reference related L-*, A-*, or E-* IDs rather than duplicating them.

4. Observable-effects and evidence layer (E: Work-Effects & Evidence). E-* is the boundary's observable-effect and evidence claim family. Each claim names the actual occurrence or evaluated finding under its subject pattern and, when reliance is current, the observation conditions and A.10 evidence path. Name U.Work only after A.13 recovers each exact actual performer and A.15.1 independently identifies the Work, Method, time, and containing System. Add F.6 only when the receiving boundary use expressly consumes precise assignment-bound attribution; its absence or failure leaves the Work intact. A natural, spontaneous, or formal transformation may instead use A.3 and A.3.4. Canonical placement is an Evidence-and-carriers section, typically rendered in AssuranceLane.

5. Actual occurrences and realizations (outside the description stack). Substitutable realizations are exercised through dated Work only when each actual performer has its A.13 core and A.15.1 independently admits the occurrence. Add F.6 only when the receiving description also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. Work may participate in change, production, speech-act effect, evaluation, or evidence production, but each relation or claim must be established under the pattern that defines or constrains it. A.3 and A.3.4 also admit natural, spontaneous, and formal transformations without a performer, assignment, Method, or Work occurrence.

6. Publication faces. MVPK selects exact epistemes and publication forms for audience-specific face uses. A selected episteme has U.View membership only when E.17.0 conformance to the exact viewpoint episteme obtains; any A.6.3 source-to-receiving construction remains separate. The face class, publication occurrence, form, rendering, and carrier are not the U.View.

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

#AssuranceLane skeleton (informative)

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

Minimal content (suggested):

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

No new semantics reminder. An AssuranceLane may explain adjudication informatively, but every new normative sentence first enters the canonical claim set. A changed permission-looking claim cites its selected A6-AW-* row and subject pattern rather than being introduced inside the face.

Example (conceptual, no tools):

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

Default placements (quadrant → stack layer / section):

• L → Signature.Laws (and, where appropriate, mechanism‑local semantic laws; never runtime gates)
• A → Mechanism.AdmissibilityConditions
• D → generic prescriptions, individual duties or commitments, recommendations-as-duty, prohibitions, and A6-AW-NORM-GRANT claims at their exact A.2.8 or A.2.8.PER subject pattern
• E → actual occurrences, evaluated findings, and evidence claims, including A6-AW-EXERCISE, A6-AW-WEAK, A6-AW-CONFLICT, and A6-AW-SOURCE when those claims are current

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

• A.6.1 ↔ A‑quadrant: U.Mechanism.AdmissibilityConditions is the canonical claim layer for A-* gate and admissibility claims.
• A.10 / B.3 ↔ E‑quadrant: E-* claims should cite evidence carriers and provenance (A.10); without an explicit evidence-carrier reference they are treated as AssuranceLevel:L0 (Unsubstantiated) in the Trust & Assurance calculus (B.3).
• A.2.3 and F.12 ↔ D/E separation: a U.PromiseContent promise is not evidence; promise acceptance is linked to Work evidence via F.12. A general duty remains normative content, while an obtaining individual duty is one A.2.8 U.Commitment borne by an actual System or other admitted party. Any system-role kind or assignment used to establish applicability stays separate. D-* claims reference A-* and E-* IDs when needed.

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

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

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

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

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

• Modality family: truth-conditional versus governance content. For permission-looking wording, the selected A6-AW-* row states which side applies; A.2.8.PER membership alone does not.
• Adjudication substrate: in‑description vs in‑work (whether satisfaction is decided from the description alone or requires observing executed work and carriers).

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

• L (Laws & Definitions) → Signature.Laws (truth‑conditional semantics, in‑description)
• A (Admissibility & Gates) → Mechanism.AdmissibilityConditions (runtime entry predicates; a predicate may consume an exact grant or finding selected by A.6.B:8.4.1, but it neither creates nor resolves that object)
• D (Deontics) → generic-prescription or individual-duty A.2.8 claims and A6-AW-NORM-GRANT
• E (Work-Effects & Evidence) → actual-occurrence, evaluated-finding, and evidence claims, including the applicable E-side A6-AW-* row

Atomicity rule:

If a sentence mixes logical jobs, for example “MUST” plus a gate predicate plus an effect claim, it is not classifiable as a single statement. Per A.6.B, split it into atomic claims so each one has exactly one quadrant and, ideally, an identifier you can reference.

Micro‑template: Atomize → Classify → Place → Bind to EntityOfConcern, Description, or carrier → Register

1. Split the sentence into atomic claims, one logical job each.
2. Assign each claim to exactly one quadrant (L/A/D/E) using the matrix.
3. Place each claim into its correct section or publication form (stack layer + section).
4. Anchor A.7: name what each claim is about. For permission-looking wording, bind the direct object and participants required by the selected A6-AW-* row; the selected subject pattern or kind of direct object never supplies the quadrant.
5. Register: add the atomic claim to the Claim Register (if used) and ensure every downstream face references the claim by ID rather than paraphrasing.

Action outputs after classification:

• implement or repair an admissibility predicate when the claim being made is A-*;
• repair the exact normative source for a generic D claim, the actual duty bearer and A.2.8 result for an individual D claim, or the direct object named by the selected permission row;
• recover the exact actual occurrence, evaluated finding, or evidence path named by an E claim; use the selected E-side A6-AW-* row when permission wording is current;
• publish or update an MVPK face that cites L/A/D/E claim IDs rather than paraphrasing them;
• reopen the exact subject pattern when the classified statement is used beyond boundary wording; the selected A6-AW-* row names the permission-side subject pattern;
• downgrade the visible wording to cue use or source-finding only when the exact source is missing;
• keep the work claim or reliance claim local, reversible, or blocked only for the unsupported work claim or reliance claim while the source is repaired.

Informative example. Example rewrite (mixed → atomic):

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

After (classifiable + lintable):

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

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

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

After (classifiable + adjudicable):

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

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

#Authority-wording split examples

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

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

After (classifiable + source-ready):

• L-API-1 (Quadrant L): the API operation and rollback terms are defined in the signature vocabulary.
• A-API-1 (Quadrant A): a request is admissible only under the named subject, action, object, context, and policy-version predicate.
• D-API-1 (Quadrant D): the exact provider policy prescribes maintaining or enforcing A-API-1 under the named window and exclusions. If the claim is instead that one actual provider or operator bears this duty, cite its separately instituted A.2.8 commitment.
• E-API-1 (Quadrant E): rollback success is evidenced only by the named work traces, audit records, or metrics; a gate decision carrier can support gate passage, but not rollback execution by itself.

Here “approved” creates no extra claim: A-API-1 applies A6-AW-GATE, while any approval badge remains A6-AW-SOURCE unless another row's closing facts are present.

For a filled grant/exercise/evidence case and its near-misses, use A.6.B:8.4.5.4. It applies A6-AW-NORM-GRANT, A6-AW-EXERCISE, and the separate A.10 evidence claim by value; do not reproduce the subject-pattern map here.

Then:

• if a user is deciding whether the wording may guide action, enter A.15;
• if evidence, currentness, or provenance is live, attach the A.10 evidence relation;
• if trust, readiness, compliance, or release confidence is being raised, build the B.3 assurance tuple;
• if an actual gate decision or gate passage is asserted, cite A.21 OperationalGate(profile), GateDecision, and DecisionLogRef;
• if a flow witness or constraint witness is asserted, cite A.20 ConstraintValidity status or witness;
• if a permission-looking claim is asserted, use the selected A6-AW-* row and its subject pattern; an entry predicate or gate decision does not substitute for another row;
• if release, deployment, rollback, or execution Work is asserted, cite the exact A.15.1 dated occurrence; then use only the applicable A.15.1:4.6 row for an application result, A.15.PROD production branch, delivery/transfer relation, evaluation/acceptance relation, or A.10 evidence path. None is an intrinsic Work field;
• if the phrase is only an action invitation or cue, keep it in A.6.A, A.16, or A.16.1 according to the current kind.

Policy engines, credentials, registers, provenance, and attestations can supply policy decisions, source claims, currentness, or evidence. Start a visible permit, badge, or registry value at A6-AW-SOURCE; move to another branch only when its named direct object and participants are independently established.

#View membership needs exact viewpoint conformance

MultiViewDescribing makes the candidate episteme and exact viewpoint episteme explicit. The candidate has U.View membership only when E.17.0 conformance obtains. A projection or query may participate in an A.6.3 construction, but that construction does not establish membership. MVPK separately fixes a closed set of publication face classes (PlainView, TechCard, InteropCard, AssuranceLane).

A disciplined stack therefore requires:

• Every published face use identifies the exact selected episteme, the exact viewpoint episteme through U.ViewpointRef, the publication occurrence, the form, and the carrier. The face class is not any of those objects.
• Calling the selected episteme a U.View requires E.17.0 conformance; a face label, viewpoint reference, projection history, or publication does not establish it.
• Per E.17 (“no new semantics”), a face MUST NOT introduce a new semantic commitment or any new object or claim selected through A6-AW-*. A face MAY add informative explanation, examples, and cross-references. Every normative sentence cites the canonical L/A/D/E claim ID and direct object or moves into the canonical claim set.
• Per E.17 and publication-face and publication-form discipline (face‑kind closure), a publication package that claims MVPK alignment MUST NOT mint additional MVPK face kinds (e.g., “EvidenceCard”, “NormsCard”) as if they were first‑class kinds; if you need local headings, keep them as sections within the canonical face kinds.

#“Contract” unpacking: avoid assigning agency to epistemes

When practitioners say “the API contract”, they usually compress several independently optional objects into one word. Use A.6.C to ask the four plain questions—what was promised, what was said or instituted, what governance position obtains, and what actually happened—then use A.15.1:4.6 to separate the dated Work from any result, production, delivery/transfer, evidence, or acceptance claim.

• Promise content (promise content; U.PromiseContent, A.2.3): what is promised to be made available to eligible consumers — a promise, not execution (U.Work).
• Utterance package (published descriptions + instituting act): what is said and published and versioned (signature or mechanism descriptions plus MVPK faces), plus the U.SpeechAct <: U.Work that published or approved it when provenance matters (A.2.9).
• Commitment (individual deontic relation; U.Commitment, A.2.8): whether one actual admitted System or other party is obligated, recommended-as-duty, or prohibited from doing something under an exact constitutive rule and required instituting basis. A system-role kind or assignment may help satisfy that rule's applicability conditions; neither is the duty bearer or the commitment relation. A commitment does not establish responsibility, which needs its own direct domain predicate or an exact missing-governor result.
• Permission-looking claim: do not make Permission a bundle part or quadrant. Select one A6-AW-* row for each atomic claim and cite its direct object.
• Performed Work (A.15.1): whether one dated Work occurrence happened, who performed it, which Method it enacted, when it happened, and within which System. Recover each exact performer through A.13 and admit the Work independently through A.15.1. Only when the receiving account expressly consumes precise assignment-bound attribution, recover the exact A.2.1 assignment independently and let F.6 check its link to the Work through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and a failed or absent result does not revoke Work. This claim supplies no result, delivery, or acceptance by itself.
• Result or consequence (A.15.1:4.6 dispatch): only when current, name the exact A.6.1 application/result binding or subject-specific WorkResultRelation, A.15.PROD production branch, A.3.4 change, evaluation result, delivery/transfer relation, or acceptance relation.
• Evidence (A.10): only when a receiving use relies on one of those claims, name the claim-bound evidence path and carrier. Evidence supports that claim; it creates neither Work nor its result.

In A.6 terms:

• The signature is the utterance substrate for the boundary; it is not itself a promiser or obligor (A.7).
• Deontic claims use A.2.8 for generic prescriptions or separately obtaining individual duties and commitments, and A6-AW-NORM-GRANT for the current norm/grant branch. Other permission-looking claims keep the placement and object named by their selected row.
• Operational “guarantees” are empty rhetoric unless each atomic claim is classified as L (truth-conditional law), A (entry predicate), D (generic prescription, individual commitment, or current grant), or E (actual exercise, evaluated result, work effect, or measured property with evidence).

Compact optional-object replay. SVC-DEPLOY-1 states promise content. Admitted system ReleaseManager-4 performs SA-4711 : U.SpeechAct under ReleaseManager-4@ReleaseShift; the exact policy may institute COM-4711 : U.Commitment or PER-4711 : GrantedPermissionRelation@Context. Later admitted system Operator-7 performs DeployRun-4711 : U.Work under its covering assignment. If the application returns ReleaseArtifact-4711, cite the exact A.6.1 result binding or an already governed WorkResultRelation; if that artifact is delivered, cite a separately obtaining transfer relation defined by its subject pattern; if acceptance is claimed, cite the criterion, evaluation Work/result, and acceptance relation. An A.10 path may support whichever one of those claims is relied on. Omit every absent object: the Work can occur without a result, delivery, acceptance, or evidence-use claim.

This paragraph is a compact reminder; the reusable expansion and the same A.15.1:4.6 dispatch belong in A.6.C — Contract Unpacking for Boundaries.

#Where statements go (classification examples)

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

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

Notes:

• The classification is not just about modal verbs. “Shall” can be D (a duty) or A (a gate behavior). “Guarantees” can be D (a commitment) or E (a measured property). The matrix forces disambiguation.
• If a sentence reads like “X MUST … if … then …”, it almost always bundles multiple quadrants. Split it into (A) a gate predicate (A-*), (D) either a general prescription or a claim about one exact U.Commitment borne by an actual System or other admitted party (D-* referencing the gate ID), and (E) an evidence claim (E-*) if observability matters. A system-role kind or assignment may establish applicability only through an independently obtaining rule; neither bears the duty.
• When something needs to be enforceable but is mathematical, prefer predicate blocks rather than deontic language in the L/A blocks, per E.8’s deontics vs admissibility guidance.

#Classification sanity rules (informative, concept-level)

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

• RFC keyword inside Definition, invariant, or admissibility predicate → classification error (rephrase as predicate; move obligation to D-*).
• E-* with no exact actual occurrence or evaluated predicate, or with a carrier but no evidence relation for the claimed use → incomplete effect/evidence claim. Ground Work through A.15.1 only when it actually obtains; otherwise use A.3/A.3.4 or the exact interaction or causal-use pattern. A carrier supports the claim but does not create the effect.
• 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 the canonical claim set → view-fork (make it informative only, or repair the exact direct object and classify its claim: duty/commitment/grant in D; exercise/evaluated finding/evidence in E; gate in A).
• “The system or service SHALL …” where the phrase does not name a direct behavior claim, general prescription, or exact individual commitment with its actual bearer and constitutive basis → unresolved subject and modality. Recover the System or other party, state the E-* behavior separately, and state either the normative content or the direct A.2.8 commitment. A service label, system-role kind, or assignment proves none of these claims.

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

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

#Tell (universal rule)

A boundary description is evolvable iff its claims are separated across the signature stack and each statement is classified as Law, Admissibility, Deontic duty/commitment/grant, or the boundary's observable-effect/evidence family. An E claim names the exact actual occurrence under its subject predicate and retains the pattern only as a locator: dated Work only when the A.15.1 predicate is satisfied, or A.3/A.3.4 plus the exact interaction or causal predicate for non-Work change. EntityOfConcern, description, and publication carrier remain separate.

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

System: A “Payment Authorize” service.

• Signature layer (A.6.0).

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

• Mechanism layer (A.6.1).

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

• Actual occurrence and work layer.

  • The payment-handling occurrence is U.Work only when its exact actual performer first has the A.13 core and A.15.1 independently admits the occurrence from its Method, time, containing System, and other required direct facts. If this payment account also asks under which assignment the performer acted, add F.6 through the same obtaining A.13 assignment; missing or failed attribution leaves the payment Work intact.
  • The ledger reservation change, event emission, timer transition, or retry effect is a separate actual-occurrence claim under A.3/A.3.4 or its exact interaction or causal-use pattern. Check each effect separately: knowing that the payment Work occurred does not show that the ledger changed, an event was emitted, or a retry happened.
  • Traces, logs, and metrics enter an A.10 evidence path for the exact effect being relied on; carrier presence creates neither Work nor change.

• Publication faces (MVPK).

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

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

Classification example:

• “Defined iff tokenValid” belongs in Quadrant A (admissibility gate).
• “Clients MUST include Idempotency-Key” belongs in Quadrant D as a normative prescription and should reference the same gate semantics to avoid divergence. It becomes a claim about one obtaining individual U.Commitment only after A.2.8 identifies the actual bearer, constitutive rule, required instituting basis, and direct predicate.
• “System emits AuthorizationRecord” belongs in Quadrant E (evidence via carriers).

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

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

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

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

• Deontics and commitments: the protocol may prescribe that reviewers use dataset vX.Y and that authors publish MVPK faces and cite the measurement environment. If an organisation has an individual review-SLA duty, identify that actual admitted System or other A.2.8 party as bearer and establish the direct U.Commitment predicate. Any system-role classification or assignment remains a separate possible applicability ground.

• Effects and evidence: the dated evaluation run is a Work occurrence only when A.15.1 grounds it; its result episteme, any model or dataset change, and the report publication remain separate. Report files, logs, hashes, and trace IDs support the selected claims through A.10 but create none of those occurrences or results.

Non-Work E contrast. A seedling's spontaneous first-leaf unfolding can be an actual A.3.4 transformation with no performer, assignment, method, or Work occurrence. Measurements may support that exact change claim through A.10; neither the observation work nor its carrier becomes the change.

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

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

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

#Bias-Annotation

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

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

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

A boundary is simultaneously:

• a mathematical object (signature: operations over vocabulary, governed by laws),
• an engineering boundary signature (stable intent, evolvable implementations),
• a governance object (commitments, responsibilities, deontics), and
• an actual-occurrence and evidence concern (effects may arise through Work, natural or spontaneous transformation, formal change, or another directly governed interaction, and evidence supports but does not create them).

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

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

#SoTA-Echoing (post-2015 practice alignment)

Informative. Alignment notes; not normative requirements.

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

• Adopt — session and behavioural types for protocol boundaries. Post-2015 practice in behavioural typing treats boundaries as typed interaction protocols with progress and safety properties. A.6’s classification matrix makes protocol laws (Quadrant L) explicit and separates entry gates (Quadrant A) from general prescriptions or exact individual commitments (Quadrant D) and runtime evidence (Quadrant E), reducing ambiguity.

• Adapt — categorical optics, lenses, and bidirectional transformations. Contemporary lenses supply useful construction expressions with coherence laws. FPF uses that lesson only for explicit A.6.3 construction or C.29 representation: a projection expression, publication face, and U.View remain different objects, while any cross-context reuse stays explicit.

• Adapt — model-based views-as-queries practice. Query and projection operations can construct candidate epistemes and make omissions inspectable. E.17.0 still tests each candidate independently against one exact viewpoint episteme; generation, selection, or a viewpointRef alone supplies no U.View membership.

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

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

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

• Adopt, adapt, and reject stance for authority-looking boundary wording. A.6 adopts policy-as-code separation of text from evaluated decisions, uses credentials and registers as source/currentness evidence, and rejects any visible wording or display as a substitute for the selected A6-AW-* branch.

• Adapt — Markov blankets and active inference as probabilistic boundary views only after restoration. Markov-blanket thinking can help pick observables and diagnose boundary-condition failures, but the source phrase must be restored before it carries an A.6 boundary claim. It may name accepted local Markov dynamics, a mathematical or probabilistic lens, a holon delimitation or crossing relation, an interface, an interface module, a physical component, a boundary description, or an agency-threshold claim. A.6 uses the phrase only after the boundary claim set is recovered; it does not replace deontics, invariants, admissibility gates, or the subject pattern of the physical or mathematical claim.

#Relations

• Implements authoring discipline: Follows canonical section order and style expectations from E.8.
• Uses A.6.B as the classification authority: A.6.B:8.4.1 selects the job of permission wording. A.6 maps the resulting atomic claim to the stack; it does not put every A.2.8.PER object in D. The filled case in A.6.B:8.4.5.4 is the concrete handshake.
• Coordinates actual effects without merging them: Use A.15.1 only to identify a grounded dated Work occurrence; use A.3.4 for an independently identified actual transformation, including spontaneous or formal change with no Work; state each interaction, causal, production, speech-act, evaluation, evidence, or result claim through its applicable predicate and pattern. A description or carrier creates none of them.
• Constrains signature writing: Reinforces A.6.0 separation of Laws vs operational gates (AdmissibilityConditions live in mechanisms).
• Constrains mechanism writing: Aligns with A.6.1 structure (Signature block plus mechanism‑only blocks such as AdmissibilityConditions, Transport, Audit).
• Requires EntityOfConcern and Description-episteme / publication-carrier discipline: Uses A.7 to prevent category mistakes; ties evidence to evidence carriers and publication faces to descriptions.
• Coordinates U.View, U.Viewpoint, and publication use: E.17.0 governs viewpoint and view membership; MVPK selects exact epistemes, viewpoints, face uses, and publication forms; A.6.3 governs only optional source-to-receiving construction.
• Unpacks “contract” talk: A.6.C, A.2.3, A.2.8, A.2.8.PER, and A.2.9 keep promise content, speech act, commitment or grant explicit; use A.15.1 only to identify dated Work, and its §4.6 dispatch requires the exact subject predicate for each application-result, production, change, delivery/transfer, evidence, or acceptance claim.
• Connects to signature engineering patterns: A.6.5 (slot discipline) and A.6.6 (anchor and base discipline) can be read as “constructor and enabling” operations that help build well‑formed signatures by disciplined unpacking and grounding (they belong in the same stack discipline because they govern boundary construction).
• Coordinates with C.28 CausalUse-CAL: When boundary prose uses causal-use evidence or a causal-use verdict to justify deployment, release, duty, commitment, or admissibility, A.6 splits the boundary sentence while C.28 carries the causal-use question, CausalityLadderRung, estimand, support basis, support verdict, and supported causal use and unsupported causal use.
• Coordinates work and consequences: A.15.1 supplies only a dated U.Work occurrence. Its §4.6 table routes an application/result binding, production, change, evaluation result, evidence use, delivery/transfer, and acceptance to separate subject patterns. A.15, A.10, B.3, A.21, and A.20 govern the exact work-use, evidence, assurance, gate, or constraint claim when current.

#Quantum-like boundary-claim classification note

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

Action classification:

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

Minimum boundary discipline before a quantum-like boundary reading:

Useful outputs:

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

#A.6:End

#Recognition Signatures for Descriptions

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

#Problem frame

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

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

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

What goes wrong if this pattern is missed:

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

What this pattern buys:

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

Ordinary not-this-pattern boundary:

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

#Problem

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

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

#Forces

#Solution

#Relation-signature object and non-goals

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

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

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

Use definitionEpistemeRef for the defining U.Episteme. If the definition is available only through one publication, cite the U.EpistemePublication that publishes it separately; the publication, projection, or carrier does not become the defining episteme merely because it exposed the definition to the reader.

A.6.RSIG does not govern:

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

#Two-level description-recognition shape

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

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

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

description_seen
encountered_carrier_or_projection
reader_viewpoint
case_signal_or_access_condition
applies_to
excludes
expected_first_recognition_gain
first_admissible_entry_stop_or_reroute
definitionEpistemeRef
projection_role_if_any
nearby_false_description_or_wrong_definition_episteme

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

#Minimal local repair and review sequence

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

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

Minimal admissible output:

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

#Parent cases

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

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

#Neighbor boundaries

Neighbor boundaries remain explicit:

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

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

#No-minting rule

This pattern does not mint:

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

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

#Archetypal grounding

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

Draft cue:

"The system shall reject invalid requests."

Why the cue is not enough yet:

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

Recognition repair:

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

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

Draft cue:

"POST /deploy triggers deployment."

Plausible but wrong first reading:

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

Recognition repair:

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

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

Draft cue:

"Use pairwise comparison."

Why the cue is not enough yet:

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

Recognition repair:

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

#Bias-Annotation

This pattern counters:

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

#Conformance checklist

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

#Common Anti-Patterns and How to Avoid Them

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

#Consequences

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

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

#Rationale

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

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

#SoTA-Echoing

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

#Relations

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

#A.6.RSIG:End

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

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

#A.6.B:0 — Conventions

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

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

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

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

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

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

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

Adjudication substrate (for classification). For the purposes of this square, an atomic claim is classified by where its own truth condition or governance content is settled. This tells you how to classify the sentence; it does not make an individual commitment, grant, or finding exist.

• In-description or in-theory: an L-* truth condition is settled by inspecting, proving, or type-validating the description; a generic D-* claim states exact normative content, while an individual D-* claim names the commitment or grant it concerns.
• In-work or in-execution: deciding satisfaction requires observing executed work, inspecting carriers produced in work, or both.

Note (important). Writing a D-* claim records either generic normative content or a claim about an individual duty, commitment, or grant; it does not institute an individual relation or establish compliance. When the wording is about permission, use the permission-word branch in §8.4.1 to recover the exact object, what makes it obtain, and the evidence needed before reliance.

Modality family. A claim is either:

• Truth‑conditional: definitions, invariants, typing rules (“is”, “iff”, “∀”).
• Governance: prescriptions, individual obligations or commitments, grants, and exclusions (the RFC keywords MUST, SHOULD, and MAY, “is admissible”, “is blocked”, “commits to”).

#A.6.B:1 — Problem frame

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

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

#A.6.B:2 — Problem

When authors cannot reliably answer two questions—

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

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

A boundary needs a minimal, stable classification that:

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

#A.6.B:3 — Forces

#Solution — the Boundary Norm Square

#Two independent distinctions

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

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

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

#A.6.B:4.2 — The square

Clarification (classify the claim by its job, not by its subject pattern).

• Classify the exact atomic claim by what its sentence states and by the conditions that let a reader decide it.
• The exact ClaimGraph located through the subject pattern supplies the referenced object's predicate and obtaining conditions; it does not choose the claim's quadrant.
• When permission wording is present, use the single permission-word branch in §8.4.1. It separates the possible jobs of that wording without inventing a common “permission result” kind.

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

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

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

The quadrants have canonical placements in the boundary stack:

• L → Signature layer: U.Signature.Laws (and mechanism‑local semantic laws if present).
• A → Mechanism layer: U.Mechanism.AdmissibilityConditions (entry gates / runtime admissibility predicates).
• D → Deontics & Commitments layer: atomic claims about a generic prescription or about one separately obtaining individual duty, recommendation-as-duty, prohibition, or commitment. When permission wording is live, §8.4.1 decides whether its claim also belongs here.
• E → Work-Effects & Evidence layer: truth-conditional claims whose satisfaction requires actual work, evaluation, observation, or produced carriers.

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

#A.6.B:5 — Quadrant specifications

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

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

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

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

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

Prohibitions.

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

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

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

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

Intent. Specify when a mechanism application is admissible: runtime entry predicates, validity gates, and applicability checks that require context or execution environment. An A-* predicate may consume a separately established result as one input, but it does not create or settle that result. If the sentence uses permission wording, choose its job with the branch in §8.4.1.

Common mistake #0 — Applicability ≠ Admissibility (informative). Signature Applicability scopes intended use and bounded context; it is not a runtime entry gate. Runtime entry checks and admissibility predicates belong in U.Mechanism.AdmissibilityConditions as A-*. If prose reads “clients must satisfy the applicability”, separate the A-* gate from either a generic D-* prescription or, when independently instituted, an individual duty linked to that gate.

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

Canonical form. Predicate style, e.g.:

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

Prohibitions.

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

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

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

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

Intent. State one atomic deontic claim. A generic prescription states what one exact policy or other normative episteme requires; it does not create an individual duty bearer or commitment occurrence. A claim that one actual System or separately governed party has that duty instead cites one separately obtaining A.2.8 U.Commitment. When a sentence sounds permissive, use §8.4.1; only its Grant or norm row enters D. Writing the D-* sentence neither institutes a relation nor establishes compliance.

Adjudication. For a generic prescription, inspect the exact normative source, its applicable rule content, scope, and current edition. For an individual duty, apply A.2.8 to the separately obtaining commitment and its actual basis. The wording itself decides neither obtaining nor compliance.

Canonical form. First choose the route. A generic D claim names the normative episteme and the rule content being stated, without inventing an individual bearer. An individual-duty D claim names the actual bearer and exact U.Commitment; a system-role kind or assignment may be a rule ground but is neither bearer nor duty. A responsibility claim uses an admitted domain responsibility predicate and its actual participants, or returns its exact missing governor. A permissive-looking word does not by itself select D; use §8.4.1 for the grant route. Examples:

• Generic: “APIEntryPolicy-v4 requires covered clients to satisfy A-….” No individual commitment is asserted.
• Individual: “Actual bearer ClientIntegrator-A has commitment COM-17 to satisfy A-….”

Canonical assertion (recommended; lintable). Use a CommitmentAssertion only when an individual-duty claim must be reused or audited. It concerns one exact separately obtaining U.Commitment and makes explicit:

• entityOfConcernRef, resolving to one exact U.Commitment occurrence, and the D-* claim ID;
• exactly one actual bearer branch: dutyBearerSystemRef or dutyBearerPartyRef;
• non-empty exact dutyReferentRefs and any actual counterparties;
• the A.2.8 DeonticModalityToken, scope, and validity window;
• the exact current constitutive policy, individualizing rule, and actual instituting basis required by that rule; and
• evidence-claim or carrier references only when the receiving reliance or adjudication needs them.

The assertion states and supports a claim about the relation. Its fields, publication, and evidence do not make the relation obtain.

Prohibitions.

• A generic D-* statement MUST NOT invent an individual bearer or commitment; name its exact normative source and rule content. An individual-duty D-* statement MUST NOT use “the system, service, interface, or specification” as a vague subject; name the actual duty-bearing system or separately governed party and exact U.Commitment, with an assignment only when the constitutive rule uses it as a ground. Use A.6.C when promise, utterance, approval, guarantee, or agreement-like boundary language is live.
• A D-* statement MUST NOT restate L-* or A-* predicates in new words when an ID exists; it SHOULD reference the ID.
• A D-* statement MUST NOT pretend that a duty, commitment, or grant is a law or that writing the claim makes it obtain.

A.7 EntityOfConcern binding. A generic D-* claim episteme concerns the exact normative rule content it states. An individual D-* claim concerns the exact duty, commitment, or grant named by its content and does not substitute for that object. When permission wording is live, the branch in §8.4.1 names the subject pattern and the obtaining or non-obtaining test.

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 a truth-conditional result that can be settled only from actual work, evaluation, observation, or produced carriers.

Adjudication. In-work or by an exact evaluation of work and its conditions. Reading a subject-pattern description or seeing a record is not enough.

Canonical form. Write the ordinary result first, then make recoverable only what settles it:

1. the exact predicate and object that the claim concerns;
2. the participants, work or evaluation occurrence, scope/window, comparison frame, and other conditions required by that predicate; and
3. the evidence or source-use relation and its carrier only when a gate, plan, audit, or assurance decision relies on that support. A carrier may support the claim but does not create the work, effect, or finding.

When permission wording is current, use the branch in §8.4.1 for the exact occurrence or finding, its failure test, predicate, and subject-pattern locator; do not repeat that subject-question catalogue here.

Prohibitions.

• E-* statements SHOULD NOT use RFC deontic keywords; they report adjudicable results rather than obligations.
• An E-* statement MUST NOT hide a gate predicate; gate predicates are A-*.
• An E-* statement MUST NOT assign agency to an interface, record, or publication. For any precise cited Work, first recover each exact actual performer through A.13 and let A.15.1 independently admit the dated Work. Add an exact A.2.1 assignment reference and F.6 only when this claim or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither the assignment nor the performer, and missing or failed F.6 leaves the Work intact. If enforceability or commitment is intended, express a separate D-* claim.

A.7 EntityOfConcern binding. An E-* claim episteme concerns the exact work effect, evaluated finding, evidence relation, or carrier condition named by its predicate. A record or carrier is a separate object and becomes the concern only when its existence or condition is itself the claim.

Required references (explicit).

• If the result is conditioned on a gate decision, the E-* statement SHOULD reference the relevant A-* ID(s).
• If another object is needed to settle the predicate, reference that object's subject pattern without importing its quadrant.
• If evidence is used for reliance, cite the exact A.10 or G.6 evidence-use relation rather than treating carrier presence as truth.

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

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

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

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

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

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

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

#(D → A) Prescription-or-duty-to-gate linkage

When governance says that a gate must be satisfied or enforced:

• generic D-*: “Policy-P requires covered subjects to satisfy or enforce A-*”; or
• individual D-*: “Actual bearer S has commitment C to satisfy or enforce A-*.”

This separates what is admissible (A) from generic normative content and any separately instituted individual duty (D). If responsibility is also claimed, state its admitted direct domain predicate or exact missing governor rather than inferring it from the duty.

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

When gate decisions must be observable:

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

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

#(D → E) Prescription-or-duty-to-evidence linkage

When governance prescribes evidence production, retention, exposure, or a measured property:

• generic D-*: “Policy-P requires covered subjects to retain or expose carrier class C used by E-* …”; or
• individual D-*: “Actual bearer S has commitment CMT to meet E-* under exclusions …”

This separates a generic prescription or individual duty (D) from its adjudication (E).

#(A/E → L) Semantic grounding linkage

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

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

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

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

When a generic prescription or individual obligation relies on precise term or metric meanings:

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

This keeps governance text from accidentally redefining semantics in prose.

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

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

• A: admissibility predicate (A-*)
• D: generic prescription or individual-duty claim referencing the gate (D-* → A-*)
• E: evidence binding referencing the gate and carriers (E-* → A-*)

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

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

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

Normative rule (no upward dependencies).

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

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

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

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

Guidance (informative):

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

#Archetypal Grounding (Tell–Show–Show)

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

#Tell (universal rule)

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

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

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

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

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

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

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

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

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

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

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

#Goal

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

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

#Micro-procedure (Atomize → Classify → Triangle → Link → Bind References → Recompose)

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

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

• L if the claim is truth‑conditional and adjudicable in‑description (inspection, proof or type validation, or model reasoning over declared assumptions): definitions, invariants, typing and well-formedness constraints. Guardrails: L-* MUST NOT (i) use RFC deontic keywords as operators, (ii) encode runtime entry predicates (those are A-*), or (iii) assert evidence existence or measurement outcomes (those are E-*).
• A if it is an in‑work gate predicate: what the mechanism admits at application time (“admissible iff …”). It is not a duty and MUST NOT be phrased as one. Guardrails: A-* SHOULD be written in predicate form and MUST NOT (i) use RFC deontic keywords as if it were an agent obligation, (ii) claim that evidence carriers exist (that is E-*), or (iii) assign responsibility or enforcement (that is D-*). (Do not confuse this with Signature.Applicability: applicability scopes intended meaning and intended use; it is not a runtime entry gate.)
• D if the exact atomic statement states either a generic prescription or an individual duty, recommendation-as-duty, prohibition, or commitment. A permissive sentence enters D only through the Grant or norm row below. Guardrails: a generic claim names the exact normative episteme and applicable rule content without inventing an individual relation. An individual-duty claim names its actual bearer and exact separately obtaining A.2.8 commitment. A grant claim instead follows the participant and ground test in the Grant or norm row. A system-role kind or assignment may be a rule ground but is neither bearer nor deontic relation. Writing any claim does not make its object obtain.
• E if it is an in-work truth-conditional claim whose satisfaction requires actual work, evaluation, observation, or produced carriers. Predicate-specific minimum: name the exact E-* predicate and object, then the actual work, evaluation, or observation, scope/window, comparison frame, and other settling conditions that this predicate needs. Add an evidence or source-use relation, carrier/schema, viewpoint, or consumer only when the receiving gate, plan, audit, assurance, or other reliance decision depends on that support. Guardrails: E-* SHOULD NOT use RFC deontic keywords, MUST NOT hide a gate predicate (that is A-*), and MUST NOT cite D-*. (If the source sentence is “Role SHALL measure, retain, or expose …”, first decide whether it is a generic prescription about an exact system-role kind or a claim about one actual bearer. Classify either as D, but assert an individual commitment only on the second route.)

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

• A: the admissibility predicate (what must be true to treat the claim as applicable),
• D → A: which exact policy prescribes keeping or enforcing the predicate, or which actual bearer has that separately instituted duty; any responsibility relation is stated separately under its direct domain predicate
• E → A: what evidence or traces are used to adjudicate the predicate.

Permission-word branch (use only when the sentence sounds permissive). Choose the row by the job the sentence performs, not by the word may, approved, authorized, or permitted.

Choose one row. If one sentence answers two questions, split it before classification. If the sentence is not permission-like, do not use this branch. The branch classifies claims and selects existing subject patterns; it creates no permission result umbrella. Use the filled case in §8.4.5.4 when a concrete model is needed; point back to that case rather than adding another pattern list.

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

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

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

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

Step 5 — Bind references (minimal A.7 discipline).

• Place L claims in Signature.Laws (and mechanism-local semantic laws if present), and A claims in Mechanism.AdmissibilityConditions.
• Bind a generic D claim to its exact normative episteme and applicable rule content. Bind an individual-duty D claim to its actual duty-bearing System or separately governed party and exact U.Commitment; cite an assignment only when the constitutive rule uses it as a ground. State responsibility and authority, when claimed, through their own admitted direct relations or exact missing governors. Prefer ID references rather than restating L-* or A-* content.
• Bind each E claim first to its exact predicate/object and to the actual work, evaluation, observation, scope/window, comparison frame, and other conditions that settle that predicate. Add a carrier/schema, evidence or source-use relation, viewpoint, and consumer only when a receiving reliance decision depends on them; a claim about a carrier's own existence or condition names the carrier as its object.

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

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

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

#Anti-pattern (quick)

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

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

#Draft sentence (non-conformant)

“This API guarantees p95 latency < 200ms.”

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

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

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

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

D-API-01 (Commitment). Admitted service-maintaining system ServiceOperations-A is the actual duty bearer of separately obtaining LatencyCommitment-API-01 : U.Commitment; under that commitment it SHALL meet p95_latency < 200ms when A-API-01 holds, adjudicated per L-API-01 using the carriers and observation conditions in E-API-01. (References L-API-01 and A-API-01 by ID; does not restate them.)

D-API-02 (Operational duty). Admitted operations system SRE-A is the actual duty bearer of separately obtaining IncidentNoteCommitment-API-02 : U.Commitment; it SHALL publish incident notes when LatencyCommitment-API-01 is violated and SHALL avoid claiming compliance outside A-API-01. (References D-API-01 and A-API-01 by ID.)

E-API-01 (Evidence / carriers). For decisions under A-API-01, the following carrier classes are produced or observable under the declared observation conditions: trace IDs and span IDs, raw histogram carriers with schema reference, percentile dashboard snapshots, and pinned sampling configuration for window W. Observation conditions (minimum): workload profile selector, sampling method and configuration pins, and computation method reference (L-API-01). Viewpoint and consumer (minimum): the admitted System, viewpoint, or consumer that uses the carriers to adjudicate the gate or audit commitments; cite an exact system-role assignment only when its identity matters to Work attribution or another independently governed predicate. (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). Admitted telemetry-maintaining system TelemetryOperations-A is the actual duty bearer of separately obtaining TelemetryRetentionCommitment-API-03 : U.Commitment; it SHALL retain or expose the carrier classes referenced in E-API-01 for the audit window required by policy. (References E-API-01 by ID.)

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

#Triangle decomposition (explicit)

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

#Readable recomposition

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

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

Plain recomposition (one paragraph, readable): “The API’s latency target uses the p95 definition in L-API-01 and is only applicable under the declared operating envelope A-API-01. ServiceOperations-A has the latency duty stated in D-API-01. Adjudication uses the telemetry carriers listed in E-API-01; TelemetryOperations-A has the retention duty in D-API-03, and SRE-A has the incident-note duty in D-API-02. Under that envelope, the observed p95 over Γ_time=[t1..t2] was 173ms (E-API-02).”

#Example 2 — Mechanical engineering (fit / coaxiality)

#Draft sentence (non-conformant)

“This fit ensures coaxiality.”

#Atomize + Classify

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

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

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

D-FIT-01 (Duty). Admitted production-engineering system ProcessEngineer-A is the actual duty bearer of separately obtaining ProcessEnvelopeCommitment-FIT-01 : U.Commitment; it 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). Admitted quality-engineering system QualityEngineer-A is the actual duty bearer of separately obtaining FitEvidenceRetentionCommitment-02 : U.Commitment; it SHALL retain or expose the carriers referenced in E-FIT-01 for the production lot. (References E-FIT-01 by ID.)

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

#Readable recomposition

Tech bundle:

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

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

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

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Classify

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

A-PRJ-01 (Gate predicate: stage entry). For starting execution work, ExecutionAdmissible(project) holds iff required approvals are present and required prerequisites are satisfied (e.g., risk review completed, budget line exists, key roles staffed). (This is the real “may start work” entry predicate; it references L-PRJ-01 for what counts as approvals. If “approved” is meant as permission rather than gate evidence, use the permission-word branch in §8.4.1. An approval registry entry or evidence carrier alone remains source/display evidence and is not a grant.)

D-PRJ-01 (Duty). Admitted project-coordination system ProjectCoordinator-A is the actual duty bearer of separately obtaining ProjectEntryCommitment-PRJ-01 : U.Commitment; it SHALL not initiate execution unless A-PRJ-01 holds, SHALL keep the approval registry current, and SHALL retain or expose the evidence carriers referenced in E-PRJ-01. (References A-PRJ-01 and E-PRJ-01 by ID.)

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

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

#Readable recomposition

Tech bundle:

• “Approved” is not one relation: L-PRJ-01 defines approval kinds.
• “May start execution” is a gate predicate: A-PRJ-01.
• ProjectCoordinator-A's project-entry duty: 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). ProjectCoordinator-A has the project-entry and registry-maintenance duties stated in 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).”

#Filled permission case (each sentence classified)

E-CAL-01 (Instituting communicative Work). Admitted system MaintenanceCoordinator-A performed dated CalibrationGrantAct-17 : U.SpeechAct under MaintenanceCoordinator-A@DayShift; that obtaining assignment has the system as holder and covers the act. In this filled case, CalibrationGrantPolicy-v4 does not require a separate authority relation, so none is asserted. The assignment supplies no authority and performs no act. CalibrationGrantAct-17 satisfies the policy in PlantCalibrationContext and is the actual instituting Work. A policy variant that does require grant authority must cite one exact obtaining authority relation under its direct predicate or stop at missing-governor[grant authority].

D-CAL-01 (Grant position). MaintenanceCalibrationGrant-17 : GrantedPermissionRelation@Context, instituted by CalibrationGrantAct-17—the actual speech act stated in E-CAL-01—permits beneficiary MaintenanceTechnicianSystemRole to run CalibrationProcedure-v3 in Zone 8 during ServiceWindow-17. CalibrationGrantPolicy-v4 remains current, the grant still covers that system-role kind, procedure, zone, and window, and no valid revocation or supersession has ended this occurrence; this D-* claim records the grant but does not institute it.

A-CAL-01 (Gate). CalibrationEntryAdmissible(plan, checkTime) holds only if MaintenanceCalibrationGrant-17 is current for the plan's beneficiary, action, zone, and time and no applicable permission/norm conflict finding is unresolved. The gate consumes those inputs; it creates neither the grant nor a conflict result.

E-CAL-02 (Actual Work and actor). Through its A.13 core, admitted system Tech-17 is the exact actual performer for this case under obtaining assignment Tech-17@Shift-B, whose holder is Tech-17 and whose extent covers the early part of ServiceWindow-17. A.15.1 independently admits dated CalibrationWork-17B : U.Work from that performer, its Method, extent, and containing-System facts. Because this filled case expressly claims precise assignment-bound attribution, F.6 separately relates CalibrationWork-17B to that same assignment. The assignment neither acts nor identifies the performer; failed attribution would leave the Work intact and remove only the under-assignment claim.

E-CAL-03 (Optional exercise claim). Because this case asks whether the grant was used, CalibrationExercise-17B : PermissionExerciseRelation@Context connects CalibrationWork-17B to MaintenanceCalibrationGrant-17: the Work instantiates CalibrationProcedure-v3; Tech-17@Shift-B is an assignment occurrence whose declared species uses MaintenanceTechnicianSystemRoleKindDomain as its assigned-kind domain, and the occurrence supplies MaintenanceTechnicianSystemRole as the value admitted by that domain; and the Work occurs in Zone 8 within ServiceWindow-17 while the grant is current. If the action or beneficiary test failed, this exercise relation would not obtain.

D-CAL-02 (Exercise non-use boundary). The authoring rule says to add E-CAL-03 only when the reader needs to know whether the grant was exercised; otherwise stop with the separately named grant and Work. This is a generic prescription for boundary text, not a claim that one particular author bears an individual U.Commitment.

E-CAL-04 (Later non-violation finding). Through its A.13 core, admitted system ComplianceEvaluator-4 is the exact actual performer under obtaining assignment ComplianceEvaluator-4@QualityShift. A.15.1 independently admits dated CalibrationComplianceEvaluation-17B : U.Work; because this finding expressly preserves precise assignment-bound attribution, F.6 separately relates that Work to the same assignment. The Work checked CalibrationWork-17B against current PlantCalibrationNormativeFrame-17, explicitly complete enough for this technician, procedure, zone, and evaluation window, and returned CalibrationNonViolation-17B : NonViolationFinding@Context(result=nonViolating). A stale or insufficient frame would return unresolved; a missing or failed F.6 relation would instead leave the Work and evaluation result intact while removing only the attribution.

E-CAL-05 (Evidence for reliance). An A.10 evidence-provenance path links the exact CalibrationNonViolation-17B finding to CalibrationComplianceEvaluation-17B, ComplianceEvaluator-4@QualityShift, CalibrationRunLog-17B, the log's source and currentness relations, and the bounded audit context. The path supports reliance on the finding; the log, assignment, and path do not perform the evaluation or create its result.

E-CAL-06 (Unresolved conflict). After CalibrationWork-17B and its evaluation, Zone8EntryProhibition-17 becomes current for the same beneficiary, action, zone, and the remaining service window, including the calibration action specified by CalibrationWorkPlan-17C; no applicable rule selects an outcome and no authorized dated decision Work with a current resolution result exists. CalibrationConflict-17 : PermissionNormConflictFinding@Context therefore remains unresolved.

A-CAL-02 (Gate outcome). At the later entry check for CalibrationWorkPlan-17C, A-CAL-01 is false because CalibrationConflict-17 is unresolved. That result blocks entry for the planned Work; it neither resolves the conflict nor revokes MaintenanceCalibrationGrant-17.

E-CAL-07 (Source/display fact). SignedGrantRecord-17 and GreenPermitTile-17 are visible carriers in this case; their presence is an observed source/display claim only.

L-CAL-01 (Tempting wrong classification, rejected). “The visible permit is D, so the grant exists, the Work exercised it, and the Work was non-violating” is not one atomic claim and is false as a classification shortcut. The carrier observation is E-CAL-07; the grant, exercise, evaluation finding, and gate outcome remain the separately classified claims above.

#A compact “recomposition pattern” you can reuse verbatim

#Tech register (2–5 lines)

“This boundary claim is defined by L-… and applies only under A-…. D-… states either the exact generic prescription or the separately instituted duty of [actual bearer]. E-… states the evidence and observed status or value for Γ_time=….”

#Plain register (1 paragraph)

“We mean [short label] in the sense of L-…, and use it only when A-… holds. D-… either states what the named policy requires or, when an individual duty was separately instituted, names its actual bearer. E-… states how the condition is checked and the latest status or value. If responsibility is also claimed, cite its direct relation separately.”

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

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

• Arch bias: favors explicit separation and explicit references; mitigated by allowing narrative faces while keeping commitments classified and referenced by ID.
• Gov bias: makes actual duty bearers and duties explicit (D) and auditability explicit (E); mitigated by keeping evidence conceptual and carrier-referenced rather than tool-specific. Responsibility, when claimed, remains a separate direct relation.
• Ontological and Epistemic bias: insists on EntityOfConcern, Description episteme, and carrier and on work‑adjudicated effects; mitigated by providing clear cross‑quadrant link patterns so authors can still express real‑world governance needs.

#A.6.B:10 — Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#A.6.B:12 — Consequences

#A.6.B:13 — Rationale

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

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

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

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

Informative. Alignment notes; not normative requirements.

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

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

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

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

• Effect systems & handlers: clear separation between operation signature (L), handler and runtime behavior (A/E), and generic prescriptions or separately instituted duties (D); only the latter name an actual operating or implementing System as bearer.

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

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

#A.6.B:15 — Relations

• Used by A.6 and A.6.C: supplies the canonical matrix and cross-quadrant link discipline. Both consumers classify each exact atomic claim by predicate and adjudication, keep the claim episteme separate from its EntityOfConcern, and use the §8.4.1 branch only when permission wording is live.
• Constrains A.6.0 (U.Signature): enforces that L-* laws are truth‑conditional and do not include admissibility predicates.
• Constrains A.6.1 (U.Mechanism): enforces that admissibility lives in AdmissibilityConditions (A-*) and that evidence semantics are classified as E-* with carrier references.
• Requires A.7: binds quadrants to EntityOfConcern, Description episteme, or publication carrier so agency and evidence are not misattributed.
• Interacts with MVPK/E.17: faces are projections that cite L/A/D/E-classified claims and mint no new semantics. When the permission-word branch is selected, its row names the subject pattern and obtaining or failure test; A.6.B only classifies the statement, and neither wording nor a carrier makes the referenced object obtain.

#Probe-coupled boundary claim classification

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

Action classification:

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

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

Useful outputs:

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

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

#A.6.B:End

#A.6.C — Contract Unpacking for Boundaries

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.6 Signature Stack & Boundary Discipline Builds on: A.6 (stack + classification intent), A.6.B (L/A/D/E), A.6.P:4.11a (service/access subject-pattern recovery), A.7 (EntityOfConcern, Description episteme, and carrier separation), A.2.3 (U.PromiseContent), A.2.8 (U.Commitment), A.2.8.PER (strong/weak permission, exercise, and conflict), A.2.9 (U.SpeechAct), A.15.1 (U.Work), A.10 and B.3 (evidence and assurance use), E.10 (L-SERV and LEX-BUNDLE), E.17 (MVPK “no new semantics” faces), F.12 (service acceptance and evidence discipline) Naming boundary: F.18 may provide durable names for recovered terms when naming is current; it does not define or constrain the promise-content, speech-act, commitment, permission, work, evidence, or boundary ontology. Vocabulary boundary: Reuses “contract”, “SLA”, and “guarantee” only as Plain-level source cues. The four questions below are a boundary-language unpacking lens, not a Contract, bundle, register-part kind, or rival claim set. The existing A.6.B Claim Register may add bundleId, optional questionRef, directObjectDesignation, directObjectPatternLocator, and faceRefs; it remains the one atomic-claim record. Purpose (one line): Prevent “contract soup” by asking four plain questions, then recording each resulting atomic claim with its direct object, exact subject assertion, non-semantic pattern locator, quadrant, and evidence path when current.

#A.6.C:1 — Problem frame

Boundary descriptions frequently use “contract” as shorthand for “the thing that governs the interaction”. That shorthand collapses four practical questions and the separately governed objects needed to answer them:

• What was promised? — the exact promise content, if any,
• What was said, published, or instituted? — the speech-act Work, descriptions, publication occurrences/forms/carriers, and any separately governed institutional effect,
• What governance or permission-looking claim exists? — the one atomic norm, grant, gate, exercise, evaluation, conflict, or source claim selected by its job,
• What happened, what followed, and what supports reliance? — dated Work, each separate result or delivery claim, and each evidence claim.

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

Service-cluster note (modularity + lexicon). When contract talk co-moves with service, service provider, server, SLA, SLO, or service-level and a relied-on boundary use still hides a concrete subject or relation, recover that hidden choice through A.6.P:4.11a while asking the four questions below. Mere co-occurrence does not trigger recovery, and clear, quoted, historical, illustrative, or harmless ordinary wording remains usable. U.PromiseContent is written as promise content, never 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 across scales or contexts: keep the current grant or prohibition as its own D claim, classify the conflict finding as E through A.6 A6-AW-CONFLICT, and use the exact mediation predicate and assertion only when mediation is current;
• redefine the core meanings of U.PromiseContent, U.Work, U.SpeechAct, U.Commitment, or the exact A.2.8.PER results—it only makes “contract talk” classifiable into those objects or claims.
• redefine quadrant semantics (L/A/D/E) or cross‑quadrant reference rules; those are defined normatively in A.6.B.

#A.6.C:2 — Problem

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

1. Agency is not misattributed to descriptions (signatures, docs, specs, “interfaces”),
2. Governance claims are distinguishable from permission-looking gate, exercise, evaluation, conflict, and source claims by the job of each atomic statement rather than by A.2.8.PER membership,
3. Operational “guarantees” become adjudicable via explicit evidence expectations, without smuggling evidence into semantics,
4. Multi-view publication (MVPK faces) does not create a parallel contract object or rival canonical claim set by paraphrase drift?

#A.6.C:3 — Forces

#A.6.C:4 — Solution

A.6.C introduces a four-question boundary-language lens. It interprets and rewrites contract-like source wording under A.6.B without admitting a Contract object or another ontology branch.

#A.6.C:4.1 — Four questions for contract-like boundary wording

Whenever a text uses “contract”, “guarantee”, “promise”, “SLA”, or “interface agreement”, ask the four questions below. A question may yield zero, one, or several atomic Claim Register rows; the question itself is not a bundle part or direct-object kind.

1. What was promised?

   • The promised value or effect (the promise content) in the intended scope.
   • In FPF terms (A.2.3), U.PromiseContent is promise content—a promise content, not an execution event (U.Work) and not, by itself, an obtaining individual deontic relation (U.Commitment).
   • Prose head rule (normative). When referring to U.PromiseContent in normative prose, authors SHALL use the head phrase promise content (or service offering clause or service promise clause) and SHALL NOT rely on the bare head noun service. If the surrounding text also talks about endpoints, systems, and operations, apply A.6.P:4.11a only when the current relied-on use still hides which concrete subject or relation is meant; examples include a service access point, service delivery system, or service-delivery Work occurrence. Mere proximity to those words creates no additional claim or recovery duty.
   • Recommendation: give the promise-content a stable local ID (e.g., SVC-*) so it can be cited from commitments, gates, evidence, and MVPK faces without paraphrase drift.
   • Claim-classification discipline: keep meanings and definitions of the promised behavior in L. A generic prescription about that behavior is a separate D claim about its exact normative source and applicable rule content. If an actual System or separately governed party has that duty, state a separate D claim about the exact U.Commitment, plus any A-* and E-* references needed by that claim.

2. What was said, published, or instituted?

   • Speech-act row: if the boundary decision depends on who stated, published, or approved something, record that exact A.2.9 U.SpeechAct <: U.Work occurrence.
   • Description/publication rows: record the versioned utterance epistemes separately from their publication occurrences, forms, renderings, and carriers. None is the speech act.
   • A speech act may institute or update a commitment or strong grant only when the exact context policy recognizes that act type and the subject pattern's obtaining conditions are met.
   • The published utterance descriptions (signature or mechanism descriptions plus MVPK faces) carry L/A/D/E-classified claims. The act is not “the contract”; it is the Work occurrence that created or updated those descriptions and may have a separately governed institutional effect.
   • World-side obtaining rule (normative). The predicates defined in A.2.8 and the cited context policy decide whether a commitment obtains; the predicate defined in A.2.8.PER together with that policy decides whether a strong grant obtains. They use the actual instituting speech act, participants, scope/window, current policy, and any revocation or supersession conditions. A Claim Register row, utterance description, publication, carrier, or identifier creates or proves neither relation. Publication or approval may establish a publication/status relation only through that relation's exact predicate and obtaining facts.
   • Representation and reliance rule (normative). The model MAY assert or rely on a commitment or grant only through a separate atomic claim that identifies the exact U.Commitment or GrantedPermissionRelation@Context occurrence and cites its exact predicate, SubjectPatternLocator, instituting act and policy, participants, scope/window, and the currentness or evidence required by that use. Never infer the relation from Publish/Approve wording, a document, carrier, or completed-looking record alone.

3. What governance or permission-looking claim exists?

   • A generic prescription states what one exact policy or other normative episteme requires; it does not create an individual duty bearer or commitment occurrence. A claim that one actual System or separately governed party has that duty instead cites one separately obtaining A.2.8 U.Commitment. Here the normative episteme may be a contract, SLA, protocol, or policy, and the generic claim also states where its rule applies.
   • When the model asserts or relies on an individual obligation, recommendation-as-duty, or prohibition, write a separate atomic D claim whose direct object is that exact separately obtaining U.Commitment. The claim describes that relation for use; it neither institutes it nor proves that it obtains.
   • For permission-looking wording, select one A.6 A6-AW-* row. Only A6-AW-NORM-GRANT enters D; A6-AW-GATE enters A; exercise, weak evaluation, conflict, and observed-source claims enter E when their closing facts are present. Classification under A.2.8.PER alone selects no quadrant.
   • Individual-commitment checklist (use only for the individual branch):
     • identify one exact U.Commitment occurrence and the separate D-claim or CommitmentAssertion about it;
     • select exactly one actual bearer branch: an admitted U.System or separately governed party;
     • name non-empty exact duty referents, any actual counterparties, normalized modality, scope, and validity window;
     • cite the exact current constitutive policy, its individualizing rule, and the actual instituting basis required by that rule;
     • cite a system-role assignment only when that rule uses the assignment as an applicability ground—the assignment is neither bearer nor duty; and
     • add evidence-claim or carrier references only when the receiving reliance or adjudication needs them.
   • Permission-branch pointer: cite the selected A6-AW-* row, its exact A.2.8.PER object when applicable, and that atomic claim's quadrant. Preserve the object's own schema, participants, and references; do not reuse the commitment checklist.
   • A commitment is not “the spec text”: an utterance description carries the statement, while U.Commitment is the separately obtaining relation described by that statement (A.7 and A.2.8).

4. What happened, what followed, and what supports reliance?

   • Work: For one exact dated W : U.Work, recover each exact actual performer through A.13 and let A.15.1 independently admit the occurrence from that performer, enacted Method, extent, and containing System. Add an exact A.2.1 assignment reference and F.6 only when this account or a receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither the assignment nor the performer, and missing or failed F.6 leaves the Work intact. The Work can exist without a result, production, delivery, evidence-use, or acceptance claim.
   • Result or consequence: only when the sentence asks for one, select the matching A.15.1:4.6 row—an A.6.1 application/result binding or independently obtaining WorkResultRelation, A.15.PROD production branch, A.3.4 change, evaluation result, subject-specific delivery/transfer relation, or acceptance relation. An absent row stays absent.
   • Evidence: only when a receiving use relies on Work or one of those consequences, state an A.10 claim-bound evidence path and carrier. Evidence supports the named claim; it creates neither the Work nor its result.

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

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

• Promise content → L/A (promise semantics + eligibility).
  • Put meanings, invariants, and metric definitions for what is promised in L (L-* in signature laws and definitions).
  • Put “eligible, covered, or valid iff …” predicates as A (A-* admissibility or gate predicates), not as deontic obligations.
• Governance and permission-looking claims → claim-specific quadrant.
  • Put a generic contract, SLA, protocol, or policy prescription in D as a claim about its exact normative source and applicable rule content. Put an individual-duty claim in D only when it cites an exact separately obtaining U.Commitment under A.2.8; do not use a completed record as the relation.
  • For authority-looking wording, select one A.6 A6-AW-* row: norm/grant → D, gate → A, and actual exercise or evaluated finding/conflict/source → E. Cite the exact A.2.8.PER object only where that row requires it; the selected subject pattern or kind of direct object does not choose the sentence's quadrant.
  • If a generic prescription or individual duty requires satisfying or enforcing a gate, its D-* claim MUST reference the relevant A-* ID(s) (D→A).
  • If reliance on either D branch needs evidence, cite the relevant E-* claim or evidence-use relation (D→E); for the individual branch, a CommitmentAssertion may carry that reference. Evidence does not make U.Commitment obtain.
• Performed Work → E (did it happen?).
  • Name the exact A.15.1 Work occurrence and its performer, assignment, method, extent, and containing system. Do not add an output or delivery field.
• Result or consequence → E when current (what else happened?).
  • Use the one applicable A.15.1:4.6 predicate and exact subject assertion for the returned value, production, change, evaluation result, delivery/transfer, or acceptance claim; retain its pattern only as a locator.
• Evidence → E when relied on (how can the claim be used?).
  • Name the exact A.10 path, observation conditions, and carrier for the Work or consequence claim being supported. Carrier presence establishes none of those objects. Keyword placement rule (canonical claim set). Within the canonical L-, A-, D-, or E-classified claim set, BCP-14 keywords are statement operators, not ontology or quadrant selectors. MUST, MUST NOT, SHOULD, and SHOULD NOT enter D for a generic prescription or, when separately instituted for an actual bearer, an individual duty, recommendation-as-duty, or prohibition. MAY, OPTIONAL, and authority-looking synonyms trigger the A.6 A6-AW-* branch: a current norm or grant enters D, a mechanism entry predicate enters A, and an actual exercise or evaluated finding enters E. If the wording does not expose the branch and direct object, rewrite it or mark it informative.

A helpful rewrite rule:

First recover what “allowed” asserts by selecting one A.6 A6-AW-* row. Put only the current norm/grant in D, the entry predicate in A, and actual exercise or evaluated findings in E; cite each direct object and source. The word and A.2.8.PER membership select neither quadrant nor obtaining.

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

Treat “guarantee” as ambiguous until classified:

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

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

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

The atomic claims grouped for one boundary use live in one canonical A.6.B Claim Register set; the four-question lens creates no parallel claim set. Publication faces are views of that set under viewpoints:

• Faces may select, summarize, and render claims for audiences.
• Faces must not introduce a new commitment or any new object or claim selected through A6-AW-*; they project the existing classified claim.
• Any face-level decision-relevant or normative-looking statement SHOULD cite the underlying claim ID(s). If it cannot be traced to claim IDs, it MUST be explicitly presented as informative commentary.

Keyword rule (faces). If a face contains a BCP-14 keyword, each sentence MUST cite its existing classified claim ID and direct object. Duty/recommendation/prohibition and current-grant projections cite their D claim; a gate projection cites its A claim; exercise or evaluated-finding projections cite their E claim. Use the selected A.6 A6-AW-* row for permission-looking wording. A face-level keyword manufactures no object or quadrant; without a traceable claim, remove the keyword or mark the sentence informative. To avoid keyword‑evasion, equivalent deontic phrasings (e.g., “is required to…”, “is prohibited from…”) SHOULD follow the same trace-by-ID discipline even when no BCP‑14 keyword is present.

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

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

#A.6.C:4.5 — A.6.B Claim Register additions (recommended)

Use the A.6.B Claim Register (IDs, statements, quadrant, and canonical location). Add the following A.6.C fields without minting another record or ontology kind:

• bundleId (optional local ID grouping atomic claims discussed together)
• questionRef (optional pointer Q1, Q2, Q3, or Q4 to the four questions above; it selects no kind, subject predicate, or quadrant)
• directObjectDesignation (use U.RelationRef constrained to the exact relation family for a relation occurrence, the applicable U.EpistemeRef for a whole episteme, or the admitted reference kind for another independently identified entity. When one claim inside an episteme is the direct object, use C.2.1 ClaimAddress: exact episteme-edition reference plus intrinsic claim identity declared by that edition's ClaimGraph. The entity-reference branches designate independently identified objects; the claim branch designates content inside the named edition. Neither carries the designated content.)
• directObjectPatternLocator (the exact pattern-description locator for the ClaimGraph that defines or constrains that direct object; it asserts no ownership relation)
• faceRefs (optional mapping from PlainView, TechCard, InteropCard, or AssuranceLane to where this same claim is rendered)

Each row still uses the A.6.B fields for one exact statement, claim ID, quadrant, and canonical location. Do not create a second boundary-language record or a Permission, Utterance, WorkEvidence, or result-or-evidence umbrella kind.

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

#A.6.C:5.1 — Tell

If you use contract-language for a boundary, do not treat “the interface or specification” as an acting system. Instead:

1. What was promised? Record the exact promise-content claim if one exists.
2. What was said, published, or instituted? Give the speech-act Work, each description/publication object, and each institutional effect its own row and subject pattern.
3. What governance or permission-looking claim exists? Record either a generic D prescription with its exact normative source and applicability, an individual D claim about an exact obtaining commitment with its actual bearer and institution basis, or the selected A6-AW-* claim in its own quadrant. State responsibility separately under its admitted domain predicate or return its exact missing governor.
4. What happened, what followed, and what supports reliance? Record dated Work, each current result/change/delivery/acceptance claim, and each A.10 evidence claim separately; omit absent rows.

Write those answers in the one A.6.B Claim Register: one atomic statement, direct object, exact subject assertion, non-semantic pattern locator, and quadrant per row. Faces cite the claim IDs; they do not create another bundle record.

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

(A) Software API boundary

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

Unpack + classify:

• Description/publication: signature or mechanism publication for PaymentsAPI (MVPK faces: TechCard, InteropCard).
• L: define idempotency and the uniqueness semantics of Idempotency-Key. (“Idempotent” is a semantic property, not a duty.)
• A: admissibility predicate: request is admissible iff Idempotency-Key is present and valid. (Gate belongs to mechanism.)
• D: the API policy generically requires covered clients to satisfy the gate and states the provider-side idempotency and availability prescriptions. No individual commitment follows from those clauses alone. If the case claims that ClientIntegrator-A or ProviderSystem-A bears one of those duties, cite that bearer's exact separately instituted A.2.8 commitment. (Do not say “the API commits”. Responsibility, if claimed, needs its own direct relation.)
• E: evidence expectations: audit and log carriers include request id, idempotency key, rejection reason; availability measurement uses defined window and signal definition.

(B) Hardware interface boundary

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

Unpack + classify:

• Description/publication: published interface spec (pinout, electrical ranges, handshake procedure).
• L: electrical invariants and allowable ranges are definitions and invariants (truth-conditional).
• A: admissibility predicate: power delivery is admissible only after handshake state reaches an agreed mode.
• D: the interface specification's normative section contains generic prescriptions for covered manufacturers or integrators to implement the handshake and enforce voltage limits; it asserts no individual commitment occurrence.
• E: evidence: test-report carriers; measurement traces; observable negotiation logs (if exposed), or lab measurements under a declared method.

(B-PER) Compact permission replay (only when the permission branch is live)

Situation: “ReleaseAuthoritySystem, acting as release grantor under assignment ReleaseGrantor-A, approved DeploymentAgent-A, acting under assignment Operator-A, to deploy Release-4711 after preflight.”

Unpack + classify:

• Promise content (optional): SVC-RELEASE-4711 states which release artifact eligible consumers are promised; that content establishes no speech act, commitment, grant, deployment Work, result, or delivery.
• Speech-act Work: ReleaseGrantorAssignment is a declared U.SystemRoleAssignment species. Occurrence ReleaseGrantor-A has admitted System ReleaseAuthoritySystem as holder and the local release-grantor kind as assigned-kind value. That System performs dated Approve occurrence SA-4711 under the assignment. The assignment supplies only the holder and assigned-kind facts used by the policy; it neither performs the act nor supplies authority. Any authority required by ReleaseGrantPolicy must obtain independently. Under the applicable policy, SA-4711 institutes—not merely publishes—grant occurrence PER-4711 only if the A.2.8.PER obtaining conditions hold. Approval text and a register row that names PER-4711 do not establish that fact.
• D — current grant (A6-AW-NORM-GRANT): ReleaseOperatorAssignment is another declared species. Occurrence Operator-A has admitted System DeploymentAgent-A as holder and covers this window. The grant's beneficiary participant cites that occurrence, and its permitted-action participant is U.EpistemeRef(Deploy-Release-4711). This Claim Register row uses U.RelationRef(PER-4711), constrained to GrantedPermissionRelation@Context, as its directObjectDesignation. SA-4711, the two assignments, policy, context, scope, and window remain grounds or qualifiers. The model may use this D claim only while the A.2.8.PER conditions make PER-4711 obtain and the row cites the named occurrence, act, and policy; the row itself does not make the grant current.
• E — weak evaluation alternative (A6-AW-WEAK): if the basis establishes only current absence of prohibition in a sufficiently complete frame, record NonProhibitionFinding@Context; do not promote it to a strong grant or place it in D.
• A — independent entry predicate (A6-AW-GATE): “deployment is admissible iff PER-4711 currently obtains and preflight is green” is an A-* predicate. It may consume the grant as one condition but is neither the grant nor proof of gate passage.
• E — actual Work and exercise (A6-AW-EXERCISE): A.13 first recovers admitted System DeploymentAgent-A as the exact actual performer through obtaining assignment occurrence Operator-A of declared species ReleaseOperatorAssignment; A.15.1 independently admits dated U.Work occurrence DeployRun-4711. Because this permission-exercise branch expressly consumes precise assignment-bound attribution, F.6 then relates that already admitted Work through the same assignment and checks holder equality and coverage. The Work must instantiate the action specification inside the grant's scope and window. Only then may PermissionExerciseRelation@Context bind WorkRef(DeployRun-4711) to U.RelationRef(PER-4711), constrained to GrantedPermissionRelation@Context. The assignment contributes the beneficiary and attribution facts consumed here; it neither classifies the performer, grounds or creates performance, nor performs the Work. Failed F.6 leaves the Work intact but blocks this attribution-dependent exercise branch. Planned work, the approval wording, and preflight alone are not exercise.
• E — optional result or delivery: if DeployRun-4711 returns ReleaseArtifact-4711, cite the exact A.6.1 result binding or an already governed subject-specific WorkResultRelation; if that artifact is transferred, cite the independently obtaining delivery/transfer relation defined by its subject pattern. Work, result, and delivery do not imply one another.
• E — evidence (optional): an A.10 path may link the exact grant, Work, exercise, result, or delivery claim to its current carriers for one bounded reliance use. The carriers create none of those objects.

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

(C) Multiparty protocol boundary (behavioural and session-type motif)

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

Unpack + classify:

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

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

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

Unpack + classify:

• Promise content (service promise clause): responsiveness promise for a defined incident class and window.
• Description/publication: SLA publication (and its views for different audiences).
• A: admissibility predicate for the promise: ticket qualifies iff severity classification meets stated conditions.
• D: the SLA clause is first a generic prescription for covered providers, clients, and auditors. Claim that actual provider ProviderSystem-A bears the four-hour duty only after the SLA's individualizing rule and required actual basis establish one exact A.2.8 commitment; otherwise keep the clause generic.
• E: evidence: ticket carriers, timestamps, classification records, and the measurement procedure binding “4 hours” to a time window and clock source.

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

Lenses tested: Gov, Arch, Ontological and Epistemic, Prag, Did. Scope: Universal for “contract talk” in boundary descriptions.

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

#A.6.C:7 — Conformance Checklist

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

1. CC‑A.6.C‑1 (Four questions, atomic answers). If contract-language appears, the text SHALL answer the four questions only with atomic claims. Speech act, description/publication, generic prescription, individual commitment, selected permission-side claim, dated Work, each consequence, and each evidence claim SHALL retain its own direct object, exact subject assertion, non-semantic pattern locator, and quadrant.

2. CC‑A.6.C‑2 (No agency to epistemes). The text MUST NOT attribute promising, committing, or obligating agency to signatures, mechanisms, interfaces, documents, system-role kinds, or assignments. A generic prescription SHALL name its exact normative source and applicable content without inventing an individual bearer. An individual duty or commitment SHALL name its actual bearer and exact separately obtaining U.Commitment; an assignment may appear only as an instituting rule's applicability ground.

3. CC‑A.6.C‑3 (Classify contract-language statements via A.6.B). Contract-language statements SHALL be atomic L/A/D/E claims. Permission-looking wording SHALL select one A.6 A6-AW-* row; A.2.8.PER membership alone MUST NOT set the quadrant.

4. CC‑A.6.C‑4 (Promise content ≠ Work discipline). A performed-work statement SHALL name the exact A.15.1 dated Work occurrence. A result, production, change, delivery/transfer, evidence, or acceptance statement SHALL use its own direct object and shall not be inferred from Work. Promise-content language remains about U.PromiseContent, not execution or consequence. When service or access-like wording occurs in a relied-on boundary claim, recommendation, decision, gate, assurance, publication, or reuse and hides the concrete subject, participant, predicate, kind, permission, Work occurrence, or next subject question, the text SHALL recover that hidden choice through E.10 L-SERV and A.6.P:4.11a, then state the exact assertion under the recovered predicate with its pattern locator. Quoted, historical, illustrative, and harmless ordinary wording remains outside this recovery rule; an actual U.PromiseContent referent still uses the head phrase promise content, not bare service.

5. CC‑A.6.C‑5 (Evidence hook for operational guarantees). If a “guarantee” is operational (requires reality to decide), the text SHALL include an E claim that states what evidence would adjudicate it, with the evidence carrier or evidence claim named when current.

6. CC‑A.6.C‑6 (No second contracts via faces). MVPK faces MUST NOT add a new commitment or any new object or claim selected through A6-AW-*; they may only project the existing canonical L/A/D/E claim under a viewpoint.

7. CC‑A.6.C‑7 (RFC‑keyword discipline inside faces). If an MVPK face contains a BCP-14 keyword, each sentence MUST cite its classified claim ID, direct object, and selected A6-AW-* row when permission-looking. Only norm/grant claims cite D; gate claims cite A; exercise and evaluated findings cite E.

8. CC‑A.6.C‑8 (Obtaining is not representation). A Publish or Approve utterance, a document, carrier, or record does not by itself institute or prove a U.Commitment or GrantedPermissionRelation@Context. The exact obtaining predicate and cited context policy decide whether the relation obtains. A Claim Register row may assert or support reliance on it only when the row names the exact occurrence, predicate, SubjectPatternLocator, instituting act and policy, participants, scope/window, and current evidence required by that use; the row does not create the relation. When the grant occurrence is the row's direct object, directObjectDesignation SHALL be a U.RelationRef constrained to GrantedPermissionRelation@Context; an entity reference, ClaimAddress, display label, or arbitrary identifier cannot fill that branch.

#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.
• Generic prescriptions remain usable without invented occurrences, while individual commitments remain distinguishable and adjudicable through their actual bearer, rule, instituting basis, scope, validity, and any evidence needed for reliance.
• Boundaries remain evolvable: laws, gates, governance, and evidence can evolve with controlled coupling.

Trade-offs and mitigations

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

#A.6.C:10 — Rationale

FPF already distinguishes signatures, mechanisms, dated Work, separately identified results or consequences, and evidence use. Contract-language collapses them unless the author asks what happened, what separate result or delivery is claimed, and what evidence supports the exact reliance use.

F.18 may supply durable names for recovered terms, but it does not provide the ontology. A.6.C keeps promise content, speech act, commitment or grant, dated Work, application/result binding, production, change, delivery/transfer, evidence, and acceptance distinct and independently optional. This keeps contract language classifiable under A.6.B without turning A.15.1 into a semantic source of result or delivery.

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

Informative. Alignment notes; not normative requirements.

• Adopt — BCP 14 (RFC 2119 + RFC 8174) keyword discipline. The visible keyword does not select a quadrant: generic prescriptions, separately instituted individual duties, and current grants enter D; entry predicates enter A; actual exercise or evaluated findings enter E.
• Adopt — behavioural and session types for protocol boundaries (post‑2015 practice). Protocols as typed interactions emphasize separating safety and progress properties (L) from runtime admission (A) and from implementer obligations (D), with trace-based evidence (E).
• Adopt or adapt — algebraic effects and handlers plus effect systems. The operation-signature/handler distinction helps separate utterance substrate from dated Work, but application result, production, delivery, evidence, and acceptance still require their own direct relations; handler vocabulary does not bundle them into Work.
• Adapt — ISO/IEC/IEEE 42010:2022 viewpoint discipline. Multi-view publication is treated as viewpoint claims constraining view construction; A.6.C applies this to contract talk to avoid face-level semantic forks.

#A.6.C:12 — Relations

• Uses and is used by

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

• Coordinates with

  • A.7 (EntityOfConcern, Description episteme, and carrier) for correct placement of evidence claims.
  • A.15.1 for the exact dated Work occurrence and its §4.6 dispatch to application/result, production, change, evaluation, evidence, delivery/transfer, and acceptance patterns.
  • 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.2.8.PER for the exact permission-side direct objects; A.6 A6-AW-* and A.6.B classify each atomic claim without treating pattern selection as its quadrant.

#A.6.C:End

#Relation Obtaining and Individuated Relation Occurrences

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

#Problem frame

Plain name. Relation occurrence.

Primary EntityOfConcern. One obtaining relation occurrence of an admitted relation kind, opened only when later work must distinguish it from another occurrence of that same relation.

Primary working reader. An engineer who has stated a direct relation and must decide whether a readable current report is enough or later work must distinguish repeated occurrences.

Working concern and viewpoint. Preserve the readable direct relation assertion and ask first what later work must distinguish. Open occurrence identity only when that work must tell this occurrence from another; do not substitute an epistemic, designation, or representation-side object for the world-side relation.

Use this when. Use this pattern when later use must tell one obtaining relation occurrence from another occurrence of the same relation. With Robot-7 is assigned as inspector through InspectionAssignment-17, a report that only says who is currently assigned can keep that direct sentence and stop. A history or comparison that must tell a second MaintenanceInspectionAssignment episode from the first, even with the same Robot-7 and InspectorSystemRole, needs the occurrence-identity branch. A dependent direct relation may likewise require one already distinguished occurrence as its participant.

First useful move. Write the direct relation with its named participants, using the subject pattern's participant meanings and obtaining predicate only as far as needed to state that relation accurately. The subject pattern defines the test; it does not inspect the current case. Relevant world facts or constituting history from that case must satisfy the test, and a claim-bearing episteme may state the result without making it true. Then ask: Will later work need to tell this occurrence from another occurrence of the same relation, including another episode with the same participants? If no, keep the readable direct sentence and stop. If yes, recover and apply the subject pattern's same-versus-new-occurrence rule. Only after that rule distinguishes the occurrence should you name or reference it and map the exact receiving assertion, description, direct relation, or declared operation application.

What goes wrong if missed. An epistemic, designation, or representation-side object is treated as what creates the relation it is meant to describe or designate. Repeated assignments with the same participants then collapse into one. At the opposite extreme, every ordinary relational sentence is expanded into a relation-occurrence description episteme even though later work does not need to distinguish occurrences.

What this buys. Engineers can report a current relation in ordinary prose without opening unused apparatus. When history, comparison, evaluation, or another direct relation must distinguish repeated occurrences, a system can apply the domain identity rule while assertions, descriptions, designations, representations, and publication occurrences retain their own identities.

Not this pattern when. If the wording does not yet identify the direct relation and participants, start with A.6.P or A.6.RSIR. If no exact ClaimGraph yet defines the participant meanings, applicability, and obtaining predicate, recover that content rather than inventing a case test here. If the current case lacks relevant world facts or constituting history, keep its claim under C.2.1 and the exact direct predicate; a denial, forecast, scenario, counterfactual, permission, or other claim-side fact invents no obtaining occurrence. An explicit reliance judgment may record supported, refuted, or unresolved reliance under A.10 or the current evaluation, but neither evidence nor reliance makes the relation obtain. When current case facts satisfy the direct predicate, A.6.REL remains available only if later work must tell this occurrence from another occurrence of the same relation. If the question concerns only the SlotSpecs of a reusable relation declaration, apply A.6.5. If later work only reports the current relation, keep the direct sentence and stop.

#Problem

When a later engineering use needs one obtaining relation occurrence to remain distinguishable from another, descriptions often state five different claim contents as if one assertion or identifier established them all. The claims have this dependency order; the order does not turn them into five project-time decisions:

1. the direct relation obtains for the named participants, those participants jointly satisfy its semantic predicate, one occurrence therefore exists, and the direct identity rule governs its reidentification and distinction from another occurrence;
2. FPF ontology settlement already admits occurrences of that relation kind under U.Relation; the direct pattern states the relation-specific participant meanings, obtaining condition, and occurrence-identity rule, while a compatible RelationSignature episteme declares corresponding SlotSpecs for reusable descriptions;
3. a system performing explicit-individuation work applies the admitted identity rule so the named receiving use can recoverably distinguish one occurrence; a separate relation-occurrence description episteme is produced only when the selected receiver needs that description;
4. an identifier designates that already recoverable occurrence under a reference scheme;
5. the selected receiving object is either an episteme whose content designates that occurrence, another direct relation that has the occurrence as a participant, or an assertion episteme whose content states that one exact A.6.1 operation application binds the occurrence as its actual argument value under one named ArgumentDeclaration.

The later claim contents do not make the earlier relation obtain. Root U.Relation admission is a corpus ontology decision governed by E.24.UK. A.6.REL supplies the common occurrence discipline, while each direct relation pattern supplies the relation-specific participant meanings, obtaining condition, and occurrence-identity rule used as the admission witness. Project work does not repeat that classification decision. A system performing explicit-individuation work applies the direct identity rule so one existing occurrence is recoverably distinguishable for the current use; that work neither creates the occurrence nor by itself requires a separate description episteme. A system performing naming work may subsequently associate a designator with the occurrence, and a receiving episteme may subsequently contain a reference that designates it.

Relation-heavy work often begins from a table row, graph edge, identifier, or reified statement. An engineer can then mistake the represented row, edge, identifier, or reifier identity for world-side relation identity. Applying this method permits exact use of relation-occurrence identity without reversing representation and ontology and without forcing a relation-occurrence description episteme into every readable sentence.

#Forces

#Solution

Use progressive relation-occurrence individuation. Start from a readable obtaining direct relation, ask whether later work must distinguish a repeated occurrence, and stop before technical receiving branches when the answer is no.

Local relation-occurrence mantra. State the direct relation, using its governing predicate enough to say it accurately. Ask whether later work must tell this occurrence from another occurrence of the same relation, including another episode with the same participants. If no, keep the readable sentence and stop. If yes, recover and apply the direct same-versus-new-occurrence rule. Only then name or reference the occurrence and map the exact receiving assertion, description, direct relation, or declared operation application.

This short formula keeps the progressive-individuation Solution in attention; it does not replace sections 4.1-4.7. It is a mnemonic, not a work plan or performed work. When a receiving use instead needs one reusable constraint-governed unfolding structure for those continuations and stops, A.22.CGUS governs that structure.

#Apply the relation-object architecture discipline

Relation-object architecture discipline is the rule set in this subsection. It is not another U-kind. Conforming prose keeps the objects around one direct relation distinct, names the direct relation between adjacent objects, and uses a recoverable name for each current object. A.6.5 specializes only the SlotSpec part of this rule set.

Short use rule. State the world-side relation and its actual participants first. Add another named object from the relation-object architecture only when the current receiving use depends on that exact object, and state its direct relation to the object already in view. The tables below help select that additional object and relation; they are not a mandatory form for ordinary relation prose.

The world-side relation comes first. An actual relation participant is one exact U.Entity participating in one obtaining relation occurrence under one relation-participant meaning. Participation leaves the entity under its independently governed intrinsic kind. A relation occurrence is the obtaining U.Relation occurrence itself. The direct relation obtains when the actual participants satisfy the obtaining predicate; the occurrence-identity rule provides the criteria for reidentification, continuity, and distinction from another occurrence. Signatures, assertions, names, references, and representations retain their separate identities.

#World-side objects

The phrase actual relation participant therefore never replaces the entity's own name. It says how that entity participates in this occurrence. Likewise, the readable sentence Robot-7 is assigned as inspector through InspectionAssignment-17 can state the direct assignment without first creating a relation-occurrence description episteme.

#Relation-kind settlement

The relation kind is a classificatory distinction over relation occurrences. Every admitted direct or derived relation kind has one direct subject settlement that states relation-participant meanings, an obtaining predicate, applicability, and an occurrence-identity rule as semantic and rule content. A derived kind additionally names its base-definition and substrate dependencies. Ordinary use may omit explicit individuation when no receiver needs it; that omission does not mean the identity rule is absent. World-side entities participate according to the settlement while retaining their own kinds.

Public name settlement. The following F.18 NameCard names the already governed root occurrence kind. It neither admits a new kind nor makes a relation obtain.

NameCard:
  NameCardId: NC-U-RELATION
  GovernedValueRef: U.Relation under A.6.REL
  SubjectPatternLocator: A.6.REL
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseRef: individuable obtaining relation occurrence whose direct pattern supplies participants, obtaining conditions, and identity
  TechLabel: U.Relation
  PlainLabel: relation occurrence
  CandidateSet: U.Relation; U.RelationOccurrence; U.ObtainingRelation; U.IndividuatedRelation
  RejectedCandidates: longer candidates expose occurrence or obtaining but lose the established root retrieval head; U.Relation remains safe only with the A.6.REL identity discipline
  SelectionRationale: preserve the root name while distinguishing existence, kind admission, explicit individuation, identifier assignment, and reference use
  PublicRowStatus: pending
  LineageEntries: existing local U.Relation declarations narrowed to individuable obtaining occurrences
  RefreshCondition: reopen if direct relation patterns cannot supply stable occurrence identity for an admitted relation kind

Use U.Relation for the admitted root kind only. A direct relation kind keeps its own governed name, participant meanings, obtaining predicate, and occurrence-identity rule.

In the world-side relation, the actual entities participate directly under the relation-participant meanings. When assertions and descriptions need typed reuse, a reusable declaration episteme declares those meanings without becoming the world-side relation.

#Reusable declaration episteme

SlotKind, ValueKind, and refMode answer different questions. SlotKind identifies the declaration component locally. ValueKind is the independently governed kind of the actual relation participant. refMode states how a receiving episteme designates that participant. Together they specify one declaration component; world-side entities and occurrences keep their independently governed identities.

#Claim and description epistemes

A receiving episteme contains a relation-participant designation in a content position corresponding to one declared SlotSpec. A concrete representation may carry that designation in a field, but the field keeps its source name and corresponds to the declaration-local SlotKind only through an explicit declaration or C.29 correspondence. Reusing the SlotKind spelling for convenience does not identify the field, SlotKind, designation, or participant. The designation denotes the actual participant; the participant remains a U.Entity, the obtaining occurrence remains a U.Relation, and the receiving episteme keeps its own C.2.1 identity.

#Naming, reference, and representation

A source-specific term remains the name of its source-side object until an explicit correspondence is stated. That correspondence never identifies a source representation element with the represented FPF object. Representation preservation stays with C.29 and the selected representation-transition pattern, structural equivalence goes to C.34, and cross-context sameness goes to A.6.9.

#Use the subject pattern for the current object

Only systems perform authoring, evaluation, individuation, naming, reference-resolution, and representation work. Relation occurrences obtain; epistemes contain declarations, assertions, and descriptions; names and references stand in governed designation relations. This grammar keeps agency with systems without suppressing the semantic relations that make the relation-object architecture useful.

#Name only the minimum current object

The relation-object architecture organizes the distinct objects that may become current; it is not a publication form repeated for every relation sentence. Stable relation-kind semantics belong once in the direct relation pattern or ontic. A reusable declaration belongs once in its RelationSignature. A durable name belongs once in its F.18 naming settlement. Later prose names the object current for its use and cites the subject pattern for already established neighboring objects.

In recognition text, prefer the readable direct relation sentence. Put the reusable declaration, occurrence-identity rule, naming settlement, or representation correspondence in nearby Tech or assurance text governed by its direct pattern, and refer to it when another declared use depends on it. Precision comes from recoverable subject patterns and explicit relations between adjacent objects, not from repeating the complete architecture.

This rule keeps elaboration additive. Each new receiving use introduces only the object on which that use depends and the object's direct relation to an already recoverable object. When the use stops at the world-side relation, the prose adds no signature, occurrence-description, naming, or representation apparatus.

#Apply the receiving-use test

Here receiving use is a Plain head, not a common FPF kind. Do not decode it into the architecture before the cheap decision. First state the readable relation and ask what later work must distinguish. Only after that work needs occurrence identity, resolve it to the exact receiving object: an assertion or description episteme under C.2.1, a direct relation that has the occurrence as a world-side participant, or an assertion episteme that states one exact A.6.1 application binds the occurrence as its actual argument value under a named ArgumentDeclaration. Any acting system, enacted method, and performed work remain separately governed.

1. Name the direct relation kind and participants in a readable sentence. Use only the direct relation-participant meanings, obtaining predicate, and applicability needed to state that sentence accurately; do not yet require a RelationSignature, SlotSpecs, occurrence designator, representation correspondence, or the complete occurrence-identity rule.
2. Immediately ask: Will later work need to tell this occurrence from another occurrence of the same relation, including another episode with the same participants?
3. Apply the observable contrast. A current report that only says Robot-7 is assigned as inspector through InspectionAssignment-17 answers no. A history or comparison that must distinguish a second occurrence of the same direct species from the first, despite the same participant values, answers yes.
4. If no, keep the readable direct sentence and stop this pattern. Do not create a relation-occurrence description episteme for completeness.
5. If yes, recover the participant meanings, applicability, and obtaining predicate from the subject pattern. Inspect the relevant world facts or constituting history in the current case and judge whether they satisfy that test. Only when the case facts satisfy the predicate is there an obtaining occurrence to individuate; otherwise use the exact direct claim predicate and keep its subject pattern only as a locator or A.6.P. A claim-bearing episteme may state an affirmative or negative result, but its polarity, a forecast, scenario, counterfactual, permission, another separately governed claim, evidence, and supported, refuted, or unresolved reliance neither establish nor constitute that occurrence.
6. Recover and apply the subject pattern's same-versus-new-occurrence rule. Explicitly individuate one occurrence; assign an identifier only when stable reference is needed.
7. Only now name the exact receiving object and subject pattern. Designate the occurrence in a receiving assertion or description episteme; for a receiving direct relation, verify its obtaining with that occurrence as a participant; or, for an already identified operation application, verify the named A.6.1 ArgumentDeclaration, designation rule, ValueKind, cardinality, and binding predicate before an assertion episteme states that the occurrence is its actual bound argument value.

Occurrence existence depends on the direct relation obtaining. Reidentification and distinction from another occurrence depend on the direct identity rule. Explicit individuation depends on a named receiving use. Identifier assignment and reference use depend on an already recoverable occurrence. None of the later moves makes the earlier relation obtain.

#Select an identity rule that survives repetition

Use participant-determined identity only when the direct ontology establishes that two distinct occurrences of this relation kind cannot have the same participant identities. The RelationSignature SlotSpecs declare how assertion or description episteme content designates those participants; neither the SlotKinds nor any database-row or representation key contributes to world-side identity.

When the same participants can enter more than one occurrence, the direct pattern declares the discriminator that exists in that domain:

When a relation occurrence is a constructed result under its direct construction rule, recover each exact constructing U.System through A.13 and let A.15.1 independently admit the performed construction Work. Add F.6 only when the occurrence-identity explanation or a later receiving claim expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 establishes that Work-assignment link and identifies neither the assignment nor the performer. A short explanation may omit an unused assignment identifier, and missing or failed F.6 leaves the construction Work intact. Also recover the enacted constructor Method, input entities, and the identity contribution of that Work occurrence. An installed-part relation is only a hypothetical candidate here: installation Work may distinguish its occurrences only after an accepted pattern for that relation declares the participant meanings, obtaining predicate, applicability, and constitutive identity contribution. Until then, do not infer an installed-part occurrence from the Work, row, drawing, assertion, designation, or representation.

A changed episteme contributes to occurrence identity only when that episteme itself is a constitutive participant under the direct identity rule. A changed publication occurrence contributes only when that publication occurrence is itself a constitutive participant under the same rule. A system merely learning about the relation, describing it, or publishing an episteme about it changes no world-side occurrence.

#Separate occurrence, assertion, reifier, relator, description, and publication

A relational assertion is an episteme whose content affirms or denies the direct obtaining predicate for the designated participants. Forecast, scenario, counterfactual, permission, and other claim families keep their exact direct governors rather than entering one common catch-all field; A.10 or the receiving evaluation separately states supported, refuted, or unresolved reliance. The assertion and its reliance posture can be revised or superseded while the world-side relation remains unchanged.

A reifier is a representation-side term or node. A system may use it to represent statements about a proposition, assertion episteme, or relation-occurrence description episteme. Its presence does not make the direct relation obtain and is not a world-side occurrence-identity rule.

A direct material-relation ontology may identify a relator: a dependent material truth-maker through which its participants stand in the relation. Introduce one only when that ontology identifies the relator, its dependence relations to the participants, and its occurrence-identity rule. Do not generalize that relator to relation kinds whose direct ontology does not provide those three settlements.

An episteme can describe a relation occurrence. A second episteme can describe the first episteme. Under a publication-relation occurrence, a selected episteme edition is available to the declared audience and use. If an information carrier is current, E.17 governs its publication-kit use and E.24.PUB governs publication; carrier identity replaces neither episteme identity nor relation-occurrence identity. None of these objects replaces the direct occurrence-identity rule.

#Use one relation occurrence as a participant of another

Before one relation occurrence participates in another relation, explicitly individuate the first occurrence under its direct identity rule. The receiving direct pattern states a participant meaning whose ValueKind admits U.Relation or the exact relation kind; its RelationSignature episteme declares the corresponding SlotSpec. In the world-side receiving occurrence, the first occurrence itself is the participant. A participant designation in the receiving assertion or description episteme denotes it by value or through the RefKind declared by that SlotSpec.

This is ordinary typed participation, not a relation-of-relations exception. The first occurrence keeps its kind, participants, obtaining condition, and identity. The receiving relation keeps its participant meanings, obtaining condition, and identity rule; the receiving RelationSignature keeps its SlotSpecs. The reference used by an assertion belongs to neither world-side occurrence.

#Keep ordinary relation use lightweight

Ordinary users write one readable direct relation sentence with named participants and immediately ask whether later analysis or reporting must distinguish this occurrence from another occurrence of the same relation. A report that only states the current Robot-7 assignment to InspectorSystemRole through InspectionAssignment-17 stops there. A history or comparison that must distinguish a later occurrence of the same species opens its direct occurrence-identity rule. Only after that rule distinguishes the occurrence does the user add the exact receiving assertion, description, direct-relation participant, operation argument, identifier, or reference branch. The direct relation pattern states the shared participant meanings, obtaining predicate, applicability, and identity rule once; later uses cite only what their branch consumes.

This is demand-driven progressive elaboration within the Solution, not a drafting sequence. The alternatives below share one readable direct relation. Indentation marks only a real dependency: the receiving occurrence branch follows a positive distinguishability decision and the direct identity rule, while the RelationSignature branch remains independent and opens only for typed reuse.

readable direct relation sentence with named participants
  +-- later work only reports the current relation -> stop
  +-- later work must distinguish another occurrence, even with the same participants
      +-- check direct obtaining and apply the direct same-versus-new-occurrence rule
      +-- then add only the receiving branch that consumes the distinguished occurrence
          +-- description or assertion designation
          +-- identifier or stable reference
          +-- occurrence as another direct relation's participant
          +-- occurrence as a declared operation argument
  +-- RelationSignature and SlotSpecs independently, only when typed reuse matters

This is a C.29 representation of the stop decision and optional increases in explicitness. Its branch marks are representation elements, not direct relations or work occurrences. The indentation below the same-versus-new-occurrence rule records only that description, identifier assignment, occurrence participation, and later designation require one recoverable occurrence; it does not make a RelationSignature prerequisite for occurrence identity. The represented branches are neither a documentation plan nor a method for constructing the world-side relation.

#Keep world-side change separate from episteme editions

Whenever current wording or work says that a relation occurrence, claim, reusable declaration, name, reference, description, or publication "changed," first name which exact object changed and apply that object's own continuity, identity, revision, or edition rule. This selection does not require an A.10 evidence relation:

A relation occurrence has identity under its direct rule; a temporally extended occurrence also has temporal history under that rule. Revision work may change an episteme or establish another edition, but it changes no world-side occurrence. Current case facts or constituting history must separately satisfy the direct continuation, cessation, or same-versus-new-occurrence rule. Another edition of an assertion, signature, or description episteme, or another publication occurrence, therefore entails no new relation occurrence.

Use A.10 only when current receiving work separately asks whether to rely on a claim in light of evidence. That reliance judgment neither triggers changed-object selection nor supplies or causes the world-side change.

#Archetypal Grounding

#Repeated occurrence of one direct system-role-assignment species

Start with Robot-7 is assigned as inspector through InspectionAssignment-17 and trace only the objects needed by the current use.

1. World-side participants and occurrence. Robot-7 remains an admitted U.System; InspectorSystemRole remains one exact local C.3 kind. InspectionAssignment-17 is an occurrence of directly declared MaintenanceInspectionAssignment <: U.SystemRoleAssignment, with Robot-7 filling HolderSystemSlot and InspectorSystemRole filling its declaration-local assigned-kind slot. This simple species has no generic taxonomy, reference-scheme, context, or interval participant.
2. Direct settlement. A.2.1 supplies the species' participant meanings, direct predicate, applicability, and same-versus-new-occurrence rule. The occurrence continues while that predicate obtains without interruption for the same complete participant set. A demonstrated predicate-false gap ends it; later resumption starts another occurrence. An evidence gap by itself does neither.
3. Reusable declaration. For typed reuse, the MaintenanceInspectionAssignment RelationSignature contains HolderSystemSlot : U.System / U.EntityRef and one declaration-local assigned-kind SlotSpec whose ValueKind is the exact InspectorSystemRole domain. A stronger direct species adds only its real identity-bearing participants. assignmentInterval remains assertion or occurrence-description content, not another participant SlotSpec.
4. Assertion and participant designations. An InspectionAssignmentAssertion carries designations corresponding to the species' declared SlotSpecs and states the currently known assignmentInterval separately. Its claim may say that Robot-7 is currently assigned as inspector through InspectionAssignment-17. If later use only needs that current report, keep the assertion and stop without adding another occurrence object.
5. Occurrence identity, designator, and reference. Suppose two episodes of the same direct species have the same complete participant values but occur in inspection shifts separated by a demonstrated predicate-false period. A history or Work-attribution claim applies the A.2.1 continuity rule, distinguishes the second occurrence, and may designate it. A roster-row identifier, copied field set, taxonomy edition, reference scheme, or reused source key cannot collapse or split the two episodes.
6. Representation. A roster row or diagram edge may represent the assignment assertion or an occurrence-description episteme under C.29. Its source fields and key keep their representation-side meanings. An explicit declaration or C.29 correspondence relates a source field to the exact SlotKind and the carried value or reference to the participant designation; using the same spelling for field and SlotKind is optional and establishes no identity. Representation identity does not replace the A.2.1 occurrence rule.

The practical payoff is visible at each stop. A current staffing report keeps the readable direct sentence. Typed reuse opens the existing declaration. A history or work-attribution claim opens occurrence identity only when it must distinguish the repeated episode. Stable cross-reference use may then motivate naming and reference work.

#Hypothetical installed-part boundary

Bearing_B isPartOf Pump_P may be a readable source claim, but current A.14 does not supply an InstalledPart relation kind, installed-part participant meanings, an installed-part obtaining predicate, or its same-versus-new-occurrence rule. Names such as InstalledPartRelationSignature, InstalledPartSlot, and AssemblyWholeSlot are therefore hypothetical candidates, not current declarations. Do not use them to claim conformance or an individuated installed-part occurrence.

A future accepted subject pattern could make installation work or a continuous installation interval identity-bearing, but A.6.REL does not choose that ontology. Until such a subject pattern exists, keep the physical entities, installation work, proposed part relation, assertion, occurrence description, designator, reference, and database or drawing representation separate, and stop before an occurrence-identity result.

#Formal reduced case

The expression 3 < 5 is assertion content written in a mathematical notation. Under the referenced arithmetic structure, the values three and five satisfy the less-than predicate. The expression is not thereby a relation occurrence. No receiving use in this case needs the obtaining less-than relation occurrence explicitly individuated under U.Relation, so the engineer stops at the assertion. A graph edge or RDF reifier introduced by tooling remains a representation of the proposition or assertion and is not an occurrence-identity rule in the formal subject domain.

#Relation occurrence as a participant

C.22.PFR has one actual-condition relation occurrence and one problem-criterion-applicability relation occurrence as world-side participants. Each is individuated under its own direct identity rule. The PFR direct pattern states those two participant meanings, its obtaining condition, and its identity rule; the PFR RelationSignature episteme declares the corresponding SlotSpecs. A PFR assertion designates the two occurrences according to those SlotSpecs. PFR is a direct relation, not an episteme whose content merely groups two assertions.

#Description and publication recursion through the relation-object architecture

Let R1 be the already individuated second MaintenanceInspectionAssignment occurrence from 5.1.

1. An assignment-occurrence description episteme E1 has R1 as its exact EntityOfConcern. In the reusable C.2.1 EpistemeConstitutionRelationSignature, the declaration-local SlotKind EntityOfConcernSlot names the entity-of-concern participant meaning. In a card representation of E1, the source field entityOfConcernRef corresponds to that SlotKind only through a declared C.29 correspondence; its U.EntityRef value is the participant designation that resolves to R1. Neither spelling nor containment identifies the field, SlotKind, designation, or occurrence.
2. A second episteme E2 contains the result of evaluation work concerning the adequacy of E1. Its exact EntityOfConcern is E1, not R1. A field in a reusable card or other C.29 representation may carry a U.EntityRef designating E1; it corresponds to EntityOfConcernSlot only through a declared representation correspondence. The two epistemes therefore have different EntitiesOfConcern and retain separate C.2.1 identities: E1 describes R1, while E2 evaluates the adequacy of E1.
3. Under a publication-relation occurrence, the current edition of E1 is available to a declared audience and use. The selected episteme edition is an actual participant of that publication relation under the publication pattern's participant meaning. The publication form and its representation elements retain their own kinds and correspond to the published episteme only through the declared publication and representation relations.

A system performing revision work can establish another edition of E1 or E2; a system performing publication work can establish another publication-relation occurrence for a selected edition. R1 continues or ceases only as the A.2.1 obtaining predicate and occurrence-identity rule determine from the assignment facts. This recursive case preserves the distinction: a description episteme can itself become the actual participant or EntityOfConcern of another relation without becoming the relation occurrence it describes.

#Bias-Annotation

This pattern has an individuation bias because it serves receiving uses that need relation identity. The lightweight stop rule prevents that bias from turning every direct relation into an explicit relation-occurrence description episteme.

The admitted system-role-assignment case can over-emphasize participant identities and temporal continuity. Another direct relation may instead use constituting Work or another world-side discriminator, but only when its own accepted pattern states that contribution. The hypothetical installed-part boundary demonstrates why A.6.REL must not invent that rule.

Engineers can easily picture relation instances through data-model examples. The prescribed move therefore begins with direct relation obtaining, predicate satisfaction, and the direct identity rule. A system introduces database rows, graph edges, reifiers, tuples, and data-model objects only afterwards as representations for a declared use.

#Conformance Checklist

1. Across the subject pattern and the current use, the relation kind, relation-participant meanings, relation obtaining predicate, actual relation participants, applicability, relation occurrence-identity rule, and any currently needed RelationSignature SlotSpecs are recoverable. An ordinary relation sentence remains complete without repeating that settlement.
2. The text does not conflate relation obtaining, predicate satisfaction, root-kind admission, explicit-individuation work, identifier assignment, and reference use.
3. Root U.Relation admission is governed by E.24.UK from the common A.6.REL discipline and the relation-specific witness supplied by each direct relation pattern; project use does not repeat the admission decision.
4. Immediately after the readable direct relation, the current work answers whether it must tell this occurrence from another occurrence of the same relation. A current-status report is the explicit no branch; a history or comparison that distinguishes repeated episodes with the same participants is the explicit yes branch.
5. The subject pattern defines the obtaining test; relevant current-case facts or constituting history supply its factual basis; a claim-bearing episteme states polarity. An affirmative assertion, evidence, or a supported, refuted, or unresolved reliance result neither establishes nor constitutes the world-side occurrence.
6. Every admitted direct or derived relation kind has a direct governing settlement that declares its occurrence-identity rule; ordinary omission of explicit individuation or an occurrence designator does not count as absence of that rule.
7. Participant-determined identity is used only when the direct ontology establishes that the same participant identities cannot recur in distinct occurrences of that relation kind.
8. When the same participants can recur, the direct pattern declares the domain discriminator; maximal continuous obtaining interval and constituting work are possible choices only when that pattern includes them in the occurrence-identity rule.
9. When construction is constitutive, the constructing system, input entities, performed construction work, and identity contribution are named; representation creation is not substituted for construction.
10. Each object in the relation-object architecture is reidentified under its subject pattern and connected to adjacent objects only by the direct relations stated in section 4.1.
11. A relation occurrence used as another relation's world-side participant is individuated first; the receiving assertion's reference remains distinct from that participant.
12. Ordinary use stops at the readable direct relation when later work only reports the current relation. When later work must distinguish repetition, the direct same-versus-new-occurrence rule is applied without first creating a RelationSignature; only then is the occurrence named, referenced, or mapped into its exact receiving branch.
13. Another episteme edition, publication occurrence, name association, or reference use is not evidence of another world-side relation occurrence; apply the direct occurrence-identity rule independently.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. One common discipline travels without flattening unlike objects: A.6.REL supplies no universal truth-maker, occurrence-identity discriminator, or representation form; for each direct relation, use the truth and occurrence-identity conditions in its defining pattern, and for the selected representation, use the form in its representation pattern. In a direct species under U.SystemRoleAssignment, A.2.1 uses uninterrupted predicate obtaining and a demonstrated false gap to distinguish repeated episodes for history or Work attribution. In the formal reduced case, 3 < 5 remains assertion content and needs no explicitly individuated relation occurrence. In C.22.PFR, the actual-condition and criterion-applicability relation occurrences are already individuated under their own direct rules before PFR uses them as participants. Each assertion remains a claim-bearing episteme; none is placed in a list of world-side relation kinds.

Costs. A direct relation pattern needs a stated occurrence-identity rule, not only participants, when a receiving assertion, description, direct relation, or declared operation application depends on distinguishing one occurrence from another. A system performing relation-identification work establishes whether participants, temporal extent, constituting work, or another domain discriminator distinguishes repetition. Data schemas that used row identity as ontology may need to expose the domain identity they hid.

Limits. A.6.REL does not decide whether a particular direct relation obtains, define every relation kind, or prescribe a storage model. It does not supply evidence, comparison, publication, forecast, scenario, counterfactual, permission, or temporal semantics governed by neighboring patterns. It also does not turn assertion polarity, a separately governed claim family, or a reliance posture into an obtaining occurrence.

#Rationale

Applying this method lets an engineer use exact occurrence identity without equating ontology with documentation. A direct relation can obtain for its participants before an FPF episteme states a sentence about it. The actual relation participants, considered under their participant meanings, satisfy the semantic predicate within the direct relation pattern's declared applicability and temporal conditions; an assertion is an episteme whose content affirms or denies that predicate under its exact direct claim family; A.10 or the receiving evaluation separately governs supported, refuted, or unresolved reliance; explicit-individuation work is performed by a system for a named receiving use; and an identifier only enables later reference. Keeping those objects and moves distinct prevents semio-bias in which an episteme is mistaken for the world-side relation.

The identity rule belongs to the direct relation pattern because the direct ontology determines whether participant identities suffice. The same complete participant set can stand in two occurrences of one A.2.1 direct species when a demonstrated predicate-false gap separates them. The same component and whole may belong to distinct part-relation episodes only if their accepted subject pattern declares the relevant discriminator; A.6.REL supplies none. Conversely, an ordinary formal order assertion may need no explicit occurrence object in project work. A universal key would be too weak for repetition and too heavy for ordinary use.

Assertion, description, and signature epistemes can have editions; a system performing publication work can establish another publication-relation occurrence for a selected edition. A relation occurrence instead begins, continues, or ceases under its direct rule; when a system applying that rule distinguishes another occurrence, the other occurrence has its own identity. Keeping episteme edition change, publication occurrence, and relation occurrence continuity separate makes repair local and prevents publication history from masquerading as world history.

#SoTA-Echoing

#Ontological SoTA and constructional sources

This pattern uses these sources to constrain its account of occurrence existence and identity. They provide ontological comparisons, not notation selection.

#Representation and implementation stress tests

This pattern uses these sources to test whether the selected ontological distinctions can be represented and used. They do not determine what relation occurrences exist or how they are identified.

This pattern uses the ontological sources to constrain its occurrence-existence and occurrence-identity method. It uses the representation sources to test implementability only after those choices are made. The worked cases expose both boundaries outside information-system projects.

#Relations

• A.6.0 declares RelationSignature participant SlotSpecs and restates the direct predicate, applicability, and exact identity rule for reuse without making the relation obtain.
• A.6.5 separates world-side participants from RelationSignature SlotKinds and from participant designations in assertions or descriptions.
• A.6.P governs restoration of hidden direct relations and participants before occurrence identity is attempted.
• A.6.RCD governs the residual case in which exact participants are known but no current direct relation closes the named receiving claim; any admitted derived or primitive relation kind must include its own direct subject settlement and identity rule.
• A.6.RSIR governs selection among a direct relation, relation-participant meaning, declaration SlotSpec, RelationSignature, and another exact interface object when wording is ambiguous.
• Use A.2.1 to state direct U.SystemRoleAssignment species, predicate obtaining, and occurrence identity, and F.6 for later attribution to performed Work.
• A.14 and exact direct mereology patterns define or constrain only the part-relation kinds and part-whole changes they actually declare; A.6.REL adds no installed-part settlement.
• A.15.1 governs work occurrence identity and readable links to separately governed participation, change, operation-result, production, evaluation, delivery, and acceptance claims.
• C.2.1 governs assertions and descriptions about relation obtaining, predicate satisfaction, and occurrences; E.17 and E.24.PUB govern publication relations.
• C.22.PFR supplies a worked case with two explicitly individuated relation occurrences participating in one dependent evaluative relation.
• C.29 governs a declared mathematical or data-model lens, including graph, tuple, or database representations used to describe relation structure.
• E.24 governs ontic settlement and E.24.UK governs root U.Relation admission. A.6.REL supplies the common occurrence discipline, and each direct relation pattern supplies the relation-specific witness. E.24.CD supplies the candidate-detection rule only after the prerequisite subject results are recoverable; it does not replace the direct occurrence-identity rule.
• F.18 governs durable names and identifier use after the relation kind and occurrence identity are settled.

#A.6.REL:End

#U.Signature - Reusable Law-Governed Declaration Episteme

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

Pattern kind. Ontic declaration pattern.

Builds on. A.7 for strict distinction, C.2.1 for episteme identity, C.3 for kinds, A.2.6 for claim scope, and A.6.5 for relation-slot discipline.

Coordinates with. A.6.REL for relation occurrences, A.6.1 for mechanisms, C.29 for mathematical-lens use, E.24.UK for durable U-kind admission, and E.24.PUB for publication.

#Problem frame

An engineer has a vocabulary and a set of laws that need to remain stable across several dependent epistemes, such as model epistemes, method descriptions, and patterns. For example, a physical-modeling team needs one stable declaration of connector variables and conservation laws; a clinical team may need one stable definition of a dose-response predicate and its applicability without assuming that a dose-response relation kind has been admitted; and a formal-methods team needs one stable declaration of terms, inference forms, and invariants.

Use this pattern only when the thing being written or reused is itself a reusable declaration. A description, rule, policy, work plan, or specification does not qualify merely because it contains terms or constraints that recur elsewhere.

Before opening declaration fields, ask:

What subject does this declaration cover? What values or results does it speak about? Which terms and laws may another use rely on? Where do those laws apply?

In FPF terms, the declaration is about one exact independently governed EntityOfConcern; SubjectKind and RangedValueKind name its declared subject and value range; ResultKind is added when a distinct result kind is current; and Vocabulary, Laws, and Applicability answer the remaining three questions. U.Signature is the episteme that carries this declaration. A relation kind opens the RelationSignature specialization; a mechanism family or formal calculus opens the corresponding A.6.1 or FormalSubstrate declaration; a method kind remains governed by A.3.1.

Primary working reader and concern. The reader is an engineer who authors or reuses a declaration and needs stable meaning, applicability, and typed reuse without authoring declaration or occurrence-identity apparatus beyond what the current use needs.

For the lightest useful declaration, name that subject through SubjectKind and RangedValueKind, add ResultKind when the result has another kind, and state Vocabulary, Laws, and Applicability. Add SliceSet and ExtentRule only when the same declared kind can have different members at different U.ContextSlice values and one named reuse needs that difference. Add A.6.5 SlotSpecs that declare the direct relation's participant meanings only inside a reusable RelationSignature; add operation argument and result declarations under A.6.1 when a mechanism declaration needs them. Add dependency declarations only when another signature relies on provided names or laws.

What goes wrong if this pattern is missed: content about later realization, evaluation, and publication accumulates inside the declaration. A later user cannot tell which names and laws are reusable, where they apply, or whether a changed implementation has changed the declaration.

What this buys: one identifiable declaration can be reused while later realizations and uses change under their own subject patterns.

Do not use this pattern merely to state that a direct relation obtains or that one work occurrence produced a result. State that claim directly. A maintenance work plan may reuse the words connector and conservation law while scheduling tasks; it remains a work plan unless its own claim content performs the reusable declaration job above. Construct a signature only when reusable declaration content is the current object.

#Problem

FPF uses a signature when the episteme itself performs the reusable declaration job above: it identifies the declared subject and value or result range, supplies terms and laws another use may rely on, and says where those laws apply. Current non-exhaustive declaration families include theory or A.3.3 U.Dynamics epistemes, mechanism or A.19.SelectorMechanism declarations, method-kind declarations, formal substrates, and direct relation-kind declarations; these examples create neither a shared subject kind nor a closed family of signature profiles. Without one precise ontic:

1. the signature is confused with the entity it describes;
2. a relation declaration is confused with an obtaining relation occurrence;
3. applicability is reduced to an unexplained context label;
4. every declaration is forced into one rigid table-shaped publication form, even when a readable sentence is enough;
5. imported names and exported names remain implicit, so dependent declarations cannot be replayed safely.

The central problem is not missing syntax. It is failure to keep the declaration episteme, its declared subject, the subject's occurrences, and later uses of the declaration as different objects.

#Forces

#Solution

Use U.Signature as the dependent durable U-kind for a reusable law-governed declaration episteme. Identify the episteme through its content, exact EntityOfConcernRef, and effective U.ReferenceScheme. Let the declaration state its vocabulary, laws, and applicability. Keep the declared subject and every later realization under their direct kinds and relations.

Local signature mantra. Name the subject of the reusable declaration and the range of values or results it covers. List the terms another user may reuse, the laws that user must preserve, and where those laws apply. Add relation-participant declarations, operation inputs or results, slice-and-membership rules, or dependencies only when one named reuse calls for them. Keep implementations, evaluations, work, and publication outside the declaration.

In FPF terms, the subject is the exact EntityOfConcernRef; SubjectKind, RangedValueKind, and optional ResultKind state the declared subject and range; and Vocabulary, Laws, and Applicability state the reusable terms, regularities, and use boundary. Add A.6.5 SlotSpecs only when a reusable RelationSignature must preserve the same participant meanings and types. Add A.6.1 operation arguments or results only for a current mechanism declaration. Add SliceSet and ExtentRule only when the same declared kind can have different members at selected context slices. Declare a dependency only when another signature actually relies on imported or provided names or laws. If the named reuse still works without an optional addition, leave that addition out. Implementations and realizations remain under A.6.1, evaluations under their direct evaluation patterns, work under A.15.1, and publication under E.24.PUB. The mantra is Plain recall wording. Its imperative grammar does not assert condition-governed continuation. Apply A.22.CGUS only when one independently identified A.22 structure has local loci and at least two potential continuations defined by its selected relations and applied constraints.

#Admit and identify U.Signature

U.Signature is a same-individual dependent durable U-kind under U.Episteme. C.2.1 first identifies one episteme through one EpistemeConstitutionRelation by its complete claim content, exact independently governed EntityOfConcern, and effective U.ReferenceScheme. The claim graph and reference scheme are epistemic constituents; the EntityOfConcern is not. A.6.0 adds a stable membership condition and practitioner-facing declaration use to that already identified individual. It adds no second constitution relation, identity discriminator, assembly, composition rule, or holon test.

An already identified episteme is a U.Signature exactly when, under its effective U.ReferenceScheme, its complete identity-bearing claim content carries a reusable law-governed declaration about its exact EntityOfConcern and includes all of the following with substantive meaning:

• direct SubjectKind and RangedValueKind declarations that identify the declared subject and value range;
• Vocabulary that supplies the designators needed to reuse the declaration;
• Laws that state the reusable predicates, equations, invariants, closure conditions, or other declared regularities;
• Applicability that bounds where those claims are used;
• ResultKind, SliceSet, ExtentRule, and dependency, import, or provided-name declarations only when those distinctions are current for the declaration.

Judge the complete claim content, not a selected subset or the presence of field names. A minimal directly authored signature may carry the declaration content required by the A.6.0 membership predicate in one claim graph without citing any smaller episteme. A signature may instead cite separately identified source or dependency epistemes, provided its own claim graph names the dependency relation and the declaration meaning thereby reused. Those source epistemes remain separate individuals connected through their governing dependency, source-use, edition, or other direct relations; they are not components assembled into the signature, and their citation alone does not establish signature membership.

E.24.UK governs the one-time public admission of the dependent kind. In project work, authoring a new declaration candidate, or revising a declaration so that its claim content, exact EntityOfConcern, or effective U.ReferenceScheme changes, yields a resulting C.2.1 discriminator triple. When the one EpistemeConstitutionRelation for that triple obtains, C.2.1 identifies the resulting episteme; A.6.0 then judges whether that already identified individual satisfies the U.Signature membership predicate, without adding a second constitution occurrence or identity discriminator. An optional separately reviewable membership judgment is another classification-assertion episteme whose exact EntityOfConcern is the candidate; that assertion neither creates the candidate nor admits the public kind. Citing, comparing, or reusing an unchanged episteme, or judging its membership without changing a C.2.1 discriminator, creates neither another episteme nor another constitution occurrence.

The signature keeps the C.2.1 identity of the same episteme. Two designations resolve to that same individual only while the complete claim content, exact EntityOfConcern, and effective U.ReferenceScheme are unchanged. Changing any discriminator identifies another U.Episteme; call that new individual a U.Signature only if it independently satisfies the membership predicate above. State an edition, refinement, or supersession relation only when its own direct predicate obtains.

The declared subject remains the independently governed EntityOfConcern, not the signature. A realization of the declaration remains under its direct pattern. A description whose EntityOfConcern is the signature is another episteme. Publication occurrence, publication form, U.PresentationCarrier, and C.29 representation remain separate objects and relations; publication or visible form establishes neither identity nor membership. G.11 currentness and every later work or use likewise remain neighboring judgments and relations rather than signature identity components.

#Write the minimum declaration content

The four content groups are semantic components, not a mandatory visual table. A publication form may present them as paragraphs, a table, formal declarations, or another representation. A publication occurrence makes a selected episteme edition available through that form without changing its content.

SubjectKind and RangedValueKind are declaration-content components. They do not create a second hierarchy beside C.3 or E.24.UK. A.2.6 supplies addressable U.ContextSlice values; C.3.2 governs the membership judgment and any optional materialized KindExtension representation. SliceSet is not a generic space, time interval, numeric or result range, or changing dataset. ExtentRule is not an arbitrary change function: it tells how the declared kind's members are determined at one named slice. A time selector may be part of a U.ContextSlice; a value or result range stays in RangedValueKind or ResultKind; changing data stays with its subject pattern; and a claim-bearing mathematical set representation opens C.29 separately. Leave both fields out unless membership of the same declared kind can differ across the named slices.

Applicability and meaning remain distinct. The effective U.ReferenceScheme is part of episteme identity. The exact U.ClaimScope delimits use; when current for the declaration, a relevant time interval, selected CHR:ReferencePlane, or selected BoundedModelUseStructure : U.Structure further delimits or organizes applicability. None replaces the reference scheme or claim scope.

#Use RelationSignature for reusable relation declaration

RelationSignature is the relation-facing use of one U.Signature. It is not a second U-kind.

Its EntityOfConcernRef identifies one exact already admitted direct relation kind. If A.6.RCD settles a derived relation kind, that kind counts here only after its direct subject settlement states the participant meanings, exact base-definition and named-substrate dependencies, obtaining and applicability laws, and a direct occurrence-identity rule. The derivation or predicate definition may be cited as a dependency, but a predicate-definition episteme whose EntityOfConcern is the reusable predicate definition rather than the admitted relation kind is not a RelationSignature. Its content declares:

• the relation-kind designator;
• one SlotSpec for each world-side participant meaning that needs reusable typed declaration;
• the direct pattern's obtaining predicate and declared laws, restated for reuse without claiming that the predicate is satisfied;
• applicability of those claims;
• the occurrence-identity rule supplied by the direct relation pattern, restated for reuse without applying it to any occurrence;
• for an admitted derived relation kind, the exact base relation definitions, named substrate and authorized derivation operation, and applicability dependencies already established by the direct subject settlement.

The direct relation pattern remains authoritative for when the relation obtains and how an individuated occurrence keeps identity. The signature declares those rules for reuse; it does not make the predicate true and does not create an occurrence.

A direct relation may obtain before anyone writes a signature. Ordinary prose may therefore stop at:

During Shift-17, Robot-7 is assigned as inspector through InspectionAssignment-17.

This is an A.2.1 assertion about an occurrence of declared species MaintenanceInspectionAssignment under U.SystemRoleAssignment. A.2.1 defines the species' predicate and occurrence-identity rule. The occurrence has Robot-7 as holder, InspectorSystemRole as assigned-kind value, and only the values required for any other declared participants. When several patterns must reuse those participant meanings, predicate, and identity rule, the species' RelationSignature becomes useful for typed assertions and F.6 attribution. When another claim must refer to this assignment episode, use A.6.REL for explicit individuation.

#Declare participant meanings and operation parameters under different specializations

For each world-side participant meaning whose reusable declaration is current, a RelationSignature declares one A.6.5 SlotSpec. The following code sketch is a compact representation of that declaration, not the world-side relation or its participants:

SlotSpec := <SlotKind, ValueKind, refMode>
refMode := ByValue | RefKind

Use A.6.5 to declare these participant meanings. In the simple MaintenanceInspectionAssignment species, use HolderSystemSlot and one declaration-local AssignedSystemRoleKindSlot whose ValueKind is the exact InspectorSystemRole domain. A stronger species adds only a real participant that changes its predicate or occurrence identity. Taxonomy episteme, reference scheme, interval description, and generic context may interpret an assertion but are not generic world-side assignment participants. Do not force SlotSpecs into a one-off assertion that has no receiving typed use.

A formal or mechanism declaration may instead need named operation arguments and a result. A.6.1 governs that OperationAlgebra; C.29 governs any mathematical operand order, product, function, or tuple used to represent it. Those operation parameters do not become RelationSignature SlotSpecs or SlotKinds merely because the same notation uses angle brackets or numbered arguments. When a relation claim consumes a mathematical representation, state an explicit correspondence between the representation's operands and the independently declared SlotSpecs.

#Expose real declaration dependencies

Open a SignatureManifest only after this test. Add an import when removing one named provider would leave this declaration unable to interpret a required non-local term or unable to replay one of its stated laws; name the provider and the exact required term or law. Add a provide entry when this declaration introduces a named term or law and one named dependent declaration relies on it. A background citation, similar vocabulary, shared publication, list membership, or convenient replay order is not a dependency.

The compatible heading is retained for dependent patterns; it names neither another U-kind nor one uniform ontic object. It co-locates entries with three functions: id is an identity-neutral display designator; signatureRef and its optional .edition pin form a governed reference to an already recoverable signature episteme; and imports and provides may carry or represent dependency and name-or-law introduction claims in the signature's exact U.ClaimGraph. Co-location makes neither every entry identity-bearing claim content nor any entry a relation occurrence.

The compatible section may carry entries with these functions:

A change confined to the spelling of id or the serialization of signatureRef preserves episteme identity only when the reference still resolves to the same episteme and its exact claim content, exact EntityOfConcern, and effective U.ReferenceScheme remain unchanged. Changing signatureRef.edition selects another already recoverable edition; it does not by itself establish an edition relation, historical continuity, or U.Signature membership for the referent. If a C.2.1 identity discriminator changes, A.6.0:4.10 governs the resulting identity.

Use these dependency-manifest predicates:

• SM-1 Term-and-law resolution. Every required non-local term or exact law claim resolves under the effective reference scheme to the one named provider declaration that supplies it.
• SM-2 No redeclaration and legal direction. A provided term or law is not also supplied by a transitive import under the same effective reference scheme, and the claimed provider-to-consumer direction matches the predicate of the exact dependency or source-use relation rather than a drawn arrow or list order.
• SM-3 Replay order and cycles. A selected one-pass provider-to-consumer replay method requires an acyclic ordering of the recovered dependency designations. A cycle means that this replay method cannot run; it does not by itself prove that every semantic dependency in the cycle is prohibited. Apply each exact dependency governor to its edge. If no current governor decides whether the semantic cycle is legal, return an exact missing-governor blocker instead of deleting an edge or inventing an order. Any graph, cycle check, or ordering notation remains a C.29 representation.
• SM-4 Export boundary. A dependent declaration relies on provided names and cited laws, not on private publication layout or implementation detail.

The remove-the-provider test above identifies a candidate dependency; it does not make a relation obtain. State the exact dependency or source-use relation only after its direct predicate is satisfied for the named provider, consumer, term or law, and use. A citation, manifest entry, list membership, or replay result can support an assertion about that relation but does not create the relation occurrence. A provider or provider-edition change may require resolution, replay, or currentness review; it changes the consumer signature's identity only when the consumer's own claim content, exact EntityOfConcern, or effective reference scheme changes.

A governed reference to a separately identified object is not an exported vocabulary name merely because that reference appears in the signature.

#Specialize declaration use without minting another root kind

A signature profile is a constrained use of the same U.Signature kind. The profile states which content is current and which neighboring patterns define or constrain later use.

profile = FormalSubstrate. Declare vocabulary and terms, inference kinds, formal laws, applicability, and the actual declaration dependencies carried in the signature's claim content. A.6.1 separately governs OperationAlgebra, operation designators, typed argument and result positions, admission conditions, application, and realization. An A.6.1 declaration may cite the FormalSubstrate signature; that citation does not make the operation part of this signature. When a mathematical object is selected as a lens for another entity, C.29 governs the lens-use claim; usefulness does not make the mathematical object a signature.

profile = PrincipleFrame. Write the postulates and invariants, then name the observable distinction each one requires: what must be observed or compared to tell whether the frame's claim holds. Cite the separately identified characteristic or measurement declaration that makes that distinction checkable; units, scales, CHR:ReferencePlane values, comparators, and normalizations remain under A.17, A.18, C.16, CHR, A.19.CPM, and A.19.UNM. If the text decides whether a proposed operation application, run, or gate may proceed, move that decision to A.6.1 or the direct evaluation and gate pattern, including A.21/C.11 where applicable. A PrincipleFrame may state what a decision must respect, but it is not that admission decision. When a reader carries its claim into another context or effective reference scheme, first recover the two exact F.17 local senses. Cite an F.9 Bridge only if its direct predicate obtains; state the bounded-use claim, direction, preservation, loss, and any required reliance separately. A context or scheme difference alone creates no Bridge. Cited declarations remain independently identified objects, not extra PrincipleFrame identity components.

State a relation between two signatures directly as refinement, conservative extension, equivalence, or another independently governed relation only when that relation's own predicate obtains. Before using the refinement label, compare all three reusable content duties: Vocabulary, Laws, and Applicability. Name the terms preserved, added, or removed; the laws preserved, strengthened, or changed; and whether the population, time, CHR:ReferencePlane, and claim scope stay the same, narrow, or widen. An unexplained applicability widening fails the refinement claim; use another direct relation whose predicate explicitly permits the widening instead of hiding it under refinement. Use a C.29 morphism only when a mathematical structure-preservation claim is actually current.

#Rule-content actual-use predicate declaration

RuleContentBasisFindingDefinition@R7 is one ordinary U.Signature for two reusable predicates over claim content. Its exact EntityOfConcern is the reusable predicate definition; both SubjectKind and RangedValueKind are U.ClaimGraph. No distinct result kind is current because an ordinary C.2.1 assertion states whether a predicate obtains. The declaration is not a RelationSignature: dependentContent and baseContent are semantic parameters, not world-side relation participants or A.6.5 SlotSpecs.

Its vocabulary includes SelectedRuleContentSubgraphDesignation@RuleContentBasisFindingDefinition-R7, derivedUsingRuleContent@RuleContentBasisFindingDefinition-R7, and evaluatedAgainstRuleContent@RuleContentBasisFindingDefinition-R7. The designation resolves one exact nonempty base subgraph selected for one identified use; it is not a U-kind or intrinsic classifier. RuleContentDerivationProfile@R7, RuleContentEvaluationProfile@R7, and RuleContentBasisFamilyAlgebra@R7 are named subgraphs of this signature's ClaimGraph, not separate entities, kinds, signatures, registries, or occurrences.

The derivation predicate obtains only when an identified derivation claim used exact baseContent as a formal premise under a declared inference rule or application to produce exact dependentContent. The evaluation predicate obtains only when an identified criterion-selection claim selected exact baseContent for one exact bounded evaluation claim concerning dependentContent. Definition, constraint, applicability, consultation, citation, influence, provenance, evidence, evaluation Work, result, sufficiency, assurance, reliance, authority, and publication establish neither predicate by themselves.

An assertion names the exact actual-use claim identity and bounded receiving use, and adds scope, temporal policy, scheme interpretation, Bridge/loss, or source/witness qualifications only when each independently changes that assertion. Same-scheme use invents no Bridge. A changed subject, content, mode, use, actual-use claim, scope extension, time policy, or interpreted endpoint identifies a successor assertion under C.2.1 rather than mutating every use of this reusable definition.

R7 is a changed-law successor of historical RuleContentBasisFindingDefinition@R6, not identity-continuous reuse. The C.2.1 succession assertion names predecessor, successor, changeClass = reusable-law-change, the changed law set—formal-premise/criterion-selection truth split, owner-claim removal, per-question analysis separation, independent candidate axes, pairwise compatibility, temporal-policy identity, and non-permissive reliance—and inheritedAcceptanceOrUse = none. A dependency pin selects R6 or R7 explicitly; a pin change reopens dependants rather than silently retargeting them.

#Keep declaration, realization, and use under their direct patterns

The rows name the direct patterns that define or constrain these common adjacent objects and claims. Their co-location is only a compact representation and does not change any subject pattern's scope.

#Add explicit objects only for a named receiving use

Make three decisions by naming the next sentence, comparison, tool, or declaration that must work:

1. State the direct relation and stop. Use this branch when the task only asks whether one named A.2.1 direct-species predicate holds for its actual participants during the named episode. For example, During Shift-17, Robot-7 is assigned as inspector through InspectionAssignment-17 is a complete current assertion when the direct MaintenanceInspectionAssignment predicate holds. State the affirmative or negative claim under A.2.1, or an exact governed modal claim when that family is current. Add an A.10 or receiving-evaluation reliance judgment only when the task separately asks whether to rely on the assertion.
2. Share one declaration. Reuse or author a signature when at least two named claims or consumers must use the same participant meanings, vocabulary, laws, or applicability. For example, a staffing assertion and an F.6 Work-attribution consumer can cite the MaintenanceInspectionAssignment RelationSignature when both must interpret HolderSystemSlot, its declaration-local assigned-kind slot with exact InspectorSystemRole domain, any real species-specific participants, and the same direct predicate. One sentence that merely repeats the word assigned does not open this branch. When a declaration is authored, C.2.1 identifies the episteme from its own claim content, exact EntityOfConcern, and effective reference scheme; A.6.0 then judges U.Signature membership.
3. Distinguish one occurrence. Open occurrence identity only when a later claim must refer to that same occurrence, compare or qualify it, track its beginning, continuation, cessation, or change, or use it as a participant of another relation. For example, F.6 work attribution must cite the exact covering assignment episode, and a staffing history that compares Shift-17 with a later reassignment must apply A.2.1's uninterrupted-obtaining same-versus-new-occurrence rule. A roster-row identifier that merely designates an assertion identifies neither the assignment occurrence nor a new occurrence; use F.18 only after A.2.1 has distinguished the occurrence to which a reference should resolve.

These are the receiving-use thresholds. They concern three different objects and are not stages that construct a relation or episteme from need. The stop is observable: the target direct assertion, shared declaration for the named consumers, or occurrence-referencing claim can be written without another unresolved object. Authoring, selecting, reusing, or explicitly individuating is motivated by that target but supplies no identity criterion and creates neither the episteme nor the relation occurrence. Selecting or reusing an unchanged episteme leaves its identity unchanged; neither a reference nor a log entry creates its referent. When entries, branches, returns, or stops form one reusable structure, apply A.22.CGUS only after the A.22 identity, local locus bindings, selected relations and constraints, and potential continuations are recoverable. One condition-dependent sentence is not enough.

#Recover formal-substrate and PrincipleFrame uses by direct governing relation

The same independently identified formal object or episteme can participate in these different uses while retaining its own identity and kind. Its identity does not decide which declaration, dependency, operation, lens, or carry-through relation is current.

For a PrincipleFrame, write one postulate or invariant together with the observable difference that would count for or against it. Cite a characteristic, measurement, unit, scale, reference plane, comparator, or normalization declaration only when that declaration is needed to state or check that difference; an informative citation is not a dependency. Do not put an operation-admission, run-acceptance, or gate-passage verdict into the frame. If a reader proposes to use the frame's claim in another context or reference scheme, recover the two exact F.17 local senses and test the direct F.9 predicate. Cite a Bridge only when it obtains; state preservation and loss in a separate bounded-use claim and establish any required reliance before use. A context or scheme difference alone creates no Bridge. A cited declaration may be superseded, or an independently obtaining dependency relation may cease or be replaced, without retroactively changing the PrincipleFrame's identity. Changing the PrincipleFrame's own citation or dependency claim changes its claim content and therefore identifies another episteme; the same follows when its exact EntityOfConcern or effective reference scheme changes. Any edition, refinement, or supersession relation between the two epistemes must independently obtain and must pass the Vocabulary-Laws-Applicability comparison above.

#Change the exact object that changed

Apply C.2.1 first. Every U.Episteme is identified by exact claim content carried by one exact U.ClaimGraph, one exact EntityOfConcern, and one effective U.ReferenceScheme. Changing any member of this mandatory triple identifies another episteme. That episteme is a U.Signature only when it independently satisfies A.6.0 membership. A changed discriminator, SignatureId, or signatureRef.edition value does not by itself establish signature membership or historical continuity.

A change to imports or provides changes the consumer signature's identity only when it changes that signature's own claim content. A changed provider or provider edition can instead leave the consumer episteme unchanged while requiring the named dependency or source-use assertion, resolution result, replay result, or currentness judgment to be reconsidered.

A changed later use does not change the signature unless the change alters one of its C.2.1 identity discriminators. For example, a new mechanism realization remains a new realization, and a new publication layout remains a new publication form.

Connect two different epistemes by EpistemeEditionRelation, refinement, supersession, or another independently governed continuity relation only when that relation's own predicate obtains under its direct governor. Revision work, shared title, changed identifier, citation, or sequence alone establishes no such occurrence.

When a once-current signature becomes stale while its identity remains recoverable, G.11 governs currentness and selection among recoverable editions. G.11 creates neither a later episteme nor an edition, refinement, or supersession relation.

Reopen declaration authoring when a proposed change affects the signature's exact claim content, EntityOfConcern, effective reference scheme, declared dependency, Vocabulary, Laws, Applicability, or the boundary of a FormalSubstrate, PrincipleFrame, or other admitted profile. The revised claim-bearing candidate is another C.2.1 episteme; A.6.0 judges its signature membership again, and any edition, refinement, or supersession relation remains a separate claim under its direct governor. Also reopen the affected declaration element when current problem-owning-domain or formal-method SoTA changes the term, inference form, law shape, applicability condition, or realization boundary being declared.

When a governed kind name, SubjectKind, RangedValueKind, SlotKind, RefKind, or exported term is renamed, rerun E.10 and F.18. Accept the rename only when a cold reader can still recover the same FPF kind, declaration use, and practical action; otherwise keep the old name or return the naming defect. Do not revise the signature merely because a realization, work occurrence, measurement, Bridge use, evidence-use relation, publication, provider currentness, or G.11 selection changed. Update that neighboring object under its subject pattern, and reopen the signature only if its own claim or dependency content must change.

#Archetypal Grounding

#Physical modeling: connector-equation FormalSubstrate

A multi-domain modeling team repeatedly uses one connector-and-equation calculus. Its U.Signature(profile=FormalSubstrate) has that calculus—not a connection relation kind—as its exact EntityOfConcernRef. SubjectKind names the modeled connector declarations governed by the calculus, and RangedValueKind names its well-formed terms and equations. Vocabulary names the potential and flow variables. Its inference and equation laws say how a selected connection assertion yields potential equality and the zero-sum flow equation. Applicability states the modeling assumptions and selected CHR:ReferencePlane. If those terms or laws cannot be interpreted or replayed without a named quantity declaration, the manifest names that provider and the exact imported term or law; otherwise a background citation stays outside the dependency manifest.

The sentence ModeledPort_A is connected to ModeledPort_B is a separate model-side connection assertion. This FormalSubstrate neither supplies that relation kind nor makes the assertion true. If repeated typed connection claims require a RelationSignature, first recover or admit the exact modeled-connection relation kind, its two connectable-port participant meanings, direct predicate, qualifier laws, Applicability, and occurrence-identity rule; only then may that relation declaration cite this FormalSubstrate when the dependency test passes. A generated equation set and a connector diagram are later result and representation epistemes, not either declaration; deeper operation, work, representation, and publication questions require A.6.1, A.15.1, C.29, and E.24.PUB.

Practical payoff: engineers can compare the connector vocabulary and equation laws across tools without treating the calculus as a connection relation, a concrete connection assertion, a generated equation set, or a diagram.

#Clinical work: dose-response claim before relation-kind admission

A clinician needs the ordinary claim: During PatientEpisode_8472, Intervention_5mg was associated with OutcomeChange_BPminus10 over ObservationWindow_Days0to28 under the stated dosing and population conditions. No current direct pattern in this corpus governs a DoseResponseRelationKind. For this use, A.6.RCD therefore keeps the sentence as a local compound claim in one C.2.1 episteme; repeated clinical uses may justify a reusable predicate-definition episteme, but neither result is a RelationSignature or a relation occurrence.

The local predicate treats the named patient episode, intervention, outcome change, and observation window as its exact inputs. ObservationWindow_Days0to28 answers how long this patient's outcome change is aggregated for this assertion. The claim's or reusable definition's Applicability instead states the population, dosing protocol and conditions, and the time and claim scope in which the rule is used. Do not repeat the patient window as Applicability unless a separate applicability claim genuinely uses that same interval. Before any RelationSignature can be published, the missing-governor result must name the candidate relation kind, these participant meanings, the direct predicate, Applicability, occurrence-identity rule, and a standalone clinical domain governor; E.24/E.24.UK must admit the result. Until then, no plausible SlotKind names or mention of a response creates that settlement.

A selected assay-result episteme may support or refute reliance on the compound assertion through A.2.4/A.10, but it does not make the clinical predicate true. A changed assay result changes that support or leaves it unresolved; it does not change the reusable predicate definition. A changed outcome meaning, population, dosing condition, or declared applicability changes the definition's claim content and C.2.1 identity, while still admitting no relation kind by itself.

Practical payoff: clinicians and analysts can write and compare the bounded claim now, reuse a settled predicate definition when repetition warrants it, and keep patient episodes, evidence epistemes, and evidence-use claims distinct without pretending that a clinical relation signature already has a governor.

#Learning: criterion declaration and evidence use

During AssessmentInterval_2026Q2, learner Learner_17 correctly diagnoses cavitation in PumpCase_A and PumpCase_B and selects the stated corrective action. A separate observation episteme, PerformanceObservation_17A, states what was observed. After applying the reusable declaration Criterion_PumpCavitationDiagnosis_v3, assessor Assessor_4 makes the separate competence-assertion episteme CompetenceAssertion_17_Q2: Learner_17 met Criterion_PumpCavitationDiagnosis_v3 for diagnosing cavitation and selecting the stated corrective action in PumpCase_A and PumpCase_B during AssessmentInterval_2026Q2.

Criterion_PumpCavitationDiagnosis_v3 is the reusable declaration governed here. Its EntityOfConcernRef identifies the pump-cavitation diagnosis criterion; SubjectKind names assessed pump-cavitation diagnostic performances and RangedValueKind names the results meets and does not meet. Vocabulary defines the cases, diagnosis, and corrective action; Laws say which observable response earns either result; Applicability limits the equipment family, task form, and assessment method. The observed performance, its observation episteme, the criterion, and the assessment interval are not relation SlotSpecs merely because the competence claim mentions them. No current direct pattern supplies DemonstratedCompetenceRelationKind, so this case asserts neither that relation signature nor a world-side demonstrated-competence occurrence.

For this bounded assessment use, the direct A.2.4/A.10 evidence-use relation names PerformanceObservation_17A as EvidenceEpisteme, the quoted competence claim as EvidenceTargetClaim, the two specified cases as EvidenceClaimScope, supports as EvidencePolarity, and AssessmentInterval_2026Q2 as EvidenceRelevanceWindow. Its A.10 evidence-provenance path identifies the observation work, method, carrier, and assessor's relying context. That relation supports reliance on this exact competence claim; it does not make the claim true or authorize course progression. A self-report without that observation path, a performance on another task, or a performance outside the named interval does not support this bounded claim.

Changing the publication form or making another publication occurrence for the unchanged criterion or competence assertion changes neither episteme. Changing the criterion's Vocabulary, Laws, or Applicability changes its claim content and identifies another declaration episteme; any edition or continuity relation must separately obtain. A new performance observation or assessor claim likewise identifies separate evidence or claim content rather than changing the criterion declaration.

Practical payoff: two assessors or curriculum tools can reuse the same declared criterion and its performance-and-result meanings while making separately identified competence claims about separately observed performances.

#Formal work: length-indexed zero-vector operation

An engineer declares the reusable operation zeroVector(n) in ordinary language: give it a natural number n; it returns a vector of n real-valued entries, every one zero. In the A.6.1 OperationDeclaration, argument lengthIndex means the requested component count and has ValueKind NaturalNumber. Result zeroVectorResult means the returned zero vector and has the indexed result family FiniteVector(RealScalar, n). The application predicate says that one application binds one n and returns that vector. The dependency law states length(zeroVector(n)) = n, and the zero law states that every indexed entry equals scalar zero. Applicability limits this declaration to finite vectors over the declared RealScalar field.

The declaration imports the exact type-former FiniteVector(RealScalar, n) and its length-index law from FormalSubstrate signature FiniteVectorSubstrate_v2. Remove that provider and neither the result declaration can be interpreted nor the length law replayed, so this is a declaration dependency rather than a background citation. The operation argument and result remain A.6.1 declarations; they are not A.6.5 relation SlotSpecs.

A Lean representation may write the result as Vector Real n. A proof-carrying record representation may write entries: List Real together with lengthProof: entries.length = n. Because both represent the same operation declaration and no mathematical lens changes the next comparison action, A.6.3.RT alone governs this representation-scheme transition. It preserves the result-length index and the all-zero law. Lean binder order, implicit elaboration, record field order, and the location of the length proof are representation-local and need not survive. Stop here: neither notation's operand or field order becomes operation meaning or world-side relation ontology, and no C.29 result is needed. If a later comparison uses a named free-module lens to decide algebraic reuse, that changed lens use opens C.29 and must separately state the preserved addition and scalar action, the lost coordinate or layout detail, and the inference that the lens does not license.

Practical payoff: formal-methods engineers can fill and inspect the dependent A.6.1 declaration, test its actual FormalSubstrate dependency, and compare representations without inventing a neighboring relation signature.

#PrincipleFrame: heat-flow balance

A thermal-modeling team writes a PrincipleFrame stating that net heat flow across a selected system boundary must balance the change in stored energy. The frame names the observable distinction between inward and outward heat flow at that boundary. It cites separately governed heat-flow characteristics, units, the selected CHR:ReferencePlane, and the measurement declaration needed to check that distinction; its Applicability names the modeled systems and conditions for which the balance claim is made.

A residual below a chosen tolerance does not by itself belong to the PrincipleFrame and does not admit a simulation run. The comparator and tolerance remain under their direct comparison and measurement patterns; operation admission remains under A.6.1, and a gate-passage verdict remains under A.21/C.11. If a laboratory measurement sense is proposed for use in a plant-model sense, resolve both exact F.17 local senses and apply F.9. Cite a Bridge only when its predicate obtains; state the bounded use and any preservation or loss of sign convention, unit, and boundary interpretation separately.

Practical payoff: the physical principle remains reusable while the measurement setup, comparator, run decision, and cross-scheme transport can change or fail independently.

#Reduced ordinary-use case

The sentence During Shift-17, Robot-7 is assigned as inspector through InspectionAssignment-17 is enough for a task that only reports whether the direct MaintenanceInspectionAssignment predicate holds for its actual participants during that episode. Stop there. If a staffing assertion and an F.6 Work-attribution consumer must reuse the same participant meanings and assignment laws, cite that direct species' existing RelationSignature. If later Work attribution or history must distinguish this assignment from a later reassignment, apply A.2.1's direct occurrence-identity rule and refer to the distinguished episode. A roster-row id that merely points to the assertion opens neither branch. Each result is complete for its stated task; the shorter result is not an incomplete signature.

#Bias-Annotation

Scope declaration: Universal across FPF-governed domains.

• Gov. Favors making the direct governor of declaration membership, declared content, and neighboring claims inspectable, together with explicit dependencies. Counter-risk: declaration administration can grow beyond reuse value. Mitigation: add SignatureManifest only for actual dependency.
• Arch. Favors a small declaration core with direct neighboring patterns. Counter-risk: the signature becomes a central container. Mitigation: keep realization, work, evaluation, and publication with their direct patterns.
• Onto-Epist. Favors strict separation of declaration episteme, declared subject, obtaining occurrence, assertion, and representation. Counter-risk: excessive explicitness. Mitigation: stop at the direct assertion unless two named consumers share declaration content or one later claim must distinguish the occurrence.
• Prag. Favors reusable named SlotSpecs and laws. Counter-risk: one-off work becomes formal paperwork. Mitigation: ordinary direct sentences remain sufficient.
• Did. Favors the four content groups and local mantra. Counter-risk: readers mistake the mnemonic order for executable work. Mitigation: apply A.22.CGUS only to an independently identified structure of potential continuations; actual execution remains a separate Work or Transformation claim.
• Context transport. A signature's claims mean only what their stated scope and effective ReferenceScheme make them mean. Counter-risk: the same label in another context is treated as equivalent or safely substitutable. Mitigation: when a proposed reuse relates two exact F.17 local senses, test the direct F.9 predicate and cite a Bridge only when it obtains; state direction, rule, tolerated loss, and polarity in a separate bounded-use claim. Different contexts or schemes alone establish no Bridge. Without the needed semantic relation and use claim, do not transport the claim by label alone.
• Comparability. Two declarations do not become comparable because both expose numbers. Counter-risk: numeric appearance hides incompatible characteristics, measurement procedures, units, scales, comparators, or normalization. Mitigation: apply the current A.17/A.18/C.16 characteristic, measurement, and unit-and-scale patterns and A.19.CPM/A.19.UNM comparison and normalization patterns as the case requires, then state the resulting comparison boundary; keep their detailed legality and result-shape rules with those subject patterns.
• Register. Begin each technical declaration block and worked case with, or immediately supply, an ordinary sentence naming what the practitioner asserts or does and what visible result follows; then map that sentence to the exact FPF terms. Counter-risk: a technically correct block remains unusable without private decoding. Mitigation: use E.10's Plain-intent step, scan the recovered wording, and rescan every replacement; keep the repair only when the same governed object, subject pattern, admissible use, and practical action remain clear.

The examples deliberately span physical modeling, medicine, learning, and formal work. Each worked declaration has its own C.2.1 identity, which remains independent of its publication form; the examples do not share one declaration individual.

#Conformance Checklist

1. Exact declaration object. The text identifies one U.Signature episteme and one exact EntityOfConcernRef.
2. Identity. Content, EntityOfConcern, and effective U.ReferenceScheme remain recoverable.
3. Minimum content. SubjectKind and RangedValueKind, together with Vocabulary, Laws, and Applicability, carry semantic content rather than empty publication rows. ResultKind, SliceSet, and ExtentRule appear only when their declared distinctions are current.
4. Optional slice-dependent membership. SliceSet names the addressable U.ContextSlice values to inspect and ExtentRule determines Extension(SubjectKind, slice) only when the same declared kind can have different members across those slices; neither field stands for a generic interval, range, changing dataset, or set representation.
5. Vocabulary boundary. A declared token is not treated as durable U-kind admission without E.24.UK and its direct pattern.
6. Relation declaration. A RelationSignature identifies one exact already admitted direct relation kind. An admitted derived relation kind has direct subject settlement for participant meanings, base-definition and named-substrate dependencies, obtaining, applicability, and occurrence identity. A predicate-definition episteme is not treated as that RelationSignature, and the declaration does not assert or create an occurrence. Every worked case that uses a RelationSignature also names the already admitted relation kind, direct governor and predicate, participant meanings, Applicability, occurrence-identity rule, and one ordinary affirmative or negative assertion. A hypothetical domain-local relation kind is labelled and fully settled before the example uses it.
7. Direct relation-pattern governance. The direct relation pattern defines or constrains obtaining and occurrence identity.
8. Typed-declaration boundary. Reused participant meanings are declared inside a RelationSignature by A.6.5 SlotSpecs with exact SlotKind, ValueKind, and refMode. Operation arguments and results remain A.6.1 declaration content. Mathematical operands and field order remain representation-side under A.6.3.RT; C.29 opens only when a named mathematical lens changes the declared lens use or next comparison action. An operand-to-participant correspondence is stated only for an already governed relation claim.
9. Semantic locality. Meaning uses the effective reference scheme; applicability uses the exact claim scope and only qualifiers current for the declaration, such as a relevant time interval, selected CHR:ReferencePlane, or genuinely current model-use structure.
10. Dependency truth. Every import names the provider and exact term or law without which interpretation or law replay fails; every provide entry names a dependent declaration that relies on the introduced term or law. Citations and list order do not qualify. SM-1 through SM-4 hold, and a replay cycle is distinguished from a semantic-prohibition verdict.
11. Realization boundary. Mechanism behavior and admission conditions remain with A.6.1.
12. Progressive elaboration. A direct assertion is enough when the task only asks whether the predicate holds; a signature opens when at least two named consumers share declaration content; occurrence identity opens only for a later same-occurrence reference, comparison, qualification, history/change claim, or relation participation. A log or assertion identifier alone opens none of them.
13. CGUS boundary. Mnemonic imperatives are not called an executable sequence; any condition-governed unfolding claim uses A.22.CGUS.
14. Profile boundary. FormalSubstrate and PrincipleFrame remain profiles of U.Signature rather than new root kinds. A PrincipleFrame names its postulates and the observable distinctions needed to check them, leaves operation and gate admission with their subject patterns, and uses F.9 before carrying its claim across a context or reference scheme.
15. Changed object. Changed exact claim content carried by the U.ClaimGraph, exact EntityOfConcern, or effective reference scheme identifies another episteme. Judge A.6.0 membership for that episteme independently, and assert edition, refinement, supersession, or another continuity relation only when its own predicate obtains. A changed use, identifier, publication form, carrier, provider currentness, or G.11 refresh state does none of those things by itself.
16. E.10 self-application and reader use. Every materially changed technical declaration, mantra, checklist instruction, and worked case begins with, or immediately supplies, one ordinary claim, the practitioner action, and the visible result, then maps them to the exact FPF terms. Apply E.10 by value: unpack the decisive FPF terms locally, rescan the replacement candidate, run the value-substitution and cold-reader closure checks, and state one nearby non-use or alien case. A Plain label without those reader-visible results does not pass.
17. Case-level witness. Each worked case names its exact EntityOfConcern, the direct pattern that defines or constrains the claim being made, what the practitioner can now write, decide, or inspect, and the nearest category error it rejects. A domain label or the presence of several case headings is not evidence of cross-domain fit.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits.

• Reusable declarations receive one stable episteme identity.
• RelationSignature epistemes can expose named typed SlotSpecs without forcing every relation occurrence into a record.
• Meaning becomes inspectable through the exact reference scheme; applicability becomes inspectable through the exact claim scope plus any current time interval, selected CHR:ReferencePlane, or selected model-use structure.
• In physical-modeling practice, an author can reuse one connector-equation FormalSubstrate while keeping a modeled connection assertion, generated equations, and a diagram separate from that declaration.
• In clinical practice, an author can write the bounded patient-episode, intervention, and outcome assertion now, relate an assay-result episteme to that claim through A.2.4/A.10, and defer a RelationSignature until a direct clinical relation governor exists.
• A changed realization, observation, evidence-use relation, or publication can be repaired independently when the declaration's own claim content, EntityOfConcern, and effective reference scheme remain unchanged.

Costs and trade-offs.

• Before choosing a form, the author answers three concrete questions: does the task only ask whether one predicate holds; do at least two named consumers need the same declaration content; or does a later claim need to refer to the same occurrence, compare it with another, qualify it, record its history, or use it as a participant in another relation? Those answers select a direct assertion, reusable declaration, or occurrence identity.
• Authors must recover the exact declared subject and effective reference scheme; a familiar label is not enough.
• A RelationSignature case also requires an already admitted relation kind, direct governor and predicate, participant meanings, Applicability, occurrence-identity rule, and an ordinary assertion. Without that settlement, the author keeps a local claim, predicate definition, or exact missing-governor blocker instead of inventing SlotSpecs.
• Typed reuse adds authoring effort for A.6.5 relation SlotSpecs or A.6.1 operation declarations, plus A.6.0 dependency declarations only when another signature actually relies on named terms or laws.
• A change to exact claim content, EntityOfConcern, or effective reference scheme identifies another episteme even when the publication looks identical; authors must separately judge U.Signature membership and any claimed edition, refinement, or supersession relation.

#Rationale

The ontic is needed because the same reusable declaration is cited across work occurrences, publication occurrences, and representations. Treating it as only a table-shaped publication form loses identity; treating it as the declared world-side object collapses episteme and EntityOfConcern.

The declaration components answer four different engineering questions. SubjectKind, RangedValueKind, and optional ResultKind identify the declared subject and value or result range. When slice-dependent membership is current, SliceSet names the addressable context slices and ExtentRule says how the members of the same declared kind are determined at one slice. Vocabulary supplies reusable names and, for a RelationSignature, named participant SlotSpecs; A.6.1 supplies operation arguments and results for a mechanism declaration. Laws state the reusable regularities. Applicability states where those regularities are used. Their conceptual separation is stable even when publication layout changes.

RelationSignature is a use of U.Signature because it has the same episteme identity and content duties. Introducing a second root kind would duplicate those duties while leaving obtaining and occurrence identity with direct relation patterns anyway.

Progressive elaboration protects didactic primacy. A practitioner can begin with a readable relation sentence and add formal declaration only when reuse creates value. Exactness is increased for a named claim or operation, not for ceremony.

#SoTA-Echoing

Sources:

• JuliaHub, Dyad 3.2 documentation; Modelica Association, Connectors and Connections as historical lineage.
• Lean project, Inductive Types and Structures.
• TypeDB, relates statement.
• W3C, SHACL 1.2 Core.
• Almeida, Guizzardi, Sales, and Fonseca, gUFO: A Gentle Foundational Ontology for Semantic Web Knowledge Graphs.

These sources test the separation among declaration, represented structure, realization, and use. FPF's constructive ontology, C.2.1 episteme identity, A.6.5 relation-slot discipline, A.6.1 operation declaration, and direct relation patterns remain authoritative for the solution.

#Relations

• Builds on: A.7, C.2.1, C.3, A.2.6, and A.6.5.
• Governs: reusable U.Signature declaration epistemes, including RelationSignature use and the FormalSubstrate and PrincipleFrame profiles.
• Constrained by: E.10 for the register and usability of materially changed technical declaration blocks, the mantra, checklist instructions, and worked cases. The local result must expose the ordinary claim or action and the decisive governed terms to a cold reader; E.10 is the pattern for the trigger scan and wording-repair method.
• Coordinates with: A.6.REL for relation occurrence, A.6.RCD for needed-claim derivation and relation-kind settlement before declaration, A.6.1 for mechanism declaration and realization, A.3.1 for methods, A.15.1 for work, F.9 for explicit bridge use, A.17, A.18, C.16, A.19.CPM, and A.19.UNM for characteristic, scale, comparison, and normalization questions, C.29 for mathematical-lens use, and E.24.UK for durable U-kind admission.
• Described and published through: C.2.1, E.17, and E.24.PUB.
• Evolves with: G.11 for currentness and explicit direct relations between signature editions.
• Used by: C.22 task signatures for A.6.0 declaration identity and content; a changed C.22 discriminator identifies another episteme and establishes an edition only when the direct continuity predicate obtains. Also used by A.19.CPM comparison declarations, A.19.SelectorMechanism selection declarations, C.29 and E.18.1 when their current claim requires a FormalSubstrate declaration, and any pattern that needs reusable vocabulary, laws, applicability, or relation SlotSpecs. Specialized operation declarations remain under A.6.1 rather than A.6.0.

#A.6.0:End

#U.Mechanism - Reusable Law-Governed Operation Declaration

Status: Stable

Pattern kind. Ontic declaration pattern.

Builds on. A.6.0 for signature identity and content, C.2.1 for episteme identity, and A.2.6 for claim scope.

Coordinates with. A.6.REL for relation occurrences, A.6.RCD for the lightest honest comparison claim, A.6.5 for RelationSignature SlotSpec discipline, C.3 for local operation ValueKinds, A.1 for holon recognition, A.3.1 for Methods, A.15.1 for performed Work, F.9 for exact cross-scheme sense correspondence, C.2.1 for the separate claim that one Bridge suits one bounded use, A.10 for ordinary reliance on that claim, B.3 only for an actual named assurance claim, CHR for selected CHR:ReferencePlane values, A.1.1 and A.22 for a selected BoundedModelUseStructure, C.29 for mathematical-lens use, E.20 for mechanism introduction, E.24.PUB for publication, A.22.CGUS for a constraint-governed potential-continuation structure and its separate case results, and G.11 for currentness.

#Problem frame

An engineer needs a reusable declaration of operations, their typed argument and result positions, the laws they preserve, and the conditions under which an operation is admitted. The declared operation family may be used for physical modeling, clinical calculation, selection, normalization, or another named engineering use.

Use this pattern when the working question is:

What operation family is being declared, which laws govern it, and under which claim scope, time, selected CHR:ReferencePlane, and mechanism conditions may its operations be used?

Primary governed object. One claim-bearing episteme being identified as U.Mechanism. Inside that episteme's C.2.1 identity, its exact EntityOfConcernRef identifies the declared operation family. U.Mechanism is a dependent durable U-kind governed through the U.Signature identity and content settlement; it adds operation and admission semantics to the reusable declaration. The operation family does not become the episteme, and the episteme does not become its operation family.

Primary working reader and concern. The reader is an engineer who needs to reuse or compare an operation declaration without confusing it with the method that uses it, the entity that realizes it, the work that evaluates it, or a publication that presents it.

The first useful move is to name the declared operation family, its SubjectKind, and its family-level RangedValueKind, then state its OperationAlgebra, LawSet, AdmissibilityConditions, and exact Applicability. Add a family-level ResultKind only when one distinct result kind is current. For each reused operation, point to the argument or result meaning that carries the SubjectKind, RangedValueKind, or ResultKind meaning, then declare every additional argument and result meaning and exact ValueKind. Also state the operation's ApplicationPredicate, ApplicationExtentRule, and ApplicationIdentityRule. ApplicationExtentRule maps the facts at one independently grounded application locus to the semantically relevant boundary or interval over which that operation's predicate obtains; it is not the signature-level ExtentRule that determines kind membership at a selected context slice. Open an actual operation-application binding only when one particular application has been independently identified and a downstream claim says which value that application used or returned. Add a dependency manifest only when removing one named provider term or law would make this declaration uninterpretable or prevent law replay; shared wording or a background citation is not a dependency.

What goes wrong if this pattern is missed: implementation behavior, method instructions, evaluation outcomes, and publication metadata enter the declaration as if they were operation laws. A later user cannot tell whether the declaration changed, one realization failed, or only the evidence became stale.

What this buys: the declaration can remain stable while methods, realizers, evaluations, descriptions, and publications evolve under their own patterns.

Do not use this pattern merely because prose contains words such as mechanism, algorithm, process, or workflow. Recover the current object first. Use A.3.1 when the current object is a semantic way of doing, A.15.1 when it is performed work, and the direct system or episteme pattern when it is a physical assembly or a model description.

#Problem

FPF needs reusable operation declarations for scope, normalization, selection, comparison, physical modeling, and other domains. Without one precise ontic:

1. an operation name does not reveal its typed arguments or result;
2. declared laws are mixed with admission predicates and evaluation outcomes;
3. applicability is hidden behind an unexplained context label;
4. a realization is confused with the declaration it realizes;
5. mathematical notation or imperative prose is overread as an executable sequence;
6. descriptions, publications, methods, and dated work acquire mechanism identity by proximity.

The repair is not a larger declaration form. It is a smaller set of exact distinctions with progressive explicitness.

#Forces

#Solution

Use U.Mechanism as the dependent durable U-kind for a reusable law-governed operation declaration episteme. Identify it through C.2.1. Put operation vocabulary, typed argument and result declarations, application rules, laws, admission conditions, and applicability in its content. Keep each actual application and binding, realizing entity and realization occurrence, method, Work, evaluation, evidence, description, representation, and publication as its own object or relation. Section 4.7 handles each question under the pattern that can identify it.

Local mechanism mantra. Name the operation family and subject. Declare exact arguments, results, application rules, laws, admission conditions, and applicability. Bind actual values only in one independently identified exact application. State a realization relation only when a named realizer satisfies its predicate. Keep method, work, evidence, description, and publication separate.

This mantra is Plain recall wording. Its imperative grammar creates neither an executable sequence nor a work order. Apply A.22.CGUS only when one independently identified A.22 structure has local loci and at least two potential continuations defined by selected relations and applied constraints. A post-qualification presentation may show one traversal as a separate DemonstrativeUnfoldingSlice@Context; a prescribed order of performed work still belongs to the direct method-description or work-plan pattern.

#Admit and identify U.Mechanism

U.Mechanism is a dependent durable U-kind governed through U.Signature and therefore through U.Episteme. Its identity is:

<content, EntityOfConcernRef, effectiveReferenceScheme>

The dependence reuses the U.Signature identity settlement and subject pattern. It is not parthood and does not make U.Mechanism a root beside U.Episteme.

Use this early object-and-relation guide:

A machine part does not become U.Mechanism by being called a mechanism. For example, a pump assembly remains a U.System; this pattern defines or constrains a reusable operation declaration to which a realizing entity may be related while retaining its direct kind.

#State mechanism content

The following is a conceptual content outline, not a mandatory record or publication layout. The field and content-group names do not admit new U-kinds, relation kinds, SlotKinds, RefKinds, application records, or work objects.

U.Mechanism content:
  EntityOfConcernRef
  effectiveReferenceScheme
  SubjectKind
  RangedValueKind
  ResultKind?
  SliceSet?
  ExtentRule?
  OperationAlgebra:
    OperationDeclaration*:
      operationDesignator
      ArgumentDeclaration*:
        argumentDesignator
        argumentMeaning
        ValueKind
        bindingDesignationRule
        bindingPredicate
        cardinality?
      ResultDeclaration*:
        resultDesignator
        resultMeaning
        ValueKind
        bindingDesignationRule
        bindingPredicate
        cardinality?
      ApplicationPredicate
      ApplicationIdentityRule
      ApplicationExtentRule
  LawSet
  AdmissibilityConditions
  Applicability
  SignatureManifest?

The content components have distinct jobs:

Choose the three headline fields before listing operation positions. In plain terms: name the common kind of thing this operation family is about in SubjectKind, and name the common value domain over which the family ranges in RangedValueKind. Add ResultKind only when one distinct family-level result kind is current. For every operation, point to the argument or result meaning that realizes each current family-level declaration; extra arguments and results keep their own exact ValueKinds. A collection or reference wrapper likewise keeps its own ValueKind and must state how it refers to or contains the family-level kind. If the operations do not share one truthful subject-and-range pair, do not hide that fact in a union, Any, or an input or output list: split the declaration or stop. If several result kinds are only operation-local, omit the singular family-level ResultKind and keep them in their exact ResultDeclarations.

OperationDeclaration, ArgumentDeclaration, and ResultDeclaration are declaration-content terms, not U-kinds, direct-relation participants, actual values, or records. A bindingDesignationRule says whether a binding carries the value itself or one exact governed reference that resolves to it; a stored token or compatible reference does not establish a binding. An operation index may be derived from the operation designators for retrieval, but it is not another semantic content group.

A.6.5 SlotSpecs are not used here. They declare participant meanings only inside a RelationSignature for one already governed direct relation kind. A.6.1 argument and result declarations instead govern the named values of an operation application. Mathematical operand order remains a C.29 representation unless an explicit correspondence relates it to these independently declared operation meanings.

Keep neighboring facts outside mechanism identity-bearing content. Cite an F.9 Bridge only when two exact SchemeSenseCell values are being related across semantic contexts and its predicate obtains. Cite an actual application binding only when the downstream claim asserts which value the application used or returned. Evaluation, subject participation, evidence use, and realization each require their own obtaining predicate. A new neighboring occurrence or binding does not change U.Mechanism identity unless it reveals changed semantic content. A stable designator can refer to a mechanism episteme; file path, publication state, release label, and layout do not enter episteme identity merely because a tool stores them beside the content.

#State meaning and applicability without a generic context slot

Meaning and applicability answer different questions:

• the effective U.ReferenceScheme determines how the declaration content is interpreted;
• U.ClaimScope identifies the entities and relations to which the current use claim applies;
• the applicability interval states when that use is claimed;
• the selected CHR:ReferencePlane states the world, conceptual, or epistemic referent mode when that distinction is current;
• mechanism-specific conditions state assumptions that affect operation admission;
• optional modelUseStructureRef : U.StructureRef cites one selected BoundedModelUseStructure only when its relations delimit or change mechanism use.

Do not replace these values with one generic context field. Do not add modelUseStructureRef merely to preserve an old context column.

When one proposed receiving use spans different local senses, take these steps. First, use F.9 only to test the exact SchemeSenseCell correspondence and identify an obtaining Bridge. Second, state a separate current C.2.1 claim about whether that Bridge suits this use, in this direction, under this correspondence rule, and within this loss tolerance; give the claim affirmative or negative polarity. Third, choose the reliance branch from the consequence of the proposed use:

• for ordinary reliance with no actual assurance claim, use A.10. Name the exact evidence-provenance relation, bounded use, unsupported stronger use, window, and reopen or stop condition; proceed only with RelianceDisposition=pass;
• when an actual named assurance claim about this use is current, use B.3 and require its result for that same bounded assurance use. A direct domain rule may require the claim, but no Bridge, operation, display, or consequence creates it.

A Bridge, bounded-use claim, or reliance result neither admits an operation application nor says that reuse or Work occurred. A.6.1 AdmissibilityConditions still decide whether the proposed operation application is admitted; the actual application and bindings remain under A.6.1, and dated Work remains under A.15.1.

For example, let BridgeDoseTerms-7 be the obtaining F.9 Bridge between exact cells WardDoseValueCell and ProtocolDoseValueCell under its exact BridgePredicateProfile. The separate C.2.1 claim for reusing the protocol mechanism in the ward-to-protocol prescribing direction is negative because the use rule cannot meet the ward's zero tolerance for changing the dose unit or scale. That reuse stops before reliance. It also stops when the bounded-use claim is absent, when A.10 does not return RelianceDisposition=pass for an ordinary bounded use, or, when an actual named assurance claim is current, when B.3 has no AssuranceResult for the same use with disposition=supported-for-use. None of those outcomes makes the Bridge cease to obtain or makes an operation application admitted or actual.

A changed effective U.ReferenceScheme identifies another mechanism episteme through C.2.1. A changed selected CHR:ReferencePlane reopens the exact CHR assertion; a changed BoundedModelUseStructure requires exact A.1.1/A.22 assertions. If the project also claims that a plane transition or model-use change relation occurred, name its admitted predicate and participants or stop that claim. In every branch, name the exact source and target objects, the comparison or relation actually asserted, and the meaning or structure it preserves and loses. Any reliability claim remains under its direct reliability relation; neither a Bridge nor transition wording alters Formality or Guarantee by itself.

Numeric comparison and aggregation use A.19 and the direct measurement and scale patterns. Orders are declared before arithmetic is applied, units are made compatible before values are combined, and any reduction to one score cites its governing scalarization relation.

#Separate laws, admission, evaluation, and evidence

LawSet states regularities of the declared operations. AdmissibilityConditions decide whether one proposed application may proceed under current values and declared conditions. If a mechanism uses admit, degrade, or abstain, those are declared application dispositions with declared effects; they are not automatically the operation's result algebra.

A recognition-evaluation operation declares its own finite result value true | false | unknown. It returns true when its governed bound argument values determine that the candidate satisfies the selected world-side criterion, false when they determine that the candidate fails it, and unknown when missing evidence or an unavailable dependency prevents either determination. unknown is neither false, non-obtaining, a third candidate state, nor a receiving-work disposition. One admissible application can therefore return unknown.

World-side satisfaction or failure follows the direct criterion and candidate facts whether or not the project can currently determine them. Measurements, evidence, and assurance may support or warrant claims about those facts or about the returned judgment. If an exact evidence or interpretation-basis episteme is also a declared operation argument, its actual binding establishes only that the application used that value under the declared argument meaning. It does not make the criterion true, make the evidence correct, or constitute the candidate.

A separately materialized evaluation-result or classification-assertion episteme remains under C.2.1. Its claim content may state the returned value, while exact evidence and assurance relations govern support or warrant and G.11 governs edition currentness. Neither the episteme nor its currentness is the operation result value itself. Thus a mechanism realization may obtain while current evidence is insufficient to rely on it, and an evaluation may return a value without changing mechanism identity.

#Bind one actual operation application exactly

Use the readable direct forms first:

During exact application P of declared operation O, value V is bound under argument declaration a.
Exact application P returns value R under result declaration r.

A particular application is an occurrence of the ApplicationPredicate declared for exact operation O. The exact operation declaration supplies the application identity and extent rules; the phrase operation application does not admit a public OperationApplication U-kind, one universal application relation kind, or a work record. Its identity rule must name the semantically relevant application locus and boundary: for example, one physical cycle, one calculation invocation from call to return, or one comparison act from selected operands to returned judgment. If none of those examples fits, name the domain event that starts and ends the application. A trace identifier can designate that occurrence but cannot identify it by storage convention alone. If the declaration supplies no truthful application predicate, extent rule, or identity rule at the granularity required by the receiving claim, the actual application is blocked rather than reconstructed from a method name, plan row, log, or nearby result.

An operation-application binding is an occurrence of one declaration-local binding predicate under that exact application. Its direct participants are the exact application occurrence and the exact bound entity or value. The exact mechanism episteme and the named argument or result declaration govern the predicate; they are not substituted for the actual value. An argument binding obtains only when the value actually participates in P under the declared argument meaning, resolves under the binding designation rule, satisfies the declared ValueKind and cardinality, and lies within P's governed extent. A result binding obtains only when P actually returns that value under the declared result meaning; type compatibility, a planned filling, a method-description field, a stored reference, or a matching token establishes neither binding.

One binding occurrence is identified by <exactApplicationOccurrence, exactMechanismEpisteme, operationDesignator, argumentOrResultDesignator, exactBoundValue, maximalContinuousBindingExtent>. The extent lies within the exact application extent; a result-binding extent cannot begin before that result is returned. Repeated applications remain distinct through their independently governed application identities, and the same value bound under two declaration-local meanings yields two distinct bindings. A declaration may state a different cardinality or binding-continuity rule only when that semantics is part of the exact operation declaration.

The controlled phrase operation-application binding names this family of declaration-local binding occurrences; it is not a renamed universal work-participant, input, output, result, evidence, or production relation kind. A result binding says which value the application returned. It does not say that dated work produced or first constituted that entity, that a result episteme exists, or that another claim should rely on it.

A dated performance is a separate Work individual. When a Work claim also relies on one already identified application and its bindings, recover each exact actual performer through A.13 and let A.15.1 independently admit W : U.Work from its performance history, temporal extent, at least one obtaining enactsMethod -> U.Method relation, and at least one obtaining locally declared Work-to-System containment relation with its exact boundary. Add the same obtaining A.13 assignment and F.6 performedUnderAssignment(W, RA) only when this application account or its receiving use expressly consumes precise assignment-bound attribution; then check holder equality and assignment coverage. F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Add any additional enactment, work-to-referent, performed resource use, continuity policy, or Work-mereology relation only when the claim asserts it and its own predicate obtains. A.6.1 does not identify the Work occurrence. If neither a direct subject relation nor a truthful A.6.1 application binding establishes the claimed participation, retain the exact missing-governor blocker.

#State realization as a direct relation

Use the readable direct form first:

Entity E realizes U.Mechanism M for ClaimScope S during interval T.

The relation has these positions when typed reuse needs them:

The realization predicate obtains when the realizing entity provides the declared operations and preserves the declared laws for admitted uses in the stated scope and interval. A refined mechanism declaration may narrow Applicability or strengthen laws or admission conditions only with the preserved and changed semantic content stated explicitly. The realizing entity realizes the exact mechanism episteme named in the relation; it neither creates nor constitutes a refinement or edition relation. A claimed realization is lowered when it relaxes a declared law, bypasses an admission condition, or relies on undeclared operation meanings.

The non-derived participants are the declared mechanism, realizing entity, and realization scope. When a later use needs one occurrence distinguished from another, its direct identity is <declaredMechanism, realizingEntity, realizationScope, maximalContinuousRealizationInterval>. The interval is derived as the maximal continuous interval over which the realization predicate obtains. A new evaluation window or a gap in available evidence does not split the occurrence; demonstrated cessation followed by later realization does.

Ordinary use stops at the readable sentence. If another claim must refer to or compare one realization occurrence, the direct relation pattern and A.6.REL govern explicit occurrence identity. Evidence, evaluation, application, and binding occurrences remain supporting or use-side neighbors rather than realization participants.

#Keep mechanism, application, method, work, and description questions separate

One project concern can need several linked values. Recover each by its working question:

A MethodDescription may cite a mechanism declaration. An independently established selector result or one actual A.6.1 application may select a Method, and a direct constraint relation may constrain one; the mechanism declaration does not act merely by being named. An operation declaration may type a U.Method as an argument or result only when that is the operation's declared meaning; one actual application may then bind a Method value. Neither the declaration nor binding establishes a planned assignment, actual enactsMethod, or dated Work occurrence. One Work occurrence admitted under U.Work may enact the Method; the claim about that occurrence may cite the independently identified application and bindings under A.15.1. Performer assignment, extent, locally declared containing-system relations, resources, affected referent, continuity, and neighboring result or effect claims must each be established separately.

#State exact comparison claims among mechanism declarations

State a mechanism-declaration comparison only when its predicate is defined and the case facts satisfy it. A relation label alone admits neither a relation kind nor an occurrence.

These rows test declaration content; they do not admit a relation kind or occurrence. If the corpus already admits the exact comparison relation, use its direct pattern. If one case-specific comparison claim is enough, use A.6.RCD disposition 2 only after its exact claim subject, constructor, endpoint facts, and preservation facts are recoverable; otherwise return A.6.RCD's exact missing-substrate or missing-governor result. When the same predicate must be reused across cases, apply A.6.RCD's reusable predicate-definition branch. If a downstream use instead needs comparison occurrences with their own identity and no relation kind has been admitted, return missing-governor[mechanism-comparison-occurrence]; a label such as refinement or the adjective direct does not fill that gap.

In every branch, identify the exact endpoint mechanism epistemes, their effective U.ReferenceScheme values, claim scope, comparison predicate, and preserved and changed semantic content. Changed C.2.1 identity discriminators identify another episteme. If historical continuation matters to the comparison or receiving use, test the separate EpistemeEditionRelation(earlierMechanismEpisteme, laterMechanismEpisteme) under C.2.1. The two endpoint epistemes remain distinct participants; refinement, extension, equivalence, a shared name, or a later date establishes neither that relation nor one continuing episteme.

Continuing revision and replacement contrast. FixtureSelectionMechanism-R2 has changed claim content relative to FixtureSelectionMechanism-R1, so it is another mechanism episteme. In the continuing branch, the exact source use and the applicable continuity rule identify which claim, EntityOfConcern, and scheme features must be preserved or may deliberately change; the current facts satisfy that rule. Revision Work, Method, provenance, and change facts supply evidence for the test but no label makes continuity true. EpistemeEditionRelation(FixtureSelectionMechanism-R1, FixtureSelectionMechanism-R2) then lets G.11 follow the lineage to the later episteme, but every current application and realization claim is still re-evaluated against R2's own applicability and laws; an R1 realization does not automatically realize R2. In the replacement branch, FixtureSelectionMechanism-Alt1 has another C.2.1 identity and no obtaining edition relation to R1. Treat it as an independent declaration: carry forward neither R1 currentness nor its realization claims, and compare or select Alt1 only through its own applicability and an exact comparison predicate.

transport is not a generic A.6.1 mechanism relation. If the current question is cross-context SchemeSenseCell correspondence, identify the two exact F.17 cells, test the direct F.9 predicate, and cite a Bridge only when it obtains; infer neither mechanism identity nor equivalence from it. A changed effective reference scheme identifies another episteme; changed CHR:ReferencePlane or model-use organization requires its subject pattern. Compare mechanism content only after those exact endpoints and relations have been recovered.

Quotient, product, categorical morphism, and similar constructions are mathematical-lens claims under C.29 when they are current. The lens states which mechanism content is preserved and lost. Mathematical notation does not create an application, binding, realization occurrence, or mechanism U-kind by form.

#Keep description, representation, and publication separate

U.Mechanism is already an episteme. A second episteme that explains, summarizes, or compares it is a C.2.1 meta-description whose EntityOfConcernRef identifies the mechanism episteme. A diagram, equation set, program, or table is a representation governed by A.6.3 and A.6.3.RT when representation transition matters. An E.24.PUB publication relation makes one selected episteme edition available; an information-carrier relation may carry that publication, but neither relation becomes the mechanism episteme.

A grouping of several mechanism epistemes and realizations may be selected as a U.Structure or shown through a U.View when that structure or view is current. The grouping does not admit another root kind by itself.

#Use progressive explicitness

Use five degrees of explicitness:

1. A direct sentence names one operation and its condition clearly enough for present work.
2. A U.Signature is identified when reusable vocabulary, laws, or applicability matter.
3. A U.Mechanism is identified when reusable operation and admission semantics matter.
4. One particular application and its exact argument or result bindings are identified only when a downstream claim asserts that the application occurred or that one exact value participated or was returned.
5. A mechanism-realization relation occurrence is explicitly individuated only when another claim relies on that occurrence identity.

These are thresholds of explicitness, not a continuation structure. If entries, branches, returns, or stops form one reusable structure, apply A.22.CGUS only after its A.22 identity, local loci, selected relations and constraints, and potential continuations are recoverable.

#Change the exact object that changed

When mechanism content, EntityOfConcernRef, or the effective U.ReferenceScheme changes, identify another U.Mechanism episteme under C.2.1. A changed operation, argument or result declaration, application predicate, application identity or extent rule, law, admission predicate, applicability claim, or relied-on dependency therefore changes the declaration episteme when its semantic content changes.

Call that later episteme an edition of an earlier mechanism episteme only when the exact C.2.1 EpistemeEditionRelation obtains. With that relation, G.11 may follow the lineage to discover the later declaration and then re-evaluate its applicability, applications, bindings, and realizations. Without it, keep the later declaration as a non-continuing replacement and open those current-use and realization questions independently. A shared label, refinement claim, later publication, or changed filename supplies no continuity.

A new particular application or binding, new realizer, failed evaluation, new evidence item, changed work occurrence, returned value, or new publication does not change the mechanism episteme by itself. Repair that neighboring object and the affected relation. Reconsider the declaration only when the change overturns relied-on mechanism-content semantics.

Use E.20 when introducing a new mechanism declaration or changing the governing assignment of mechanism semantics. Use G.11 when the question is currentness, freshness, selection of a continuing later episteme, or decay of a relied-on declaration or cited source episteme.

#Archetypal Grounding

#Physical modeling: thermal connector operations

A physical-modeling team repeatedly uses a thermal connector operation family. The mechanism episteme declares named temperature and heat-flow argument and result meanings with their exact ValueKinds, connection operations, equality and conservation laws, application identity and extent rules, and admission conditions for unit compatibility and steady-state conduction. Applicability names a U.ClaimScope over the modeled systems, the use interval, selected CHR:ReferencePlane = conceptual for these model-side connector claims, and the steady-state conduction condition; a component port is a modeled participant or locus, not a CHR:ReferencePlane value.

One equation-based model can realize that declaration for simulation use. The modeled heater and pipe remain physical systems. Solver work, validation measurements, and a connection diagram remain work, evidence, and representation under their own patterns.

Practical payoff: another model can be compared against the same operation and law declaration without treating equation order, solver choice, or a diagram as mechanism identity.

#Clinical work: dose-adjustment operations

A clinical team declares a dose-adjustment mechanism over one common patient subject and one common dose-value domain. The headline fields and the heterogeneous operation positions connect as follows; every named ValueKind must already resolve under the effective reference scheme, and this example admits no new U-kind.

Admission conditions state which measurements and qualification intervals make one calculation admissible. Applicability names the patient-population U.ClaimScope, qualification interval, selected CHR:ReferencePlane (normally world for the patient-side use claim), and clinical conditions under which the declaration is used.

An exact claim-bearing clinical-protocol episteme is a U.MethodDescription only when it describes one admitted U.Method and satisfies A.3.2; its publication form and carrier remain separate. One clinician's treatment occurrence is work only when the A.15.1 occurrence basis obtains. Exact laboratory measurement values may be bound as arguments of one admitted calculation application, while the measurement and evidence relations that warrant their use remain separate. The returned dose-range binding does not say that the calculation produced or constituted the patient, prescription, or result episteme. None of those neighboring values becomes the mechanism episteme.

Practical payoff: a changed protocol presentation or one anomalous treatment does not silently rewrite the declared calculation laws.

#Manufacturing: fixture selection

A machining team declares a fixture-selection mechanism. Its operations filter candidate fixtures, compare admissible loading envelopes, and return a non-dominated candidate set. Laws preserve units and the partial order over constraints. The admission predicate evaluates true only when current workpiece geometry, machine envelope, and measurement qualification interval are available.

The machinist's setup method and the dated setup work remain separate. A fixture is a system. A selector implementation may realize the mechanism for a stated scope and interval.

Positive realization in plain terms. FixtureSelectorRuntime-12-E3 realizes exact mechanism episteme FixtureSelectionMechanism-E3 for Cell7FixtureSelection-Q3 during [2026-07-01T08:00Z, 2026-07-19T14:32Z). During that interval the independently identified runtime provided filterCandidates, compareLoadingEnvelopes, and returnNonDominatedSet; every admitted use required current workpiece geometry, the current machine envelope, and a current measurement-qualification interval; and its results preserved the declared unit and constraint-partial-order laws.

This replay needs one occurrence distinguished from its failing successor, so its identity is <FixtureSelectionMechanism-E3, FixtureSelectorRuntime-12-E3, Cell7FixtureSelection-Q3, [2026-07-01T08:00Z, 2026-07-19T14:32Z)>. The interval is derived, not a fourth writable participant.

Nearest failing variant. FixtureSelectorRuntime-12-FastPath-E4 : U.System exposes the same three operation names but accepts a loading-envelope comparison when MeasurementQualificationCurrent is false. It therefore bypasses one declared admission condition and does not realize FixtureSelectionMechanism-E3 for that scope, even if its returned candidate set happens to match E3 in one run. A missing audit-log segment for E3 instead reopens evidence and warrant under A.10. Without demonstrated cessation or bypass, that gap does not make the world-side realization predicate false or split its occurrence, although the project may have to withhold its positive assertion until warrant recovers. Demonstrated cessation followed by later restored conformity would create a later maximal-continuous realization occurrence.

Practical payoff: the team can replace the implementation without turning a scalar convenience score into the declared ordering law, and it can reject a look-alike implementation without rewriting the declaration.

#FPF scope and normalization declarations

A.2.6 scope operations and A.19 normalization operations may use the U.Mechanism declaration shape when their direct patterns need reusable operations, laws, admission conditions, and typed results. A.2.6 and A.19 retain their domain semantics. A.6.1 supplies the declaration and realization distinctions; it does not redefine scope or comparison.

Practical payoff: shared mechanism form does not create a second governing locus for scope or normalization meaning.

#Publication operations

E.24.PUB may cite a mechanism declaration for operations that assemble, validate, and expose a publication package. The mechanism episteme declares those operations, laws, and admission conditions. The dated publication work, resulting publication use, information carrier, evidence, and currentness relations remain with their direct patterns.

Practical payoff: reusable publication-operation semantics do not turn a released package or its carrier into the mechanism.

#Reduced ordinary use

An engineer states, "this conversion is admitted only for values in the calibrated interval." No later claim reuses an operation family, compares declarations, identifies an actual application, or refers to a realization occurrence. The direct sentence and its governing characteristic and measurement patterns are enough. No mechanism episteme is opened.

Practical payoff: precision grows only when a receiving use needs reusable mechanism identity or an exact application binding.

#Recognition evaluation: Pump #37

A project repeatedly evaluates the A.1 holon-recognition criterion. In ordinary language, one bounded evaluation act applies the selected criterion to Pump #37 and returns true, false, or unknown. For this replay, resolving HolonRecognitionMechanism-E1_Ref under its effective reference scheme returns exact mechanism episteme HolonRecognitionMechanism-E1; neither label nor suffix establishes an edition relation. That episteme has SubjectKind = U.Entity, RangedValueKind = RecognitionJudgmentValue, no separate ResultKind, and operation recognizeAdmittedHolonCandidate.

The operation declares these meanings:

RecognitionJudgmentValue is one local finite U.Kind under C.3, used here as the operation's RangedValueKind; its membership rule admits exactly the three values shown. It is not a public U-kind, universal claim-status algebra, candidate state, evidence status, episteme-currentness value, or receiving-work disposition. The argument and result rows are A.6.1 declarations, not A.6.5 SlotSpecs.

For this exact mechanism episteme, the declaration-local designation, cardinality, and binding predicates are:

These predicate names are local to HolonRecognitionMechanism-E1; they do not admit public binding relation kinds. Pump_37_Ref can be type-correct without a binding: the candidate predicate is current only when the exact application actually uses its resolved referent under the candidate meaning. The same rule applies to each argument, and a result predicate is current only after the application returns that value.

For this mechanism episteme, ApplicationPredicate(P) holds only when bounded evaluation act P fixes exactly one value for every required argument above, applies recognizeAdmittedHolonCandidate from HolonRecognitionMechanism-E1, and returns exactly one RecognitionJudgmentValue. Its ApplicationExtentRule sets the maximal extent from the moment all required argument bindings are fixed and evaluation begins through the terminal judgment return. Its ApplicationIdentityRule reidentifies one application by <HolonRecognitionMechanism-E1, recognizeAdmittedHolonCandidate, independently grounded evaluation-act locus, maximal application extent>. A later invocation is another application even with the same bound values. A trace token or reused work label can designate an act but cannot merge the two.

For the worked case, Pump37RecognitionApplication-2026-07-21T100000Z designates the evaluation act that began at 10:00:00 and returned at 10:00:04. It used Pump_37_Ref -> Pump_37 : U.Entity, admitted kind U.System, A1-Holons-Criterion-E1_Ref, Pump37-Construction-Facts-E1_Ref, Pump37-Reidentification-Rule-E1_Ref, and Pump37-Interpretation-Basis-E1_Ref. The six argument-binding predicates have maximal continuous extents from 10:00:00 through the terminal return. A required fastening-relation fact could not be resolved during this act, so the bound values could determine neither satisfaction nor failure. The act returned unknown; the extent of recognitionJudgmentReturned(Pump37RecognitionApplication-2026-07-21T100000Z, unknown) is the terminal return event at 10:00:04 and does not begin earlier. The application did occur; Pump #37's world-side satisfaction or failure did not change; and unknown is not an admission refusal.

If the project also claims that dated classification Work occurred, first recover the exact actual performer S : U.System through A.13 and let A.15.1 independently admit a separate Work occurrence W from its performance history, temporal extent, at least one obtaining enactsMethod -> U.Method relation, and at least one obtaining locally declared containing-system relation with its exact boundary. Add the same obtaining A.13 assignment RA and F.6 performedUnderAssignment(W, RA) only when this classification-work claim or its receiving use expressly consumes precise assignment-bound attribution; then check S = RA.HolderSystemSlot and assignment coverage. F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves W intact. The candidate application binding above can establish Pump #37's participation in the application; add a separate work-to-candidate or resource-use claim only when its declared predicate obtains, and add workContinuityPolicyRef only when an identity or segmentation question needs it. Any materialized classification-assertion or evaluation-result episteme remains under C.2.1. Evidence and assurance support or warrant its claim content through their own relations, and G.11 tests edition currentness. The result binding alone establishes none of Work, evidence, warrant, episteme identity, world-side criterion satisfaction, or B.2 whole reidentification.

Practical payoff: another evaluation can reuse the same typed operation while binding another candidate or basis, and evidence loss can change the returned value to unknown without rewriting the candidate or criterion.

#Bias-Annotation

Scope declaration: Universal across FPF-governed domains.

• Gov. Favors one direct governing declaration for operation meaning. Counter-risk: every operation becomes a mechanism card. Mitigation: use the progressive-explicitness threshold.
• Arch. Favors separate declaration, realization, method, work, and publication relations. Counter-risk: too many linked objects. Mitigation: materialize only objects whose identity or obtaining is asserted or used as a premise.
• Onto-Epist. Favors U.Mechanism as declaration episteme and preserves the direct kind of its subject and realizer. Counter-risk: the familiar word mechanism is overread as a machine part. Mitigation: the early object-and-relation guide and heterogeneous cases expose the distinction.
• Prag. Favors explicit argument and result declarations, application rules, laws, admission conditions, and applicability. Counter-risk: formal apparatus outruns value. Mitigation: ordinary direct statements remain admissible, and an actual binding opens only when a downstream claim asserts which value participated or was returned.
• Did. Favors a short mantra and concrete cases. Counter-risk: readers treat imperative recall as execution order. Mitigation: apply A.22.CGUS only to an independently identified potential-continuation structure and keep actual Work or Transformation separate.

#Conformance Checklist

1. Exact episteme. One U.Mechanism episteme and its exact EntityOfConcernRef are recoverable.
2. Identity. Content, EntityOfConcern, and effective U.ReferenceScheme remain recoverable.
3. Signature dependence and family-level anchors. The mechanism uses A.6.0 signature content and adds operation and admission semantics without becoming a second root beside U.Episteme. One truthful family-level SubjectKind and RangedValueKind pair is connected to the exact argument or result meanings that realize those declarations; optional ResultKind is present only for one distinct family-level result kind. Additional operation-local ValueKinds remain local. If no common pair exists, split the declaration or stop instead of using a union or generic input or output list.
4. Typed operation declarations. Every reused operation has declaration-local argument and result meanings, exact ValueKinds, binding designation rules, and semantic cardinalities when needed. None is an A.6.5 SlotSpec.
5. Application semantics. Every claimed particular application has an exact application predicate, identity rule, extent rule, and recoverable occurrence boundary.
6. Actual bindings. Every claimed actual argument or returned result has an obtaining declaration-local binding with the exact application and bound value; type compatibility, description, plan, record, or token match is insufficient.
7. Binding identity. The application, exact mechanism episteme, operation designator, argument or result designator, bound value, and maximal continuous binding extent distinguish the binding occurrence.
8. Recognition result. A recognition-evaluation declaration uses true | false | unknown with the A.1 meanings; unknown is not false, a candidate state, evidence status, currentness, or receiving disposition.
9. Law and admission split. Reusable laws, proposed-application admission predicates, and the operation's own returned value remain distinct.
10. Exact applicability. U.ClaimScope, time, selected CHR:ReferencePlane when current, and mechanism-specific conditions replace generic context wording.
11. Optional structure. A model-use structure is cited only when its selected relations delimit or change the receiving mechanism use; it does not replace the effective reference scheme or claim scope.
12. Dependency truth. SignatureManifest content names actual imports and provided names only when dependency replay matters.
13. Realization relation. A realizer keeps its direct kind; the direct relation declares its participants, obtaining predicate, and maximal-continuous-interval identity rule.
14. Evaluation and evidence boundary. Evidence availability can change evaluation or warrant without changing world-side satisfaction; an argument binding establishes use, not truth or warrant.
15. Method and work boundary. Method, method description, work plan, dated work, actual application, and binding remain separately identifiable. A.6.1 defines neither dated-work identity nor work mereology.
16. Result boundary. A result binding neither produces nor constitutes its bound entity and does not materialize a C.2.1 result episteme.
17. Mechanism comparison claims. Every refinement, conservative-extension, or equivalence claim names exact endpoint mechanism epistemes, reference schemes, scope, predicate, and preserved and changed content. Historical continuation is stated only through a separately obtaining C.2.1 EpistemeEditionRelation; a comparison or shared label supplies none. The claim uses an already admitted direct relation, the applicable A.6.RCD branch, or the exact missing-governor stop. Generic mechanism transport is absent; exact cross-context SchemeSenseCell correspondence requires F.9.
18. Mathematical-lens boundary. Quotient, product, morphism, operand order, and tuple claims use C.29 when mathematical structure preservation is current.
19. Progressive explicitness. One-off direct use is not forced into a mechanism declaration or application-binding apparatus.
20. CGUS boundary. Mnemonic imperatives are not called an executable sequence; condition-governed continuation uses A.22.CGUS.
21. Changed object. Declaration, application, binding, realization, evaluation, evidence, work, representation, and publication changes return to the object that actually changed.

#Common Failure Modes and Repairs

#Consequences

Benefits.

• Mechanism declarations can remain stable while realizers and work change.
• Physical, clinical, manufacturing, epistemic, and software cases use one declaration discipline without one domain becoming the default ontology.
• Admission, evaluation, and evidence claims become independently inspectable.
• Independently governed cross-reference-scheme, cross-CHR:ReferencePlane, and cross-model-use comparisons expose preserved and lost meaning without one generic transport relation.
• A reader can stop at a direct sentence when durable mechanism identity has no receiving use.

Costs and trade-offs.

• Authors recover the declared subject, effective reference scheme, and exact applicability rather than relying on one context label.
• A realization claim may need a separate relation and evidence-use statement.
• Mechanism comparison may require explicit mappings among operation argument and result declarations and a C.29 lens.
• Some familiar single-score or implicit-latest practices become unusable until their scale, scorer, or time policy is stated.

#Rationale

U.Mechanism earns a dependent durable name because many later patterns rely on one reusable declaration of operations, laws, admission predicates, and applicability. Treating that declaration as only a table format loses identity. Treating it as the realizing system or method makes every implementation change look like a law change.

The declaration uses the U.Signature identity and content settlement because its reusable vocabulary, laws, applicability, and dependencies have the same episteme discipline. It remains a separate dependent U-kind because operation algebra and admission semantics create recurring action-facing claims that an ordinary signature does not govern. This dependence does not assert a C.3 subkind relation by itself.

The actual application and each binding are separate because the stable declaration can be reused with different actual values, and the same value can participate under different declaration-local meanings. Exact application and binding predicates, extents, and identities prevent a plan, description, reference, compatible type, or result record from fabricating participation. They also avoid one universal work-input or work-result relation.

The realization relation is separate because several entities can realize the same declaration and one entity can realize it only for a bounded scope and interval. Evidence can change without changing that world-side or semantic relation. This keeps mechanism evolution local and makes failure diagnosis practical.

Progressive explicitness serves didactic primacy. The pattern begins with a readable engineering question and a mantra, then introduces typed content only when reuse requires it. The mantra improves recall; A.22.CGUS enters only for an independently identified structure of potential continuations, while an enabled continuation, Work occurrence, and actual Transformation remain separate values.

#SoTA-Echoing

Review this pattern when stronger work changes the distinction among operation declaration, law, admission predicate, realization, evaluation, and evidence; when A.6.0 or C.2.1 changes episteme identity; or when physical-modeling and effect-semantics practice reveals a mechanism claim that this content cannot express without kind collapse.

#Relations

• Builds on: A.6.0, C.2.1, and A.2.6.
• Governs: reusable U.Mechanism declaration epistemes, their mechanism-specific content, declaration-local application and binding semantics, exact particular operation applications and bindings when current, and direct realization claims.
• Coordinates with: A.6.REL for occurrence identity; A.6.RCD for compound comparison claims and missing-relation stops; A.6.5 for RelationSignature SlotSpec discipline; C.3 for operation ValueKinds; A.1 for recognition criteria; A.3.1 and A.3.2 for Method and Method description; A.15.2 and A.15.1 for planned and performed Work; C.2.1 for mechanism epistemes, editions, result epistemes, and bounded Bridge-use claims; A.19 for comparison; F.9 for cross-scheme sense correspondence; A.10 for ordinary reliance; B.3 only for an actual named assurance claim; CHR for selected reference planes; A.1.1 and A.22 for selected model-use structure; C.29 for mathematical-lens use; E.20 for introduction; E.24.PUB for publication; A.22.CGUS for potential-continuation structure and case results; and G.11 for currentness.
• Described and published through: C.2.1, A.6.3, A.6.3.RT, and E.24.PUB.
• Uses for precision restoration: E.10, E.10.ARCH, and F.18 after the current object and relation positions have been recovered.

#Transformation-flow use

When E.18.1 reaches a mechanism question, A.6.1 supplies the reusable operation declaration and any current exact application, application binding, or realization relation. E.18.1 carries that governed object to the next locus; it does not define mechanism semantics, bind an actual value, choose a method, identify performed work, evaluate evidence, or pass a gate.

When selected relations and applied constraints connect signature, mechanism, method, Work, and evaluation constituents into one independently identified A.22 structure with local loci and at least two potential continuations, apply A.22.CGUS to that structure. A presentation of one traversal through a qualified CGUS is a separate demonstrative slice. The local mechanism mantra remains Plain mnemonic wording unless that wider structure actually qualifies and the later presentation is about it.

#Lowering and return conditions

Lower or withdraw a U.Mechanism identification when the text cannot recover an exact declared operation family, typed argument and result meanings, application rules, laws, admission conditions, and Applicability. Lower an actual application or binding when its declaration-local predicate, participants, extent, or identity cannot be recovered. Lower a realization claim when the entity does not preserve a declared law for admitted use or the claimed scope and interval cannot be recovered.

Return to the smallest changed object:

• changed declaration content, EntityOfConcern, or effective reference scheme requires A.6.1 and identifies another mechanism episteme; call it a continuing edition only when the separate C.2.1 EpistemeEditionRelation obtains, otherwise treat it as a non-continuing replacement;
• exact cross-context SchemeSenseCell correspondence requires F.9; a selected CHR:ReferencePlane change requires CHR, and a model-use-structure change requires A.1.1/A.22. An asserted transition or use relation must name its predicate and participants or stop; none becomes a generic mechanism-transport claim;
• a particular application or binding returns to its exact declaration-local predicate, extent, and identity rules; if they cannot govern the claimed actual use, retain the exact missing-governor blocker rather than widen A.6.1 into a universal work-participant relation;
• realizer capability or realization scope returns to the direct realization relation;
• evaluation and evidence currentness require their exact predicates and G.11 when currentness is the claim;
• method and work changes require A.3.1, A.15.2, or A.15.1;
• representation and publication changes require A.6.3, A.6.3.RT, or E.24.PUB;
• a changed governing-definition assignment requires E.20.

#A.6.1:End

#Effect-free episteme morphing

Status: Stable Type: Definitional pattern

One-line summary. Effect-free episteme morphing (EFEM) is a local mathematical discipline for law-constrained arrows between exact epistemes. It compares what the source and receiving epistemes say, what they concern, and the schemes that make their claims interpretable, then states the allowed ClaimGraph difference. If its rule needs grounding, representation, conformance, or another separately obtaining relation, it names and reads that occurrence without changing it. The declaration, arrow, use claim, operation application, and performed Work remain distinct.

Use this pattern when a project needs to state and reuse a law-constrained mathematical relation between two exact epistemes while keeping that arrow distinct from a claim that it suits one use, an operation application, publication, and performed Work.

What goes wrong if missed. A view, retargeting, refinement, representation change, publication rendering, mechanism application, or work occurrence is treated as the same operation, so the project can no longer tell whether the EntityOfConcern changed or only the episteme changed.

What this buys. EFEM gives one law-constrained episteme-to-episteme morphism discipline with explicit preserve/retarget mode, clear boundaries among actual values, declaration-local participant meanings, and references, plus conservativity and composition conditions.

Placement. After A.6.1 U.Mechanism and before the A.6.3 epistemic-viewing and A.6.4 EntityOfConcern-retargeting branches.

Builds on. A.6.0 U.Signature for subject, vocabulary, laws, and applicability; A.6.1 U.Mechanism; A.6.5 for declaration-local SlotSpecs; C.2.1 for U.Episteme identity and direct constitution, empirical-grounding, and edition relations; E.10.D2 for the EntityOfConcern, Description-episteme, describing-use, and specification-use boundary; and C.3 plus F.9 for kind-level and exact cross-local reasoning.

Used by. A.6.3 epistemic viewing; A.6.4 EntityOfConcern retargeting; E.17.0 multi-view describing; E.17 (MVPK); and E.18 structural reinterpretation over transformation-flow structure.

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

Object settlement. EFEM and EpMorphism are local mathematical classes under C.29, not admitted durable U-kinds. U.Episteme is reused from C.2.1. An A.6.0 FormalSubstrate signature that declares EFEM vocabulary and laws is a separate episteme; one arrow, one use-specific assertion about that arrow, any operation application, performed Work, and publication remain separate objects under their direct governors.

#Problem frame

FPF repeatedly needs to relate one exact episteme to another, often alongside a separately described operation that produced the receiving episteme:

• 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;
• relating an analysis about one subsystem to an analysis about another, with a separate claim about invariant, visible loss, bounded use, conditions, support, and polarity.

All of these can be described by episteme-to-episteme mathematical arrows. The arrow relates exact epistemes and states its laws; it does not itself change an episteme, measure, execute, or actuate. Any operation application and Work remain separate.

Without one reusable local discipline for such arrows:

• every family (KD‑CAL, E.18, MVPK, discipline packs) reinvent their own notion of “projection”, “reinterpretation”, or “refinement”;
• laws about which parts of the source and receiving epistemes may differ, and which grounding or reference-plane facts their rules read and compare, fragment across the spec;
• cross‑family reasoning (e.g. “this E.18 structural reinterpretation is a retargeting, not a view”) becomes brittle and ad‑hoc.

#Problem

Concretely, without EFEM:

1. No single place for “effect‑free” discipline. The laws for mathematical relations between exact epistemes are otherwise scattered or implicit; any operation application remains separate.

2. EntityOfConcern behaviour is unclear. Some arrow families have endpoint epistemes about the same EntityOfConcern; others have endpoints about independently different entities. Without a common EntityOfConcernChangeMode discipline, a relation that looks like a harmless representation change can hide a different receiving EntityOfConcern.

3. No functorial backbone. MVPK, KD‑CAL, and E.18 all rely on episteme arrows that compose and respect identities, but the conditions for identity, composition, purity, conservativity, formal domain, and any arrow-family repeat law are not formulated once and reused. Different parts of the spec repeat subtly different sets of laws.

4. Slot/Ref confusion. C.2.1 identifies an episteme through exact claim content, one exact EntityOfConcern, and one effective ReferenceScheme. A.6.5 SlotSpecs apply only inside an exact reusable relation declaration. Laws for projection or retargeting that rely on unnamed fields or tuple positions therefore hide which parts of the source and receiving epistemes are being compared and which separately obtaining facts the rule reads.

The result: engineers and tool builders can no longer tell whether a mathematical relation keeps the same EntityOfConcern, identifies a different receiving one, or merely accompanies an operation. When the endpoints concern different entities, they also need a separate claim saying whether the arrow supports one receiving use, with its invariant, visible loss, conditions, support, and polarity.

#Forces

• Epistemic purity vs operational power. Effect-free episteme arrows are useful because their laws can be reasoned about algebraically and composed. If a use needs I/O, solver calls, measurements, or another effect, identify the operation application and Work separately instead of giving that activity to the arrow.

• Preserve vs retarget. A viewing arrow has endpoint epistemes with the same EntityOfConcern; a retargeting arrow has independently different ones. A separate A.6.4 use assertion states the invariant, visible loss, receiving use, conditions, support, and polarity.

• Conservativity vs usefulness. EFEM should be conservative: no new commitments about the EntityOfConcern beyond what input epistemes already entail. The receiving ClaimGraph may factor, aggregate, normalize, or re-express source content and may use a different representation when the loss and interpretation rule are explicit. Any operation or Work that produces that receiving episteme remains separate.

• Locality vs reference planes and Bridges. Epistemes are interpreted on reference planes (C.2.1). When a use relates two exact source-local senses, test the direct F.9 predicate and cite a Bridge only when it obtains; state the bounded-use claim and any reliance separately. When a use crosses a ReferencePlane, cite its applicable plane relation. EFEM cannot hide either relation inside a “pure” content rewrite, and a local-sense or plane difference alone creates neither one.

• EntityOfConcern and Description-episteme boundary and specification-use refinement. The EntityOfConcern is not identical to the Description episteme produced by this use; it may itself be U.Episteme when an episteme is under concern. ...Description names a Description episteme, and ...Spec names one admitted for specification use only when its claims are checkable and the named harness or validation relation can test them. EFEM compares what the two epistemes say, what they concern, and their effective schemes; it states what remains the same and what differs. When grounding or a describing-use viewpoint matters, name the exact relation occurrence or use qualification on each side and compare its facts. The arrow neither changes that occurrence nor establishes viewpoint selection or conformance (A.7, E.10.D2).

#Solution — define one local arrow discipline

#Informal definition

Definition. An effect-free episteme morphism is a local mathematical arrow f : X -> Y between two exact epistemes. Under its selected formal substrate, it states how claim content, the EntityOfConcern, and any material reference or representation scheme correspond. The arrow itself performs no Work, runs no mechanism, and creates no episteme.

This is a local mathematical class under C.29, not an admitted durable U-kind. The pattern keeps the short name EFEM for that class. A reusable A.6.0 FormalSubstrate signature may declare its vocabulary and P0-P5 laws, but that signature episteme is not the class and is not one arrow.

An arrow in this class:

• has exact domain and codomain epistemes identified under C.2.1;
• is effect-free: no Work, mechanism application, system change, or carrier mutation follows from the arrow;
• states the exact conservativity rule it claims;
• obeys the declared identity and composition laws; and
• declares the local two-value characteristic EntityOfConcernChangeMode as preserve or retarget.