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

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

#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 governing 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, governingPatternRef or authoritySourceRef, or work or reliance consequence, or where evidence, gate, duty, assurance, work occurrence, P2W class, admissible work, or admissible reliance would otherwise remain ambiguous. For a local first-pass repair, an equivalent L/A/D/E-classified claim set may be a two-to-four-row scratch table. Use a persistent Claim Register when the claim set is reused, published, audited, release-bearing, cross-context, or relied on by A.15, A.10, B.3, A.21, A.20, A.2.8, A.2.8.PER, A.2.9, or A.15.1. Do not atomize ordinary modifiers when one governingPatternRef or authoritySourceRef and one work or reliance consequence are already clear.

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

Common neighboring-pattern mistakes. If the real object is still cue preservation or an early unresolved cue, use A.16 or A.16.1; if a qualified relation, quality term, or action invitation is itself being repaired, apply A.6.P, C.16.Q, or A.6.A; if duties, commitments, promise content, work effects, and evidence are being mixed into one contract sentence, split them through A.6.B and A.6.C rather than minting one more 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 direct owner 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 direct owner. 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 owner. 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, assign that exact claim ID or selected A6-AW-* branch to the accountable boundary or source maintainer. Keep only cue use, source-finding, or a bounded reversible probe until the source is exposed or repaired.

Role 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. An accountable duty to enforce the gate is a separate D-* claim referencing the A-* ID.

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; the word and owner family decide nothing.

3. Contract talk category errors. “The interface promises…” is a metaphor. A.2.3 owns promise content; A.2.9 owns the instituting speech-act Work; A.2.8 and A.2.8.PER own the commitment or grant; A.15.1 owns only 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 exact actual occurrence first: use U.Work only when role-method-work facts obtain; use A.3/A.3.4 or the exact interaction or causal owner 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, or role-assignment commitments into “laws”.

#Forces

#Solution — A stack + a classification matrix

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

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

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

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

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

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

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

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

3. Deontic layer (D: duties, commitments, and grants). Put here an accountable duty, recommendation-as-duty, prohibition, commitment, or A6-AW-NORM-GRANT claim. Cite the exact A.2.8 or A.2.8.PER object selected by that row; 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/evidence claim family. Each claim names the exact actual occurrence or evaluated finding under its direct owner and, when reliance is current, the observation conditions and A.10 evidence path. U.Work is named only when role-method-work grounding obtains; a natural, spontaneous, or formal transformation may instead use A.3/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 when A.15.1's performer, assignment, method, time, and containing-system facts obtain. A Work occurrence may participate in change, production, speech-act effect, evaluation, or evidence production, but each of those remains a separately governed relation or claim. A.3/A.3.4 also admits 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 direct owner 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 → accountable duties, recommendations-as-duty, prohibitions, commitments, and A6-AW-NORM-GRANT claims at their exact A.2.8 or A.2.8.PER owner
• 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, and role obligations to maintain admissibility are expressed as D-* duties referencing A-* and E-* by ID when needed.

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

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

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

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

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

• Modality family: truth-conditional 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) → accountable 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 roles (e.g., “MUST” + a gate predicate + an effect claim), it is not classifiable as a single statement. Per A.6.B, split it into atomic claims so each one has exactly one quadrant (and, ideally, an identifier you can reference).

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

1. Split the sentence into atomic claims (one logical role each).
2. Assign each claim to exactly one quadrant (L/A/D/E) using the matrix.
3. Place each claim into its correct section or publication form (stack layer + section).
4. Anchor A.7: name what each claim is about. For permission-looking wording, bind the direct object and participants required by the selected A6-AW-* row; the owner family 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 accountable subject or direct object named by a D claim; for permission-looking wording, perform only the action required by the selected A6-AW-* 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 direct owner when the classified statement is used beyond boundary wording; the selected A6-AW-* row names the permission-side owner;
• 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 accountable provider or operator commits to maintain or enforce A-API-1 under the named window and exclusions.
• E-API-1 (Quadrant E): rollback success is evidenced only by the named work traces, audit records, or metrics; a gate decision carrier can support gate passage, but not rollback execution by itself.

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 owner model 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 direct owner; 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 (deontic commitment relation; U.Commitment, A.2.8): what an accountable role assignment, U.Role, or admitted acting system is obligated, recommended-as-duty, or prohibited to do (often: to satisfy a promise content).
• 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 exact dated Work occurrence happened, with its performer system, covering assignment, enacted method, extent, and containing system. 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 accountable duties or 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 (accountable 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 subject-owned transfer relation; 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 into (A) a gate predicate (A-*), (D) an enforcement duty on a role assignment, U.Role, or admitted acting system (D-* referencing the gate ID), and (E) an evidence claim (E-*) if observability matters.
• When something needs to be enforceable but is mathematical, prefer predicate blocks rather than deontic language in the L/A blocks, per E.8’s deontics vs admissibility guidance.

#Classification sanity rules (informative, concept-level)

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

• RFC keyword inside Definition, invariant, or admissibility predicate → classification error (rephrase as predicate; move obligation to D-*).
• E-* 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/causal owner. 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 no accountable role assignment or admitted acting system is named → likely misclassified deontic (rewrite as E-* behavior + D-* duty on implementers and operators).

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

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

#Tell (universal rule)

A boundary description is evolvable iff its claims are separated across the signature stack and each statement is classified 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 direct owner: dated Work only when A.15.1 grounds it, or A.3/A.3.4 and the exact interaction/causal owner 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 admitted performer system, covering assignment, enacted method, time, and containing system are grounded through A.15.1.
  • 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/causal owner. 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 (role-assignment or acting-system obligation) but should reference the same gate semantics to avoid divergence.
• “System emits AuthorizationRecord” belongs in Quadrant E (evidence via carriers).

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

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

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

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

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

• Effects and evidence: the 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 role-assignment or acting-system duties (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 returns work use or reliance use to A.15 rather than letting "allowed" or "authorized" wording decide by itself.

• Adopt, adapt, and reject stance for authority-looking boundary wording. A.6 adopts policy-as-code separation of 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 direct owner 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 with their direct owners: A.15.1 owns only a grounded dated Work occurrence; A.3/A.3.4 owns an independently identified actual transformation, including spontaneous or formal change with no Work; exact interaction, causal, production, speech-act, evaluation, evidence, and result owners carry their own claims. 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; A.15.1 owns only dated Work, and its §4.6 dispatch returns each application result, production, change, delivery/transfer, evidence, or acceptance claim to its direct owner.
• 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 direct owners. 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 (direct owner 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 a commitment, grant, or finding exist.

• In-description or in-theory: an L-* truth condition is settled by inspecting, proving, or type-validating the description; for a D-* claim, the description fixes the normative content and names the duty, commitment, or grant that the claim 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 what the boundary says; it does not make the named duty, commitment, or grant exist 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: governance conditions, obligations, commitments, and exclusions (the RFC keywords MUST, SHOULD, and MAY, “is admissible”, “is blocked”, “commits to”).

#A.6.B:1 — Problem frame

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

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

#A.6.B:2 — Problem

When authors cannot reliably answer two questions—

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

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

A boundary needs a minimal, stable classification that:

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

#A.6.B:3 — Forces

#Solution — the Boundary Norm Square

#Two independent distinctions

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

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

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

#A.6.B:4.2 — The square

Clarification (classify the claim, not its owner family).

• Classify the exact atomic claim by what its sentence states and by the conditions that let a reader decide it.
• The pattern that owns a referenced object supplies its 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 governance claims that state an accountable 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 result from another owner 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 your prose reads like “clients must satisfy the applicability”, you almost certainly want a D-* duty + an A-* gate (linked by ID) instead.

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

Canonical form. Predicate style, e.g.:

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

Prohibitions.

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

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

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

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

Intent. State one atomic governance claim: an accountable obligation, recommendation-as-duty, prohibition, commitment, publication or operational duty, or contractual commitment. When a sentence sounds permissive, use §8.4.1; only its Grant or norm row enters D. Writing the D-* sentence states the claim; it neither institutes the named duty, commitment, or grant nor establishes that it obtains or is met.

Adjudication. In-description for claim classification: the text fixes the governance content. To decide whether the named duty, commitment, or grant exists or whether actors complied, use its direct owner and inspect the required actual ground and evidence. The wording itself cannot decide either question.

Canonical form. For an obligation, recommendation-as-duty, prohibition, or commitment, name the accountable subject and use A.2.8. A permissive-looking word does not by itself select D; use the permission-word branch in §8.4.1, whose Grant or norm row supplies the different participant and ground test for a grant. Commitment examples:

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

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

• id (often the D-* claim ID),
• subject (accountable role assignment or party; never an episteme),
• modality (the exact A.2.8 DeonticModalityToken: MUST | MUST_NOT | SHOULD | SHOULD_NOT),
• scope + validityWindow,
• referents (by ID; e.g., SVC-*, L-*, A-*, E-*, MethodDescriptionRef(...)),
• optional adjudication.evidenceRefs when the commitment is meant to be auditable,
• optional source when authority or provenance matters.

Prohibitions.

• A D-* statement MUST NOT use “the system, service, interface, or specification” as the grammatical subject unless the accountable role assignment or admitted acting system is explicitly named; use A.6.C when contract, promise, utterance, or agreement-like boundary language is live.
• A D-* statement MUST NOT restate L-* or A-* predicates in new words when an ID exists; it SHOULD reference the ID.
• A D-* statement MUST NOT pretend that a duty, commitment, or grant is a law or that writing the claim makes it obtain.

A.7 EntityOfConcern binding. A D-* claim episteme concerns the exact duty, commitment, or grant named by its content; it does not substitute for that object. When permission wording is live, the branch in §8.4.1 names the direct owner 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 an owner pattern 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, and its direct owner; do not repeat that owner 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. Name the admitted system that performed any cited Work and keep its covering assignment separate; 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 direct owner 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) Duty-to-gate linkage

When governance requires someone to comply with a gate:

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

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

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

When gate decisions must be observable:

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

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

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

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

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

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

#(A/E → L) Semantic grounding linkage

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

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

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

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

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

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

This keeps governance text from accidentally redefining semantics in prose.

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

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

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

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

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

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

Normative rule (no upward dependencies).

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

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

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

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

Guidance (informative):

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

#Archetypal Grounding (Tell–Show–Show)

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

#Tell (universal rule)

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

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

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

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

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

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

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

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

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

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

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

#Goal

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

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

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

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

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

• L if the claim is truth‑conditional and adjudicable in‑description (inspection, proof or type validation, or model reasoning over declared assumptions): definitions, invariants, typing and well-formedness constraints. Guardrails: L-* MUST NOT (i) use RFC deontic keywords as operators, (ii) encode runtime entry predicates (those are A-*), or (iii) assert evidence existence or measurement outcomes (those are E-*).
• A if it is an in‑work gate predicate: what the mechanism admits at application time (“admissible iff …”). It is not a duty and MUST NOT be phrased as one. Guardrails: A-* SHOULD be written in predicate form and MUST NOT (i) use RFC deontic keywords as if it were an agent obligation, (ii) claim that evidence carriers exist (that is E-*), or (iii) assign responsibility or enforcement (that is D-*). (Do not confuse this with Signature.Applicability: applicability scopes intended meaning and intended use; it is not a runtime entry gate.)
• D if the exact atomic statement assigns an accountable duty, recommendation-as-duty, prohibition, or commitment. A permissive sentence enters D only through the Grant or norm row below. Guardrails: a duty or commitment claim names its accountable subject; a grant claim instead follows the participant and ground test in the Grant or norm row. Writing either 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 sentence is “Role SHALL measure, retain, or expose …”, classify that obligation to D, even if it is about evidence.)

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

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

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 owners; 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 owner 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 D claims to accountable role assignments or admitted acting systems and prefer ID references (no restatement of L-* / A-* content in new words).
• 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). ServiceOwner SHALL meet the latency target p95_latency < 200ms when A-API-01 holds, adjudicated per L-API-01 using the carriers and observation conditions in E-API-01. (References L-API-01 and A-API-01 by ID; does not restate them.)

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

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

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

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

#Triangle decomposition (explicit)

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

#Readable recomposition

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

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

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

#Example 2 — Mechanical engineering (fit / coaxiality)

#Draft sentence (non-conformant)

“This fit ensures coaxiality.”

#Atomize + Classify

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

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

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

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

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

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

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

#Readable recomposition

Tech bundle:

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

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

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

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Classify

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

A-PRJ-01 (Gate predicate: stage entry). For starting execution work, ExecutionAdmissible(project) holds iff required approvals are present and required prerequisites are satisfied (e.g., risk review completed, budget line exists, key roles staffed). (This is the real “may start work” 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). ProjectOwner SHALL not initiate execution unless A-PRJ-01 holds, SHALL keep the approval registry current, and SHALL retain or expose the evidence carriers referenced in E-PRJ-01. (References A-PRJ-01 and E-PRJ-01 by ID.)

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

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

#Readable recomposition

Tech bundle:

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

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

#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, covers the act, and supplies the authority ground. The act satisfies CalibrationGrantPolicy-v4 in PlantCalibrationContext and is the actual instituting Work, not a document or assignment acting in its place.

D-CAL-01 (Grant position). MaintenanceCalibrationGrant-17 : GrantedPermissionRelation@Context, instituted by CalibrationGrantAct-17—the actual speech act stated in E-CAL-01—permits beneficiary MaintenanceTechnicianRole to run CalibrationProcedure-v3 in Zone 8 during ServiceWindow-17. CalibrationGrantPolicy-v4 remains current, the grant still covers that role, 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). During the early part of ServiceWindow-17, admitted system Tech-17 performed dated CalibrationWork-17B : U.Work under obtaining assignment Tech-17@Shift-B, whose holder is Tech-17 and whose extent covers the Work. Tech-17 performed the Work; the assignment only grounds the role attribution.

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 instantiates the beneficiary role, 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 boundary author SHOULD add E-CAL-03 only when the reader needs to know whether the grant was exercised; otherwise the author stops with the separately named grant and Work rather than asserting an exercise relation by habit.

E-CAL-04 (Later non-violation finding). Admitted system ComplianceEvaluator-4 performed dated CalibrationComplianceEvaluation-17B : U.Work under covering assignment ComplianceEvaluator-4@QualityShift; that 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, even though the grant and exercise remain separately inspectable.

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-…, is applicable only under A-…, is accountable under D-…, and is adjudicated using evidence carriers E-…. Observed status or value is E-… for Γ_time=….”

#Plain register (1 paragraph)

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

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

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

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

#A.6.B:10 — Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#A.6.B:12 — Consequences

#A.6.B:13 — Rationale

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

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

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

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

Informative. Alignment notes; not normative requirements.

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

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

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

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

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

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

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

#A.6.B:15 — Relations

• Used by A.6 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 direct owner 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, role commitment, and work-and-evidence effect claim.
3. Give each atomic claim its quadrant and identifier.
4. Put the state, probe, update, or export part in the quadrant where it belongs rather than treating "quantum-like boundary" as one claim.
5. Apply A.6.P to reusable relation words; use F.18 only when recovered terms need durable names; apply A.10 to evidence; apply B.3 to assurance; apply C.16 to measurement; apply C.26.1 to any remaining probe-coupled state-reading claim.
6. Emit a Claim Register row set or equivalent L/A/D/E-classified claim set only when the sentence is decision-bearing, reusable, contested, assurance-facing, or likely to be cited across faces.

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

Useful outputs:

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

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

#A.6.B:End

#A.6.C — Contract Unpacking for Boundaries

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.6 Signature Stack & Boundary Discipline Builds on: A.6 (stack + classification intent), A.6.B (L/A/D/E), A.6.8 (RPR‑SERV) (service‑cluster polysemy unpacking), A.7 (EntityOfConcern, Description episteme, and carrier separation), A.2.3 (U.PromiseContent), A.2.8 (U.Commitment), A.2.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 govern the promise-content, speech-act, commitment, permission, work, evidence, or boundary ontology. Mint or reuse (terminology): Reuses “contract”, “SLA”, and “guarantee” as Plain-level boundary shorthand; mints Contract Bundle only as a four-question unpacking lens, not an entity kind or register-part taxonomy. The existing A.6.B Claim Register may add bundleId, optional questionRef, directObjectRef, ownerPatternRef, 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, owner, 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, disambiguate those referents through A.6.8 (RPR-SERV) while asking the four questions below. 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 owner 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 parallel Contract Bundles or rival canonical claim sets by paraphrase drift?

#A.6.C:3 — Forces

#A.6.C:4 — Solution

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

#A.6.C:4.1 — The Contract Bundle (four-question lens; every atomic claim keeps its own quadrant)

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

2. 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 direct owner'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). A.2.8 and the cited context policy decide whether a commitment obtains; A.2.8.PER and that policy decide 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 own direct owner.
   • 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 direct owner, 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?

   • When the model asserts or relies on an accountable obligation, recommendation-as-duty, or prohibition, write a separate atomic D claim whose direct object is the exact U.Commitment governed by A.2.8. The claim records the 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. A.2.8.PER ownership alone selects no quadrant.
   • Commitment-branch checklist (A.2.8 minimal structure):
     • id (stable; often the D-* claim ID),
     • subject (accountable role or party; never an episteme),
     • modality (the exact A.2.8 DeonticModalityToken: MUST | MUST_NOT | SHOULD | SHOULD_NOT),
     • scope (U.ClaimScope) and validityWindow (U.QualificationWindow),
     • referents (by reference or ID: promise content IDs like SVC-*, plus L-*, A-*, MethodDescriptionRef(...), or PromiseContentRef(...) as needed),
     • optional owedTo (beneficiary or counterparty),
     • optional adjudication.evidenceRefs when the commitment is meant to be auditable (point to E-*),
     • optional source when authority or provenance matters (issuer + instituting speechActRef + description reference),
     • optional notes for explicitly informative commentary (not part of the binding).
   • 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”: utterance descriptions carry the statement, but the binding is the U.Commitment object (A.7 and A.2.8).

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

   • Work: A.15.1 owns one exact dated W : U.Work with performer system, covering assignment, enacted method, extent, and containing system. 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 already governed WorkResultRelation, A.15.PROD production branch, A.3.4 change, evaluation result, subject-owned 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 “MUST, SHALL, or commits to …” statements as D (D-*), preferably as U.Commitment payloads (A.2.8).
  • 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; do not let its owner family choose the quadrant.
  • If compliance requires satisfying or enforcing a gate, the commitment MUST reference the relevant A-* ID(s) (D→A).
  • If the commitment is meant to be auditable, include evidence hooks by referencing E-* (D→E), preferably via U.Commitment.adjudication.evidenceRefs.
• Performed Work → 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 direct owner for the returned value, production, change, evaluation result, delivery/transfer, or acceptance claim.
• 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/E-classified claim set, BCP-14 keywords are statement operators, not ontology or quadrant selectors. MUST, MUST NOT, SHOULD, and SHOULD NOT enter D only for an accountable duty, recommendation-as-duty, or prohibition. MAY, OPTIONAL, and authority-looking synonyms trigger the A.6 A6-AW-* branch: a current norm/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, owner, or quadrant)
• directObjectRef (the exact U.EntityRef(...), or the canonical claim ID when the row's direct object is itself a claim)
• ownerPatternRef (the exact pattern ID that owns that direct object)
• 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 Contract Bundle record or a Permission, Utterance, WorkEvidence, or result/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 direct owner.
3. What governance or permission-looking claim exists? Record the accountable commitment or selected A6-AW-* claim with its own participants, source, and quadrant.
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, owner, 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: client implementers are obligated to satisfy the gate; provider implementers are accountable for the idempotency behavior as defined in L when the gate holds; provider commits to the availability target (scoped by window and exclusions). (Name the committing role; do not say “the API commits”.)
• E: evidence expectations: audit and log carriers include request id, idempotency key, rejection reason; availability measurement uses defined window and signal definition.

(B) Hardware interface boundary

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

Unpack + classify:

• 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: manufacturer or integrator obligations: implement handshake; enforce voltage constraints.
• E: evidence: test-report carriers; measurement traces; observable negotiation logs (if exposed), or lab measurements under a declared method.

(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: ReleaseAuthoritySystem, an admitted U.System, performs dated Approve occurrence SA-4711 under exact obtaining grantor assignment RoleAssignmentRef(ReleaseGrantor-A). That assignment's HolderSystemSlot names ReleaseAuthoritySystem; the assignment supplies role and authority but does not perform the act. Under current ReleaseGrantPolicy, 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): the grant's beneficiary participant is RoleAssignmentRef(Operator-A), held for this window by admitted operator U.System DeploymentAgent-A; its permitted-action participant is U.EpistemeRef(Deploy-Release-4711). SA-4711, RoleAssignmentRef(ReleaseGrantor-A), policy, context, scope, and window remain ground or qualifiers. The model may use this D claim only while those A.2.8.PER conditions make PER-4711 obtain and the row cites that exact 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): admitted operator U.System DeploymentAgent-A must first perform dated U.Work occurrence DeployRun-4711 under RoleAssignmentRef(Operator-A). That assignment must cover the Work, and 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.EntityRef(PER-4711). The assignment grounds the performance and beneficiary match; it does not perform the Work. 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 subject-owned delivery/transfer relation. 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: obligations on implementers or operators: implement the protocol; do not send messages outside the allowed state machine; publish conformance records if required.
• E: evidence: message trace carriers, conformance test-run records, and audit trails for disputed interactions.

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

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

Unpack + classify:

• Promise content (service promise clause): responsiveness promise for a defined incident class and window.
• 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: provider commitment to meet the target; client duties (e.g., provide required info); auditor duties if applicable.
• E: evidence: ticket carriers, timestamps, classification records, and the measurement procedure binding “4 hours” to a time window and clock source.

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

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

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

#A.6.C:7 — Conformance Checklist

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

1. CC‑A.6.C‑1 (Four questions, atomic answers). If contract-language appears, the text SHALL answer the four questions only with atomic claims. Speech act, description/publication, commitment or selected permission-side claim, dated Work, each consequence, and each evidence claim SHALL retain its own direct object, owner, 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, or documents. Any duty or commitment SHALL name an accountable role assignment, U.Role, or admitted acting system.

3. CC‑A.6.C‑3 (Classify contract-language statements via A.6.B). Contract-language statements SHALL be 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. Unqualified head‑noun service (and the co‑moving cluster service provider and server) in normative boundary prose SHALL be unpacked per A.6.8 (RPR‑SERV).

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

6. CC‑A.6.C‑6 (No second contracts via faces). MVPK faces MUST NOT add 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 direct owner's obtaining conditions 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, instituting act and policy, participants, scope/window, and current evidence required by that use; the row does not create the relation.

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

#A.6.C:9 — Consequences

Benefits

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

Trade-offs and mitigations

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

#A.6.C:10 — Rationale

FPF already distinguishes signatures, mechanisms, dated Work, separately governed 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 result or delivery owner.

#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: accountable norms and current grants enter D, entry predicates enter A, and 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 viewpoints governing projections; A.6.C applies this to contract talk to avoid face-level semantic forks.

#A.6.C:12 — Relations

• Uses and is used by

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

• Coordinates with

  • A.7 (EntityOfConcern, Description episteme, and carrier) for correct placement of evidence claims.
  • 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 owners.
  • 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 owner membership 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 work must tell one obtaining relation occurrence from another occurrence of the same relation. With Robot-7 holds InspectorRole, a report that only says who currently holds the role can keep that direct sentence and stop. A history or comparison that must tell the second assignment episode from the first, even with the same Robot-7 and InspectorRole, 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 direct owner's participant meanings and obtaining predicate only as far as needed to state that relation accurately. The owner 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 direct owner'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 the direct owner has not defined the participant meanings, applicability, and obtaining predicate, return to that owner 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 claim governor; 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 receiving 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 operation-application assertion episteme whose content designates it as an argument under an A.6.1 OperationAlgebra SlotSpec.

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 holds InspectorRole 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
  GoverningPatternRef: 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 governing 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 direct governing 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 governing 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 operation-application assertion episteme that designates the occurrence as an argument under an A.6.1 OperationAlgebra SlotSpec. 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 holds InspectorRole answers no. A history or comparison that must distinguish a second assignment episode from the first, despite the same holder and role, 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 direct owner. 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 return to the exact direct claim pattern 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 direct owner'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 governing 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 designate the occurrence as an argument in the operation-application assertion episteme according to the A.6.1 SlotSpec.

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 the constructing system, its constructor role assignment, the enacted constructor method, input entities, performed construction work, 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 direct installed-part pattern 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 work must distinguish this occurrence from another occurrence of the same relation. A report that only states the current Robot-7 / InspectorRole assignment stops there. A history or comparison that must distinguish a later assignment episode with the same holder and role opens the 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

#Admitted repeated role assignment through the relation-object architecture

Start with Robot-7 holds InspectorRole, interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A, and trace only the objects needed by the current use.

1. World-side participants and occurrence. Robot-7 remains an admitted U.System; InspectorRole remains a U.Role value; MaintenanceRoles-2026 remains the exact role-taxonomy episteme; and Maintenance-Scheme-A remains the effective U.ReferenceScheme. Under A.2.1, those are the four actual participants of one U.RoleAssignment occurrence.
2. Direct settlement. A.2.1 supplies the four participant meanings, the obtaining predicate, and the same-versus-new-occurrence rule. The occurrence continues while that predicate obtains without interruption for the same four participants. A demonstrated non-assignment gap ends it; later resumption starts another occurrence. An evidence gap by itself does neither.
3. Reusable declaration. For typed reuse, the RelationSignature for U.RoleAssignment contains HolderSystemSlot : U.System / U.EntityRef, RoleValueSlot : U.Role / ByValue, RoleTaxonomyEpistemeSlot : U.Episteme / U.EpistemeRef, and EffectiveReferenceSchemeSlot : U.ReferenceScheme / ByValue. AssignmentInterval remains assertion or occurrence-description content, not a fifth participant SlotSpec.
4. Assertion and participant designations. A RoleAssignmentAssertion contains designations corresponding to those four SlotSpecs and states the currently known assignmentInterval separately. Its claim may say that Robot-7 currently holds InspectorRole. If later work only needs that current report, keep the assertion and stop without naming the occurrence.
5. Occurrence identity, designator, and reference. Suppose the same four participants occur in two inspection shifts separated by a demonstrated non-assignment period. A history or work-attribution claim applies the A.2.1 continuity rule, distinguishes the second occurrence, and may designate that occurrence. A roster row identifier, copied field set, or reused source key cannot collapse 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 direct owner could make installation work or a continuous installation interval identity-bearing, but A.6.REL does not choose that ontology. Until such an owner 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 U.RoleAssignment occurrence from 5.1.

1. An assignment-occurrence description episteme E1 has R1 as its EntityOfConcern. In the C.2.1 declaration, the entity-of-concern relation-participant meaning corresponds to EntityOfConcernSlot. 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 relation-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 own EntityOfConcernSlot designation resolves to E1, not to R1. 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 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 direct governing 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 direct owner 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 direct governing 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; every direct relation and representation owner supplies its own. In U.RoleAssignment, A.2.1 uses uninterrupted obtaining and a demonstrated 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 holder and role value can stand in two A.2.1 assignments separated by demonstrated non-assignment. The same component and whole may belong to distinct part-relation episodes only if their accepted direct owner 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. Their role here is ontological comparison, 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 returns with 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.
• A.2.1 governs role-assignment obtaining and identity; F.6 governs later attribution to performed work.
• A.14 and exact direct mereology patterns govern 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 dispatches an unsettled ontic candidate only after those exits are recoverable; none replaces 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 governing 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. When such executable continuation is current, its object is a Constraint-Governed Unfolding Structure (CGUS) governed by A.22.CGUS.

#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 direct owner; 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 holds InspectorRole as interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A.

This is an A.2.1 assignment assertion about the already admitted U.RoleAssignment relation kind. A.2.1 defines the direct assignment predicate and occurrence-identity rule; the actual assignment history for Robot-7 and Shift-17 determines whether the predicate is satisfied. When several patterns need to reuse the four participant meanings, predicate, and identity rule, the A.2.1 RelationSignature becomes useful: its A.6.5 SlotSpecs declare those meanings for typed assertion and F.6 work-attribution reuse. When another claim needs to refer to this particular assignment episode, A.6.REL governs 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

A.6.5 governs these declarations of participant meanings. Use the exact A.2.1 SlotKind names for this admitted example: HolderSystemSlot, RoleValueSlot, RoleTaxonomyEpistemeSlot, and EffectiveReferenceSchemeSlot. They expose the four participant distinctions without making the assignment interval, a selected model-use structure, or performed work into another participant. 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 roles: 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 roles:

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 govern 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 its claim crosses a context or effective reference scheme, use the exact F.9 bridge and state what is preserved and lost. 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.

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

The rows name the direct patterns that govern these common adjacent objects and claims. Their co-location is only a compact representation and does not change any governing 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 the A.2.1 assignment predicate holds for the named holder, role, taxonomy episteme, and reference scheme during the named episode. For example, During Shift-17, Robot-7 holds InspectorRole as interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A is a complete current assignment assertion. State an affirmative or negative claim under A.2.1, or an exact governed modal claim when that family is current. The A.2.1 predicate defines the test; the actual assignment history decides the case. 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 that must interpret HolderSystemSlot, RoleValueSlot, RoleTaxonomyEpistemeSlot, EffectiveReferenceSchemeSlot, and the same A.2.1 assignment predicate can cite one RelationSignature. 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. A claim about condition-dependent entries, branches, returns, or stops is a CGUS claim governed by A.22.CGUS.

#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 the frame's claim is carried into another context or reference scheme, name the F.9 bridge occurrence and its preservation and loss before using the claim there. 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 direct owner, 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 return to 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 owners; operation admission remains under A.6.1, and a gate-passage verdict remains under A.21/C.11. If a laboratory measurement scheme is used in a plant-model scheme, F.9 must name the bridge and the preservation or loss of sign convention, unit, and boundary interpretation.

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 holds InspectorRole as interpreted by MaintenanceRoles-2026 under Maintenance-Scheme-A is enough for a task that only reports whether the A.2.1 assignment predicate holds for those participants during that episode. Stop there. If a staffing assertion and an F.6 work-attribution consumer must reuse the same four participant meanings and assignment laws, cite the existing A.2.1 RelationSignature. If later work attribution or history must refer to this assignment and distinguish it 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: A.22.CGUS governs any claimed executable conditional continuation.
• Context transport. A signature's claims mean only what their stated scope and effective reference scheme make them mean. Counter-risk: the same label in another context is treated as equivalent or safely substitutable. Mitigation: before cross-context or cross-scheme reuse, apply F.9 to name the local senses, Bridge kind and direction, declared loss, and admitted use; without that result, 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, unit-and-scale owners and A.19.CPM/A.19.UNM comparison and normalization owners as the case requires, then state the resulting comparison boundary; keep their detailed legality and result-shape rules with those owners.
• 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, owner, 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 governs 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 direct owners, 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 governs 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:

• Modelica Association, Connectors and Connections.
• 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 owns 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 form of a needed comparison claim, A.6.5 only for the contrasting RelationSignature SlotSpec discipline, C.3 for local operation ValueKinds, A.1 for holon-recognition semantics, A.3.1 for methods, A.15.1 for performed work, F.9 only for exact cross-context SchemeSenseCell correspondence, C.2.1 for the separate claim that one obtaining Bridge suits one named bounded use, A.10 for ordinary below-threshold evidence reliance on that claim, B.3 when an assurance claim is made or its material-reliance threshold is met, 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 executable continuation structure, 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 those family-level roles, 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 routes each question to 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 does not create an executable sequence. When condition-governed continuation is current, A.22.CGUS governs that structure.

Grammar does not classify the object. Plain recall wording remains a mnemonic aid. A prescribed order of performed work belongs to the direct method-description or work-plan pattern. A condition-governed executable sequence is admitted as a CGUS; when a presentation selects one traversal through that admitted CGUS, it is a separate DemonstrativeUnfoldingSlice@Context whose EntityOfConcern is the CGUS.

#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 governing 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 governs 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 carries each current family-level role; 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/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:

• when the receiver makes no assurance claim and the use does not meet B.3's material-reliance threshold, use A.10. Name the exact current evidence-provenance relation, this bounded use, the unsupported stronger use, its window, and the reopen or stop condition; proceed only with RelianceDisposition=pass for this bounded use;
• when the receiver makes an assurance claim or the threshold is met, enter B.3 and first ask whether a current assurance claim exists. A met threshold requires the minimum reliance safety assurance record and its accountable contest boundary, but it creates no positive claim. Proceed only when a positive current assurance claim with a sufficient record carries this bounded assurance use; otherwise state the no-assurance-claim or insufficient-record disposition and narrow or stop the use.

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 B.3 supplies no positive current assurance claim with a sufficient record for an assurance-bearing 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 returns to CHR; a changed BoundedModelUseStructure returns to A.1.1/A.22. 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 admitted under U.Work by A.15.1. When a work claim also relies on one already identified application and its bindings, identify the Work occurrence independently. Name the admitted performer System S and the obtaining assignment RA; verify that S = RA.HolderSystemSlot, that RA covers the attributed Work extent, and that F.6 performedUnderAssignment(W, RA) obtains. State the Work temporal extent and the actual enactsMethod -> U.Method and executedWithin -> U.System relations. Add a work-to-referent relation, performed resource use, continuity policy, or work mereology only when the claim asserts that relation and its own predicate obtains. A.6.1 does not identify the Work occurrence. If neither an exact direct subject relation nor a truthful A.6.1 application binding governs a claimed actual participant, 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 method description may cite a mechanism declaration. An independently governed selector result or one actual A.6.1 application may select a method, and an exact 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 an exact method value. Neither the declaration nor binding establishes a planned assignment, actual enactsMethod, or dated work occurrence. One exact 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, while performer assignment, extent, containing system, resources, affected referent, continuity, and neighboring result or effect claims remain separately governed.

#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, exact revision work, source use, method semantics, and change facts satisfy C.2.1's edition-continuity predicate. 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, use one exact F.9 Bridge and infer neither mechanism identity nor equivalence from it. A changed effective reference scheme identifies another episteme; changed CHR:ReferencePlane or model-use organization returns to its direct owner. 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 an executable continuation. If a use needs condition-governed entries, branches, returns, or stops, A.22.CGUS governs that structure.

#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, identify a separate Work occurrence W under A.15.1. Name the admitted System S that performed it and the obtaining assignment RA under which it performed; verify S = RA.HolderSystemSlot, assignment coverage, and F.6 performedUnderAssignment(W, RA), then state the Work temporal extent and the actual enactsMethod -> U.Method and executedWithin -> U.System relations. 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 governs 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: A.22.CGUS alone governs condition-governed executable continuation.

#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 carry those roles; 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/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 owns 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 returns to 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; CGUS remains the exact object for executable conditional continuation.

#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 explicit occurrence identity; A.6.RCD for local compound comparison claims, reusable predicate definitions, and relation-kind admission stops; A.6.5 for the contrasting RelationSignature SlotSpec boundary; C.3 for local operation ValueKinds; A.1 for recognition-criterion semantics; 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-episteme identity, editions, any separately materialized result episteme, and the separate claim that one obtaining Bridge suits one named bounded use; A.19 for comparison; F.9 only for exact cross-context SchemeSenseCell correspondence; A.10 for ordinary below-threshold evidence reliance on the separate bounded-use claim; B.3 when an assurance claim is made or the material-reliance threshold is met; CHR for selected CHR:ReferencePlane values; 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 executable continuation; 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 typed signature, mechanism, method, work, and evaluation positions are connected by condition-governed relations, admit the resulting executable continuation structure under A.22.CGUS. A presentation of one traversal through that admitted CGUS is a separate demonstrative slice. The local mechanism mantra remains Plain mnemonic wording unless that wider structure and slice have been admitted.

#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 returns to 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 returns to F.9; a selected CHR:ReferencePlane change returns to CHR, and a model-use-structure change returns to 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 return to their direct patterns and G.11 when currentness is the claim;
• method and work changes return to A.3.1, A.15.2, or A.15.1;
• representation and publication changes return to A.6.3, A.6.3.RT, or E.24.PUB;
• a changed governing-definition assignment returns to E.20.

#A.6.1:End

#U.EffectFreeEpistemicMorphing — Effect‑free morphisms of epistemes

Status: Stable Type: Definitional ontic pattern

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

Use this pattern when a project needs to transform an episteme into another episteme while preserving the distinction between episteme-only change, EntityOfConcern retargeting, publication rendering, mechanism application, 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, slot/ref boundaries, conservativity, and composition conditions.

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

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

Used by. A.6.3 U.EpistemicViewing; A.6.4 U.EpistemicRetargeting; E.17.0 U.MultiViewDescribing; E.17 (MVPK); E.18 (structural reinterpretation over transformation-flow structure).

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

Body-level U-kind settlement. U.EffectFreeEpistemicMorphing is the governed durable value in this pattern. U.Episteme is reused from C.2.1; episteme species such as episteme card, view, and publication are dependent episteme or publication values only when C.2.1/E.17 governs them. ClaimGraph, ReferenceScheme, Viewpoint, and related names are ValueKinds or SlotKinds inside the C.2.1 episteme slot relation and A.6.5 SlotSpec discipline. SubjectRef is source wiring that decodes through DescriptionContext; it is not a second EntityOfConcern ontology. EpMorphism below is the local mathematical-lens arrow value for the episteme category, not a root U-kind. Claims about performed work, mechanism application, or presentation carriers leave EFEM and use A.15, A.6.1, E.17, or the direct publication pattern.

#Problem frame

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

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

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

Without a universal pattern for such morphisms:

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

#Problem

Concretely, without EFEM:

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

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

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

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

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

#Forces

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

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

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

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

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

#Solution — define U.EffectFreeEpistemicMorphing once

#Informal definition

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

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

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

Specialisations:

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

#Signature Block (A.6.0 alignment)

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

SubjectBlock

SubjectBlock
  SubjectKind   = U.EffectFreeEpistemicMorphing
  RangedValueKind = ⟨X : U.Episteme, Y : U.Episteme⟩        // episteme pair (domain,codomain)
  Quantification= SliceSet:=ContextSliceSet;
  ExtentRule:=admissibleEpistemeMorphisms // Context slices & admissible EFEM per slice
  ResultKind?   = EpMorphism                               // local typed arrow f : X->Y in the Ep category

This says: EFEM is “about” morphisms between epistemes, indexed by Context slices; its results are local EpMorphism arrow values in the Ep category.

Vocabulary (core operators & kinds)

• Types

  • U.Episteme (as holon; realised via species U.EpistemeCard, U.EpistemeView, U.EpistemePublication under C.2.1).
  • U.EpistemeKind (episteme n‑ary relation signature; slots per A.6.5 / C.2.1).
  • SubjectRef (source wiring name only; for Description epistemes, including Description epistemes admitted for specification use, it decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ per C.2.1 §6.1 / E.10.D2). It does not define another EntityOfConcern family.
  • EpMorphism (local arrow value in Ep, governed by this morphism pattern and C.29 when the mathematical lens is current).
  • U.EntityOfConcernChangeMode = {preserve, retarget} (enumeration; no new durable U-kind named “EntityOfConcern”).

• Operators (arrow algebra)

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