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

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

#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: Classify and Place Boundary Claims

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: A.6.B for claim classification, A.6.0 and A.6.1 for declaration boundaries, A.7 for subject/description/carrier distinctions, and E.17.0/E.17 for view membership and publication. 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).

Local terminology: “Signature Stack”, “Boundary Discipline Matrix”, and “Claim Register” name authoring aids. L/A/D/E classify statements; they are not MVPK face designators or 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 are read as permissions, permissions as duties, evidence as gate passage, and publication faces as the governed boundary object.

What this buys. The project gets an L/A/D/E-classified claim set with source references and stack placement. Material dependencies name the source claim by ID or canonical location, so work, reliance, evidence, commitment, and gate uses can return to their subject patterns; publication faces cite the same claims.

First output. One or more atomic L/A/D/E-classified claims, with stack placement and references for material dependencies.

Boundary-claim activation discipline. Use only as much claim-classification structure as the live work claim or reliance claim requires. Split a statement only where one sentence carries more than one claim kind, relationFunctionClaimRef or authoritySourceRef, or work or reliance consequence, or where evidence, gate, duty, assurance, work occurrence, P2W class, admissible work, or admissible reliance would otherwise remain ambiguous. For a local first-pass repair, ordinary atomic prose suffices; a two-to-four-row scratch table may help. Use a persistent Claim Register when stable claim references are needed for reuse, publication, audit, release, cross-context use, or reliance by A.15, A.10, B.3, A.21, A.20, A.2.8, A.2.8.PER, A.2.9, or A.15.1. Do not atomize ordinary modifiers when one relationFunctionClaimRef or authoritySourceRef and one work or reliance consequence are already clear.

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

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

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

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

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

When agreement-like wording leaves an ambiguity that changes interpretation or use, 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 action or reliance, return to the exact governing claim. Use A.15.4 while appearance hides the required prerequisite; use A.15 when the question is enactment alignment.

Credential-currentness boundary. Use A.10 to determine which claims a displayed credential's source and evidence support for the bounded use. Recover issuer, holder, verifier, status and currentness where they matter. Treat the display as A6-AW-SOURCE; move to another row only when that row's direct object and ground are independently present.

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

Conflicting-source boundary. When a classified boundary claim disagrees with its governing source or a display, resolve the source order, decision source, freshness policy and supersession rule. Until then, keep cue use or source-finding available; allow a bounded reversible probe only on its own adequate basis, without relying on the unsupported claim.

Boundary and source repair assignment. If the split exposes a missing claim or source, give the claim ID or canonical location, or the selected A6-AW-* branch to the identified boundary or source maintainer. Keep cue use or source-finding available. A bounded reversible probe needs its own adequate basis; the missing source still blocks the unsupported Work or reliance use.

Recurring boundary ambiguity repair. If the same wording repeatedly needs the same split, repair the boundary package: replace the misleading label, identify the L/A/D/E claims by ID or canonical location, 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 identify the relevant L/A/D/E claims by ID or canonical location and the source for the selected A6-AW-* branch. If it cannot, keep the wording at A6-AW-SOURCE or repair the boundary package.

For an incident-learning use, record the displayed phrase, intended Work or reliance use, unsupported claim or effect, missing or ambiguous L/A/D/E claim ID or canonical location, required source, plausible overread, safe disposition and upstream repair. Retain source, currentness and supersession references only where they change that case.

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 cite the canonical claim ID or location. Face prose may explain or faithfully paraphrase the claim without creating another specification. 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 designator. 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 GateDecisionResult, GateCheckApplicationResult, optional GateCheckRef, optional DecisionLog, or proof that a gate passed. An A-* claim may name conditions consumed by a later A.21 profile application; actual passage is a separate E-* claim about the exact GateDecisionResult. An A.20 ConstraintValidity witness remains separate from the predicate, each check application, and the gate result.

Claim Register (informative, recommended). When a Claim Register is useful, use the mini-record in A.6.B:7. It can record stack placement (Signature, Mechanism, Norms, and Evidence) and the face designators that cite each claim. Add viewRef/viewpointRef only when the corresponding episteme identities matter. Mechanical checks can test ID resolution and exact text copying; inspect meaning for paraphrase drift.

#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 reusable operation declaration with OperationAlgebra, LawSet, AdmissibilityConditions and Applicability.
• Multi-view describing through E.17.0 MultiViewDescribing, plus separate E.17 publication discipline for selected epistemes, face uses, forms, and carriers.
• Recover each claim's EntityOfConcern separately from its claim-bearing Description episteme and any publication carrier. The concern may itself be an episteme or carrier; its position does not establish agency, Work, evidence, or a 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 a publication form for a bounded reader/use. PlainView, TechCard, InteropCard, and AssuranceLane are face designators, not additional publication-face kind values. A face may expose an episteme that independently has U.View membership; the form, rendering and carrier remain separate from that episteme.

#Problem

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

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

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

3. Contract talk category errors. If “the interface promises…” leaves a consequential ambiguity about the claim or its participant, use A.6.C to recover it before treating the wording as an agency error. Use A.2.3 for promise content, A.2.9 for the instituting speech-act Work, A.2.8 and A.2.8.PER for the commitment or grant, and A.15.1 only to identify the dated Work occurrence. An application result, production, delivery/transfer, acceptance, and evidence use each follows its own row in A.15.1:4.6 and is omitted when that claim is absent. F.18 only names recovered terms when durable naming is current.

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

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

#Forces

#Solution — A stack + a classification matrix

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

This pattern uses stack in the same pragmatic sense as other FPF stacks (e.g., the holonic import stack and other layered disciplines): an ordered set of layers where higher layers are more stable commitments, and lower layers are more volatile realizations and evidence. “Higher” and “lower” provide 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).

The Signature Stack (as used in this cluster) is the ordered family of canonical claim layers for a boundary package. Each of the four claim layers below 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 U.Signature through the operation declarations, LawSet, AdmissibilityConditions and Applicability governed by A.6.1. Its admission predicates remain declaration content. Evidence-interface declarations and transport details keep their own claim classification; use A.10 for evidence sources and carriers, and name carrier-producing Work only when that occurrence is claimed.

   Audit vs AssuranceLane (avoid duplication): a boundary's local Audit and observability section states its evidence-interface declarations: carrier classes and required fields, correlation keys, and exposure interface. Mechanism.AuditObservability below is a local publication-section locator, not an A.6.1 content component. Retention, access, and enforcement are D-claims. A general prescription remains a claim-bearing episteme; one obtaining individual duty cites the exact A.2.8 U.Commitment, its actual bearer, and its direct predicate. A system-role kind or assignment may be an applicability ground but is neither bearer nor commitment. An MVPK AssuranceLane is a publication face for auditors that explains how to adjudicate the evidence interface. Under CC-A.6.6, the AssuranceLane face references those evidence-interface declarations and relevant claim IDs or canonical locations; its explanation preserves their semantics.

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

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

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

6. Publication faces. MVPK selects exact epistemes and publication forms for audience-specific face uses. A selected episteme has U.View membership only when E.17.0 conformance to the exact viewpoint episteme obtains; any A.6.3 source-to-receiving construction remains separate. The face designator, 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 using examples from observability practice: 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.

#AssuranceLane skeleton (informative)

An MVPK AssuranceLane is a publication face that teaches a specific audience how to adjudicate E-* claims against the relevant evidence carriers, including those produced in Work. It cites the boundary's evidence-interface declarations and explains them without changing their semantics.

Minimal content (suggested):

• Scope: boundaryRef, version; viewRef and viewpointRef when view or viewpoint identity matters.
• 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 any new boundary claim first enters its canonical source. A changed permission-looking claim cites its selected A6-AW-* row and subject pattern rather than being introduced inside the face.

Example (conceptual; uses view/viewpoint identity and the additional hypothetical header case in §4.2):

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 request lacking header X (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]

The absence condition also covers a request that was not rejected. A claim of complete coverage requires the relevant request population to be accounted for separately from individual query joins.

Default placements (quadrant → stack layer / section):

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

Related subject rules (informative):

• 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: for an E-* claim used for reliance, recover the A.10 evidence-provenance path and bounded use. A missing path narrows or blocks only the unsupported use. Open B.3 only for an actual named assurance claim about an exact target and assurance use.
• A.2.3 and F.12 ↔ D/E separation: a U.PromiseContent promise is not evidence; promise acceptance is linked to Work evidence via F.12. A general duty remains normative content, while an obtaining individual duty is one A.2.8 U.Commitment borne by an actual System or other admitted party. Any system-role kind or assignment used to establish applicability stays separate. D-* claims reference A-* and E-* claims by ID or canonical location 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.

The 2×2 matrix crosses two independent distinctions:

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

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

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

Atomicity rule:

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

Micro‑template: Atomize → Classify → Place → Identify EntityOfConcern → Register when useful

1. Split the sentence into atomic claims, one logical job each.
2. Assign each claim to exactly one quadrant (L/A/D/E) using the matrix.
3. Place each claim into its correct section or publication form (stack layer + section).
4. Anchor A.7: name what each claim is about, separately from the episteme carrying it. Add publication and carrier relations when they change interpretation. For permission-looking wording, bind the direct object and participants required by the selected A6-AW-* row; the selected subject pattern or kind of direct object never supplies the quadrant.
5. Register when useful: add the atomic claim to the Claim Register if used. Downstream faces cite the claim by ID or canonical location and preserve its meaning in any explanation.

Action outputs after classification:

• implement or repair an admissibility predicate when the claim being made is A-*;
• repair the exact normative source for a generic D claim, the actual duty bearer and A.2.8 result for an individual D claim, or the direct object named by the selected permission row;
• recover the exact actual occurrence, evaluated finding, or evidence path named by an E claim; use the selected E-side A6-AW-* row when permission wording is current;
• publish or update an MVPK face that cites L/A/D/E claims by ID or canonical location and explains them faithfully where its readers need prose;
• reopen the exact subject pattern when the classified statement is used beyond boundary wording; the selected A6-AW-* row names the permission-side subject pattern;
• downgrade the visible wording to cue use or source-finding only when the exact source is missing;
• narrow the unsupported Work or reliance claim; allow a local or reversible use only on its own adequate basis and stated stop condition, or block the unsupported use while its 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.”

Recovered source clauses:

• “Clients MUST include header X.”
• “If a request lacks header X, the request is invalid.”
• “If a request lacks header X, the system logs NotAdmissible.”

Recover the intended invalidity/admissibility meaning before fully classifying the second clause. The third clause states a generic logging rule; it reports no particular observed request.

Additional hypothetical illustration. Suppose a separate boundary policy defines invalidity here as failure of the entry condition below and adds an implementer duty to the quoted Clients duty. Also suppose the observation stated in E-OBS-1 actually occurred in this hypothetical case:

• A-AC-1 (Quadrant A, Mechanism.AdmissibilityConditions): hasHeader(req, "X") is a necessary entry condition.
• D-CL-1 (Quadrant D, Norms-and-commitments): “Client implementers MUST include header X in each request to this boundary (A-AC-1).”
• E-OBS-1 (Quadrant E, Evidence-and-carriers): “For the selected request req lacking header X (A-AC-1), the system logged NotAdmissible; the observer recovered its AuditLogEntry{code="NotAdmissible"} in the audit stream.” The carrier schema is an additional illustrative choice. Logging depends on the absence of X, including when the request was not actually rejected.

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

Recovered source clauses:

• “The service guarantees 99.9% availability per calendar month.”
• “The service MUST keep p95 latency under 200ms.”
• “Breaches are penalized.”
• “Operators SHALL alert on violations.”

Recover the guarantee's meaning and bearer, the measurement and acceptance basis, and the breach trigger, penalty and applicable parties. Use A.6.C for the unresolved contract meanings and A.6.B to classify the resulting atoms. The split alone does not settle them.

Additional hypothetical illustration. Suppose a separate policy identifies Provider and the service being measured, states the exclusions and workload W, defines the availability and latency metrics, and sets the two criteria evaluated below. In addition to the quoted alert duty, it requires paging within 5 minutes. The following E-claims assume that the stated evaluations and observation actually occurred in this hypothetical case; the alert observation concerns a separate violation case.

• D-SLA-1 (Quadrant D, Commitments and SLA): “Provider SHALL meet the availability and latency criteria evaluated by E-SLA-AVAIL-1 and E-SLA-LAT-1 under the stated exclusions.”
• E-SLA-AVAIL-1 (Quadrant E, Evidence-and-carriers): “The evaluation of the observed calendar month T reported availability ≥ 0.999, with measurements recorded in carrier UptimeProbeSeries from viewpoint VP.ExternalMonitor.”
• E-SLA-LAT-1 (Quadrant E, Evidence-and-carriers): “The evaluation under workload W reported latency_p95 < 200ms, with measurements recorded in carrier LatencyMetricSeries from viewpoint VP.Client.”
• D-OPS-ALERT-1 (Quadrant D, Ops duty): “Operators MUST page on breach of the criteria evaluated by E-SLA-AVAIL-1 or E-SLA-LAT-1 within 5 minutes (additional policy).”
• E-ALERT-1 (Quadrant E, Evidence-and-carriers): “In the separate violation case, the operator's page was observed in carrier AlertEvent{ruleId,firedAt,target} and can be joined via incidentId.”

These added policy and observation premises do not resolve the original guarantee, duty bearer or penalty clause.

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 separate authority wording from the evidence, assurance, commitment, gate-passage, or Work claim being made.

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

Recovered source clauses:

• “This API is approved for production use.”
• “This API guarantees safe rollback.”

Recover the approval's direct object and ground under the applicable A6-AW-* row, and the rollback subject and safety predicate. Both source claims remain unresolved until that meaning is supplied.

Additional hypothetical illustration. Assume supplied signature vocabulary defines the API operation and rollback terms; a separate boundary policy gives the request-admission predicate, policy window and exclusions. For E-API-1, additionally assume that a named evaluation of an independently identified rollback occurrence actually reported success under a stated success criterion and observation basis:

• L-API-1 (Quadrant L): the API operation and rollback terms are defined in the supplied signature vocabulary.
• A-API-1 (Quadrant A): a request is admissible only under the named subject, action, object, context, and policy-version predicate.
• D-API-1 (Quadrant D): the exact provider policy prescribes maintaining or enforcing A-API-1 under the named window and exclusions. If the claim is instead that one actual provider or operator bears this duty, cite its separately instituted A.2.8 commitment.
• E-API-1 (Quadrant E): the named evaluation reported rollback success under its stated success criterion. Possible evidence inputs include the named work traces, audit records, or metrics. A gate decision carrier may support the exact gate-passage claim; rollback execution needs its own occurrence and evidence basis.

In this additional case, A-API-1 applies A6-AW-GATE, while an approval badge remains A6-AW-SOURCE unless another row's closing facts are present. The original production approval and safe-rollback guarantee remain unresolved. A success result alone does not establish the unspecified safety claim.

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.

Then:

• if appearance hides the prerequisite for action or reliance, enter A.15.4; use A.15 for enactment alignment;
• if evidence, currentness, or provenance is live, attach the A.10 evidence relation;
• if an actual named assurance claim is current, use B.3 for its exact target claim, argument, bounded assurance use and AssuranceResult; otherwise keep trust, readiness, compliance or release questions with their direct patterns;
• if an actual gate decision or passage is asserted, classify it as a separate E claim and cite the exact A.21 GateDecisionResult, bounded action, applicable GateProfile application, complete required GateCheckApplicationResult set, decisionValue, action consequence, scope/window, and recheck condition; use a short GateCheckRef only for a selected publication structure and a DecisionLog only when audit or reuse is current;
• if a flow witness or constraint witness is asserted, cite A.20 ConstraintValidity status or witness;
• if a permission-looking claim is asserted, use the selected A6-AW-* row and its subject pattern; an entry predicate or GateDecisionResult 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 uses publication face designators (PlainView, TechCard, InteropCard, AssuranceLane) and their E.17 profiles. E.17:5.2 specifies the declared publication-face kind values.

A disciplined stack therefore requires:

• Every published face use identifies the selected episteme and its separate reader/use declaration. Name the exact viewpoint episteme through U.ViewpointRef when U.View membership or viewpoint identity is used; name the publication occurrence, form, and carrier when those identities change publication or reliance. The face designator 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 that preserve the source claims. Normative face prose cites the canonical L/A/D/E claim ID or location and direct object; it may faithfully paraphrase the claim. Add any new boundary claim to its canonical source before publishing it on a face. Use verbatim text when exactness is critical or disputed.
• 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 selected faces.

#“Contract” unpacking: avoid assigning agency to epistemes

When “the API contract” leaves a consequential ambiguity, use A.6.C to ask only the live questions: what was promised, what was said or instituted, what governance position obtains, and what actually happened. Use A.15.1:4.6 to separate any dated Work from the result, production, delivery/transfer, evidence, or acceptance claims actually made. Clear wording, including a semantic guarantee or recoverable ordinary metonymy, needs no unpacking record.

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

In A.6 terms:

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

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

Use A.6.C — Contract Unpacking for Boundaries for the expanded account and the same A.15.1:4.6 dispatch.

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

The A.7 primary layer field below identifies the claim's EntityOfConcern, with its kind when needed; it is not a layer selected from the quadrant. The concern may itself be a Description episteme or publication carrier and remains separate from the episteme carrying the claim.

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 combines a duty with an entry condition, split it into (A) a gate predicate (A-*) and (D) either a general prescription or a claim about one exact U.Commitment borne by an actual System or other admitted party (D-* referencing the gate by ID or canonical location). When observability matters, add an E claim only on a separate actual observation or result basis. A requirement to produce or retain logs is D; an expectation or plan supplies no actual E result. A system-role kind or assignment may establish applicability only through an independently obtaining rule; neither bears the duty.
• When something needs to be enforceable but is mathematical, prefer predicate blocks rather than deontic language in the L/A blocks, per E.8’s deontics vs admissibility guidance.

#Classification sanity rules (informative, concept-level)

These are writing diagnostics, not tool requirements.

• RFC keyword inside Definition, invariant, or admissibility predicate → classification error (rephrase as predicate; move obligation to D-*).
• E-* with no exact actual occurrence or evaluated predicate, or with a carrier but no evidence relation for the claimed use → incomplete effect/evidence claim. Ground Work through A.15.1 only when it actually obtains; otherwise use A.3/A.3.4 or the exact interaction or causal-use pattern. A carrier supports the claim but does not create the effect.
• D-* that re-states an A-*/L-* predicate instead of citing its ID or canonical location → drift risk (prefer “MUST satisfy A-…”).
• A face introduces new L/A/D/E content not present in the canonical claim set → view-fork. Recover the direct object and classify the new claim—duty/commitment/grant in D; exercise/evaluated finding/evidence in E; gate in A—then add it to its canonical source before face publication. Informative commentary may explain existing claims without adding boundary semantics.
• “The system or service SHALL …” where the phrase does not name a direct behavior claim, general prescription, or exact individual commitment with its actual bearer and constitutive basis → unresolved subject and modality. Recover the System or other party, state an actual E-* behavior claim separately only when its actual basis is supplied, and state either the normative content or the direct A.2.8 commitment. A service label, system-role kind, or assignment proves none of these claims.

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

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

#Tell (universal rule)

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

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

System: A “Payment Authorize” service.

• Signature layer (A.6.0).

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

• Mechanism layer (A.6.1).

  • Admissibility gate: request is admissible iff tokenValid ∧ merchantActive ∧ amountWithinLimit.
  • Boundary transport details: HTTP headers and idempotency-key carriage. Declare canonical currency-conversion operations under A.6.1.
  • The local Audit and observability section specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their fields, correlation IDs and retention class. Retention duties remain D-claims.

• Actual occurrence and work layer.

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

• Publication faces (MVPK).

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

Effects-and-handlers analogy. In this software example, the signature exposes the operation interface. A.6.1 governs declared operation semantics and the separate realization relation; the realizing entity supplies the concrete handler implementation. Implementations can change while preserving the declared operation meanings and applicable constraints.

Classification example:

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

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

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

• Signature layer: names operations such as Evaluate(model, dataset) → Report and states metric definitions (AUROC, calibration error) as Laws. A.6.1 governs the corresponding operation declaration and its argument/result meanings.

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

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

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

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

• Multi‑view (MVPK face designators):

  • 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.
  • AssuranceLane for auditors: evidence map (which carriers support which occurrence claims) 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

• Arch bias: Biases toward separation of concerns and explicit layering; mitigated by allowing multiple faces 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.
• Gov bias: Prefers auditable responsibility (viewpoint accountability and commitment unpacking).

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

The claims in a boundary description concern:

• 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
• actual occurrences and evidence (effects may arise through Work, natural or spontaneous transformation, formal change, or another directly governed interaction, and evidence supports but does not create them).

Mixing these claims makes it harder to distinguish a semantic boundary change from an implementation change, and to test each claim against its own rule and evidence.

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

Informative.

• Adopt — algebraic effects and handlers / effect systems. Effect systems distinguish operation signatures from handler semantics (e.g., Koka’s effect typing; effect handlers in OCaml 5). In this analogy, U.Signature carries the boundary declaration, A.6.1 governs operation declarations and their realization relation, and the realizing entity supplies the implementation. Substitution requires the declared meanings and applicability to be preserved.

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

• Adapt — categorical optics, lenses, and bidirectional transformations. 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. 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. Traces, logs and metrics can supply evidence inputs for an exact claim. Use A.10 for the evidence-provenance relation and bounded reliance.

• Adapt — Zero Trust, dynamic authorization, and policy-as-code practice. 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 uses A.15.4 while appearance hides a prerequisite for work or reliance; A.15 retains the enactment-alignment question.

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

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

#Relations

• Uses A.6.B as the classification authority: A.6.B:8.4.1 selects the job of permission wording. A.6 maps the resulting atomic claim to the stack; it does not put every A.2.8.PER object in D. The filled case in A.6.B:8.4.5.4 is the concrete handshake.
• Coordinates actual effects without merging them: Use A.15.1 only to identify a grounded dated Work occurrence; use A.3.4 for an independently identified actual transformation, including spontaneous or formal change with no Work; state each interaction, causal, production, speech-act, evaluation, evidence, or result claim through its applicable predicate and pattern. A description or carrier creates none of them.
• Constrains signature writing: Reinforces A.6.0 separation of Laws vs operational gates (AdmissibilityConditions live in mechanisms).
• Constrains mechanism writing: Uses A.6.1 for OperationAlgebra, LawSet, AdmissibilityConditions and Applicability; local transport and evidence-interface sections retain their own claim classification.
• 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: When boundary ambiguity changes interpretation or use, A.6.C applies A.2.3, A.2.8, A.2.8.PER, and A.2.9 to keep promise content, speech act, commitment or grant explicit; use A.15.1 only to identify dated Work, and its §4.6 dispatch requires the exact subject predicate for each application-result, production, change, delivery/transfer, evidence, or acceptance claim.
• Uses relation-specific declaration disciplines: use A.6.5 when an already recovered direct relation needs reusable participant typing. Use A.6.6 when basedness wording hides the dependent, base or direct predicate; stop at the ordinary assertion when it answers the receiving question.
• Coordinates with C.28 CausalUse-CAL: When boundary prose uses causal-use evidence or a causal-use verdict to justify deployment, release, duty, commitment, or admissibility, A.6 splits the boundary sentence while C.28 carries the causal-use question, CausalityLadderRung, estimand, support basis, support verdict, and supported causal use and unsupported causal use.
• Coordinates work and consequences: A.15.1 supplies only a dated U.Work occurrence. Its §4.6 table routes an application/result binding, production, change, evaluation result, evidence use, delivery/transfer, and acceptance to separate subject patterns. A.15, A.10, B.3, A.21, and A.20 govern the exact enactment-alignment, 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 the actual participants and any channel or carrier required by the boundary relation or operation separately.
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;
• an F.9 Bridge and separate bounded-use claim when the export question concerns two exact local senses and the Bridge predicate obtains; add a Bridge Card only when durable packaging is useful;
• 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: Find the Defining Episteme for a Description

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 reader first needs to recognize the description before reconstructing its full semantics: what description is seen, where it is encountered, what it applies to, what excludes it, and which definitionEpistemeRef identifies its defining U.Episteme. Reject a nearby reading or wrong defining U.Episteme only when the grounded-guard condition in §4.1 holds.

Plain recognition line. Find the defining U.Episteme for the encountered description.

Use this pattern while the reader needs to decide whether one encountered description 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 first-contact identification instead of from guesswork.

Ordinary not-this-pattern boundary:

• not when the reader's question already concerns 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 identify the encountered description before the reader can begin pattern-language comparison.

#Forces

#Solution

#Recognition-cue discipline 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, and which definitionEpistemeRef identifies its defining U.Episteme. Reject a nearby reading or wrong defining U.Episteme only when it passes F.19's grounded-guard test: the rejected reading has an independent local ground, is plausible for the intended reader, and changes truth, understanding, selection, safety, stop, reliance, or action. Use the smallest clear correction; do not invent an alternative to fill the cue shape.

Here "description-recognition signature" is a lower-case authoring and reading discipline, not by itself a typed U.Signature or a new formal kind. A typed declaration requires the applicable neighboring pattern's explicit conditions.

The encountered carrier or projection may help recognition; it does not become authoritative merely by being encountered.

Use definitionEpistemeRef for the defining U.Episteme. If the definition is available only through one publication, cite separately the exact E.24.PUB publication occurrence that makes it available; 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 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, when the grounded-guard condition in §4.1 holds.

Review-expanded shape, only when needed. When a recognition cue affects a decision or is being reviewed, 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

The nearby_false_description_or_wrong_definition_episteme field is optional: use it only when the grounded-guard condition in §4.1 holds.

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. When the grounded-guard condition in §4.1 holds, name the nearby false description or wrong defining U.Episteme to reject.
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;
• an explicit false-neighbor rejection when the grounded-guard condition in §4.1 holds;
• 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 the reader needs to classify its claims as L/A/D/E;
• method-description applicability recognition: can one reader recover whether one method description is the right description to inspect, reject, or compare for the reader's question;
• 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:

• use A.6.B when the reader needs to classify the boundary claims as L/A/D/E;
• E.17.0 tests viewpoint/view membership; E.17 publishes reader-facing forms of an already accepted engineering account; use E.24.PUB when publication occurrence, form, or carrier identity affects the recognition use;
• E.10.D2 recovers description-episteme and specification-use distinctions; use E.10 cues within F.19 for wording, A.6.P for under-specified direct relations, and F.18 for durable naming and its collision checks;
• C.16.Q repairs overloaded recognition or discoverability quality wording; C.25 applies when the quality-family claim depends on several differently typed contributors; a single-Characteristic claim stays with its direct Characteristic pattern;
• 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:

#When a neighboring pattern is needed

If the task requires a quality claim, typed signature declaration, reusable description, or publication-face rule, use the neighboring pattern that governs that object or claim, including its evidence requirements. The recognition cue alone does not establish that result.

#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 cannot tell 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 identifying which description to inspect.

Recognition repair:

First recover the defining description; the cue alone leaves its boundary claim unresolved. For the worked branch below, suppose inspection of that defining episteme establishes a request-admissibility condition. If the source instead prescribes a duty or states another boundary claim, recognize that content and apply its corresponding entry.

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 = the perspective of a 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 = an evidence/work claim or a different routed-quadrant statement mistaken for the governing admissibility description.
8. first_admissible_entry_stop_or_reroute = the reader can now say "this is the admissibility description to inspect first"; if the reader needs to classify the boundary claims, 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 deployment initiation as a guarantee of successful completion or of the whole deployment result.

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, invocation form, and the stated deployment initiation under the conditions in the defining description.
4. excludes = success, completion, rollout, or downstream effect guarantees not present in the access description itself.
5. definitionEpistemeRef = the defining episteme for the access description; inspect the specification or pattern governing downstream effect separately if that question is current.
6. first_admissible_entry_stop_or_reroute = "this is the access description to inspect first: it describes invocation of POST /deploy and deployment initiation, not guaranteed successful completion."

#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 identifying what the pairwise comparison is to determine.

Recognition repair:

With only the cue, first ask what the pairwise comparison is intended to determine. For the worked branch below, suppose the defining episteme supplies comparison under a declared comparator but no selection or publication rule. If the source also defines selection, recover and use that contribution.

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. If one of those questions is current, apply the pattern that governs it and obtain the result it requires.
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 description-recognition question 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 the conditions under which the recognition question calls for each relevant neighboring pattern in §4.4; use only the patterns that govern the current questions.
• CC-RSIG-4 No kind inflation. An ordinary recognition cue is not by itself a typed U.Signature; a task requiring a typed declaration uses the applicable neighboring pattern under §4.5.
• CC-RSIG-5 Recoverable cue shape. For load-bearing cases, description, viewpoint, cue, applicability, exclusion, defining U.Episteme, and admissible entry stop remain recoverable. A false neighbor is required only when the grounded-guard condition in §4.1 holds.
• CC-RSIG-6 No alias minting. Query cues and ordinary phrasing do not by themselves establish a naming settlement or Bridge. Use F.18 for naming settlement and F.9 for a Bridge, each under its own conditions.

#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 the boundary claims 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, and defining U.Episteme must not be collapsed; include the false neighbor when §4.1's grounded-guard condition holds. The cost stays bounded because the expanded shape is review-only or risk-triggered, not a required card for ordinary prose.

#Rationale

A.6.RSIG combines information-scent, human/AI expectation-management, controlled vocabulary, and retrieval-context practices into one description-facing discipline.

#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, when §4.1's grounded-guard condition holds, its false neighbor before relation precision or epistemic precision-restoration work begins?

#Relations

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

#A.6.RSIG:End

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

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

Use this when. Use A.6.B when boundary wording mixes definitions, runtime entry conditions, generic prescriptions, individual duties or grants, actual work or evaluation results, and evidence.

First useful move. Split the live passage into atomic claims, classify each claim by modality and adjudication position, and replace any consequential paraphrase dependency with an ID or canonical-location reference.

What changes in practice. Laws, gates, governance, and work-and-evidence claims can change without silently changing one another; publication faces reuse the canonical claims instead of restating them.

Ordinary non-use boundary. A one-off local sentence with one recoverable logical job still needs the correct quadrant, but it does not need a Claim Register or a separate publication form. Add those only when reuse, decision, audit, or cross-face citation needs them; §6.1 still requires any material dependency to name the claim by ID or canonical location.

#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 designators 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 or the canonical claim locations 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 designator. 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 designators inside this cluster; spell face designators in full to reduce collisions.

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

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

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

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

Modality family. A claim is either:

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

#A.6.B:1 — Problem frame

Boundary descriptions routinely collapse four distinct claim families into “contract soup”: definitions are written as obligations, runtime gates are hidden inside laws, governance talk is assigned to “the interface”, and operational-result “guarantees” are asserted without the actual Work, evaluation, or observation needed to settle them. The resulting boundary is brittle: substitution becomes unclear, and auditability becomes performative rather than adjudicable.

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

#A.6.B:2 — Problem

When authors cannot reliably answer two questions—

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

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

A boundary needs a minimal, stable classification that:

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

#A.6.B:3 — Forces

#Solution — the Boundary Norm Square

#Two independent distinctions

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

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

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

#A.6.B:4.2 — The square

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

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

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

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

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

The quadrants have canonical placements in the boundary stack:

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

A publication face MUST NOT introduce new semantic claims outside this L/A/D/E-classified claim set. E.17 (MVPK) enforces this rule for publication faces and their selected profiles.

#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. Identify what the L-* definition, invariant, or typing rule concerns, separately from the episteme carrying the claim. Its EntityOfConcern need not itself be a description and may be Work.

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

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

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

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

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

Canonical form. Predicate style, e.g.:

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

Prohibitions.

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

A.7 EntityOfConcern binding. An A-* claim concerns the mechanism-entry predicate: what the mechanism admits, not a client's duty to comply with it. Keep that predicate distinct from the episteme carrying the claim.

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

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

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

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

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

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

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

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

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

Prohibitions.

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

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

Required references (explicit).

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

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

Intent. State a truth-conditional result that can be settled only from actual work, evaluation, observation, or produced carriers.

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

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

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

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

Prohibitions.

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

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

Required references (explicit).

• If the result is conditioned on a gate decision, the E-* statement SHOULD reference the relevant A-* ID(s) or canonical location(s).
• If another object is needed to settle the predicate, reference that object's subject pattern without importing its quadrant.
• If evidence is used for reliance, recover the independently established support or evidence-use relation and its basis through A.10; use G.6 when an addressable provenance path is needed. Carrier presence alone is not support.

#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 or canonical location) rather than duplicated prose.

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

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

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

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

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

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

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

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

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

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

When a claim reports actual observability of a gate decision:

• E-*: “For the stated rejection or acceptance due to A-*, carrier C was produced or observed under conditions …”

This separates gate semantics (A) from the actual observation or result (E). A prescription to produce or retain a carrier belongs in D; an expectation or plan alone supplies no actual E result.

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

When governance prescribes evidence production, retention, exposure, or a measured property and a separate E-* claim states the related result:

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

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

#(A/E → L) Semantic grounding linkage

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

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

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

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

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

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

This keeps governance text from accidentally redefining semantics in prose.

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

Normative rule (decomposition). A conforming boundary text SHALL decompose any mixed sentence into its actual claim jobs. Recover the predicate and modality of an observability clause before assigning its quadrant. The triangle applies when the source states all three:

• A: admissibility predicate (A-*)
• D: generic prescription or individual-duty claim referencing the gate (D-* → A-*)
• E: actual observation or result referencing the gate, with carriers when needed (E-* → A-*)

Keep a prescription or individually instituted duty to produce evidence in D. Preserve an expectation or plan as such; leave the actual E result absent until its basis exists. This repairs mixed validity, authorization, compliance, audit, and security claims without manufacturing a third claim.

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

The square keeps laws and admissibility predicates independent of governance prose. An evidence or result claim may concern a prescription, duty, or grant, but its truth is settled by its own predicate and actual basis.

These are cross-quadrant restrictions. They do not prohibit same-quadrant references, such as L-* → L-* or E-* → E-*.

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.)
• An E-* claim MAY reference a D-* claim as its evidence target or to identify the norm, duty, or grant used by its evaluation. The E-* result MUST still satisfy its own predicate and the actual-work, evaluation, or observation requirements of §5.4; the D-* claim alone establishes no result or compliance. (E-* may also 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 or canonical location rather than restating content.

Rationale (informative). Laws (L) and admission predicates (A) retain their own meanings. Governance (D) states prescriptions, duties, and grants. Evidence and results (E) may report on those claims or evaluate conduct against them; a prescribed result is not inferred from the prescription.

#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 its ID or canonical location.
• Stack layer should be one of {Signature, Mechanism, Norms-and-commitments, Evidence-and-carriers} to make classification auditable.
• A.7 primary layer identifies the claim's EntityOfConcern, with its kind when needed. The concern may itself be a Description episteme or publication carrier; it remains distinct from the episteme carrying the claim.
• viewRef and viewpointRef are used when the corresponding view or viewpoint identity matters under E.17; U.View membership requires E.17.0 conformance.
• Use References for explicit cross‑quadrant links: for example, which D-* states a requirement or individual duty to enforce which A-* predicate, which E-* reports the result or evidence used to adjudicate which commitment, and which L-* defines a metric used by E-*. Add 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)

Decomposing every normative statement into atomic claims, classifying each under exactly one quadrant of the Boundary Norm Square, and expressing cross‑quadrant dependencies by claim ID or canonical location rather than paraphrase supports later boundary evolution and audit.

#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: admitted system EvaluationRunner-A performed MLProtocolEvaluation-T1 : U.Work over Model-M1, Dataset-D7, the pinned environment and seed policy, and evaluation window T; the exact AUROC metric application declared by the L claim returned AUROCResult-T1 with measuredAUROC=0.91. When a checker, gate, or audit decision relies on that result, an A.10 evidence-provenance path links it to exact carriers RunLog-T1, DatasetHash-D7, EvaluationReport-R1, and TraceSet-T1.

The square keeps “must use dataset vX” (D) separate from “evaluation is admissible iff dataset usage terms match” (A), and both separate from “MLProtocolEvaluation-T1 returned AUROCResult-T1(measuredAUROC=0.91)” (E). The report and log carriers may support reliance on that result; producing a carrier is not the measured result.

#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 or canonical location (no paraphrase duplication),
3. a readable recomposition (separate Tech and Plain forms when their readers need them),
4. a minimal anti-pattern lint (things we reject / flag).

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

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

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

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

Step 3 — Triangle decomposition. Recover the observability clause's predicate and modality under §6.3. Use the A/D/E triangle only when the source states an entry condition, a generic prescription or individual duty, and an actual observation or result:

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

A requirement to produce or retain evidence stays in D. Preserve an expectation or plan without inventing an actual E result.

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

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

Guideline. Keep gate semantics independent of specific evidence carriers: write the gate predicate in A-*; when an actual observation or result is stated, put it in E-* and reference 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 or canonical location, not by paraphrase. Apply the cross-quadrant restrictions in §6.4, including its explicitly informative-note exception for L references to A/D/E. Same-quadrant references remain available.

Common link motifs (informative). The most reusable boundary rewrites use D→A, E→A, D→E, A/E→L, and D→L; E→D identifies an evidence target or normative evaluation input under §6.4.

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

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

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

Step 6 — Recompose into readable text. Include only the claim classes present in the source. Use separate Tech and Plain forms when their readers need them; both may also serve as a teaching aid.

• Tech recomposition: a short L/A/D/E-classified claim bundle listing the present claims and their ID or canonical-location references.
• Plain recomposition: a one-paragraph narrative that summarizes the bundle and cites its claims (no new semantics). If you need a new constraint, add a new atomic L/A/D/E-classified claim to the canonical source before publishing it in Plain.

#Anti-pattern (quick)

• AP-1 Unestablished operational-result guarantees. An asserted operational result lacks the actual Work, evaluation, or observation needed to settle it. If the guarantee's L/A/D/E meaning is ambiguous, use A.6.C:4.3 to recover it.
• 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 or canonical location).
• 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)

The draft alone leaves open whether the author means a latency target, an obtaining duty, or an observed result, and under which measurement rule and operating conditions. With only that cue, return those questions. For the expanded worked case below, take the referenced definitions and envelope, the independently obtaining duties, and the dated evaluation and carrier-use facts as additional premises.

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

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

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

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

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

E-API-01 (Evidence / carriers). For LatencyEvaluation-T1 over Γ_time=[t1..t2], actual carriers TraceBatch-T1, Histogram-H1, DashboardSnapshot-D1, and SamplingConfiguration-S1 were produced or observed under the operating and sampling conditions in A-API-01, using the metric and computation definition in L-API-01. An A.10 evidence-provenance path links those exact carriers to LatencyEvaluation-T1 and its LatencyResult-T1. (References A-API-01 and L-API-01 for the operating conditions and metric definition.)

D-API-03 (Duty-to-evidence linkage). Admitted telemetry-maintaining system TelemetryOperations-A is the actual duty bearer of separately obtaining TelemetryRetentionCommitment-API-03 : U.Commitment; it SHALL retain or expose the actual carriers 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, LatencyEvaluation-T1 produced LatencyResult-T1 with 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.
• D-API-02 states the operational incident-note duties.
• D-API-03 states the 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): “In this expanded case, the API’s latency target uses the p95 definition in L-API-01, and the mechanism admits its evaluation only under operating envelope A-API-01. ServiceOperations-A has the latency duty stated in D-API-01. Adjudication uses the telemetry carriers listed in E-API-01; TelemetryOperations-A has the retention duty in D-API-03, and SRE-A has the incident-note duty in D-API-02. Under that envelope, the observed p95 over Γ_time=[t1..t2] was 173ms (E-API-02).”

#Example 2 — Mechanical engineering (fit / coaxiality)

#Draft sentence (non-conformant)

“This fit ensures coaxiality.”

#Atomize + Classify

First ask whether the draft concerns a geometric constraint, a process duty, or a measured result, and recover the datum, tolerance and applicable conditions. For the expanded worked case below, take the referenced definition and process envelope, the independently obtaining process and retention duties, and the dated measurement facts as additional premises.

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

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

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

D-FIT-01 (Duty). Admitted production-engineering system ProcessEngineer-A is the actual duty bearer of separately obtaining ProcessEnvelopeCommitment-FIT-01 : U.Commitment; it SHALL ensure A-FIT-01 holds for the production lot and SHALL not release the lot for use when A-FIT-01 is false. (References A-FIT-01.)

E-FIT-01 (Evidence carriers). For CoaxialityEvaluation-L123 over lot L123 and Γ_time=[t1..t2], actual carriers CMMReport-L123, CalibrationCertificate-C7, AssemblyLog-L123, TemperatureTrace-L123, and DatumSchemePin-D4 were produced or observed. An A.10 evidence-provenance path links those exact carriers to CoaxialityEvaluation-L123 and its CoaxialityResult-L123. (References A-FIT-01 and L-FIT-01; avoids RFC deontics.)

D-FIT-02 (Duty-to-evidence linkage). Admitted quality-engineering system QualityEngineer-A is the actual duty bearer of separately obtaining FitEvidenceRetentionCommitment-02 : U.Commitment; it SHALL retain or expose the carriers referenced in E-FIT-01 for the production lot. (References E-FIT-01 by ID.)

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

#Readable recomposition

Tech bundle:

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

Plain paragraph: “In this expanded case, ‘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 mechanism admits this coaxiality evaluation only under the declared manufacturing and assembly envelope (A-FIT-01). ProcessEngineer-A has the process-envelope duty stated in D-FIT-01. Compliance is adjudicated using the measurement and process carriers listed in E-FIT-01; for lot L123 over Γ_time=[t1..t2], the observed coaxiality was within tolerance E-FIT-02.”

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

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Classify

With only the draft, ask which approval is claimed, which subsequent action depends on it, and what rule and actual result support that use. For the expanded worked case below, take the named approval definition, gate profile, independently obtaining coordinator duty, four actual check-application results and evidence path as additional premises.

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

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

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

E-PRJ-01 (Gate decision result). At Γ_time=snapshot(t), ProjectEntryGateResult-P-t : GateDecisionResult has gateRef=ProjectEntryGate-P, decisionSubjectRef=ProjectEntryClaim-P-t, boundedActionRef=StartExecution-P, and profileApplicationRef=ProjectEntryProfileApplication-P-t. That application of ProjectEntryProfile-v3 uses the complete required set {ApprovalCheck-P-t, RiskReviewCheck-P-t, BudgetCheck-P-t, StaffingCheck-P-t} : GateCheckApplicationResult[]; each exact application reports its checked subject and criterion, has sourceOutcome=satisfied, and maps to pass. The result records decisionValue=pass, action consequence “start StartExecution-P within the admitted project-entry window”, the project-entry scope and window, and recheck on any changed approval, risk-review, budget, staffing, profile, scope, or window. (This actual E-* result applies the inputs named by A-PRJ-01; it is neither the A-* predicate nor performed execution Work.)

E-PRJ-02 (Evidence for reliance). For reliance on E-PRJ-01, the exact observed carrier set is {DecisionRecord-R7, MeetingMinutes-M3, BudgetLine-B4, StaffingAssignments-S2, GateChecklistSnapshot-G9}. An A.10 evidence-provenance path links those carriers to the four exact GateCheckApplicationResult values and ProjectEntryGateResult-P-t. GateChecklistSnapshot-G9 displays the result; its presence alone establishes neither a check result nor the gate decision. (References A-PRJ-01 and E-PRJ-01; avoids RFC deontics.)

#Readable recomposition

Tech bundle:

• “Approved” is not one relation: L-PRJ-01 defines approval kinds.
• “May start execution” is a gate predicate: A-PRJ-01.
• ProjectCoordinator-A's project-entry duty: D-PRJ-01.
• The actual A.21 gate result is E-PRJ-01; its bounded A.10 evidence support is E-PRJ-02.

Plain paragraph: “In this expanded case, 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 predicate (A-PRJ-01). ProjectCoordinator-A has the project-entry and registry-maintenance duties stated in D-PRJ-01. At snapshot t, the current A.21 profile application maps every required check-application result to pass; E-PRJ-01 records decisionValue=pass with the action consequence ‘start StartExecution-P within the stated window’, and E-PRJ-02 supplies the exact evidence path for reliance on that result.”

#Filled permission case (each sentence classified)

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

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

A-CAL-01 (Gate predicate). 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 predicate takes those inputs; it creates neither the grant, a conflict result, nor an actual gate decision.

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

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

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

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

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

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

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.

E-CAL-08 (Gate decision result). At the later entry check, CalibrationEntryResult-17C : GateDecisionResult has gateRef=CalibrationEntryGate-17, decisionSubjectRef=CalibrationWorkPlan-17C, boundedActionRef=StartCalibrationProcedure-v3-in-Zone8-17C, and profileApplicationRef=CalibrationEntryProfileApplication-17C. The current profile application uses the complete required set {CalibrationGrantCurrentCheck-17C, CalibrationConflictResolvedCheck-17C} : GateCheckApplicationResult[]: the current-grant application maps to pass, while the exact CalibrationConflict-17=unresolved source outcome maps to block. The result records decisionValue=block, action consequence “hold CalibrationWorkPlan-17C outside entry”, the remaining Zone 8 service scope and window, and recheck when the grant, conflict result, profile, scope, or window changes. It neither resolves the conflict nor revokes MaintenanceCalibrationGrant-17.

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 E-CAL-08 gate result remain the separately classified claims above.

#A compact recomposition aid

Include only the claim classes present in the source; use separate Tech and Plain forms when their readers need them. Cite claim IDs or canonical locations.

#Tech register (2–5 lines)

“This boundary claim is defined by L-… and applies only under A-…. D-… states either the exact generic prescription or the separately instituted duty of [actual bearer]. E-… states the observed or evaluated result for Γ_time=…; add its evidence support when the receiving use needs it.”

#Plain register (1 paragraph)

“We mean [short label] in the sense of L-…, and use it only when A-… holds. D-… either states what the named policy requires or, when an individual duty was separately instituted, names its actual bearer. E-… states the observed or evaluated result for the declared interval; add its evidence support when the receiving use needs it. If responsibility is also claimed, cite its direct relation separately.”

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

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 or canonical location.
• Gov bias: makes actual duty bearers and duties explicit (D) and auditability explicit (E); mitigated by keeping evidence conceptual and carrier-referenced rather than tool-specific. Responsibility, when claimed, remains a separate direct relation.
• Ontological and Epistemic bias: insists on EntityOfConcern, Description episteme, and carrier and on work‑adjudicated effects; mitigated by providing clear cross‑quadrant link patterns so authors can still express real‑world governance needs.

#A.6.B:10 — Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#A.6.B:12 — Consequences

#A.6.B:13 — Rationale

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

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

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

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

Informative. Alignment notes; not normative requirements.

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

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

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

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

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

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

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

#A.6.B:15 — Relations

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

#Probe-coupled boundary claim classification

When boundary text says that an interaction changes the state represented by its output, identify the interaction, the changed state, and the receiving use, then classify the atomic claims through the same L/A/D/E square. Such interactions may include asking a question, measuring or intervening through a metric, reading a dashboard, conducting a workshop, exporting through a Bridge, or making an API read. Probe-coupled boundary language does not create a fifth quadrant.

Action classification:

1. Copy the boundary sentence being used for a decision.
2. Split it into its atomic claims before judging it, retaining only the classes present in the source: definition or law, runtime admissibility, generic prescription or individual duty, work effect or evaluated result, and any separate evidence-support claim.
3. Give each atomic claim its quadrant and any identifier required by a later reference.
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. Use A.10 for needed evidence support, B.3 for a named assurance question, C.16 for measurement, and F.9 for a Bridge question. Use C.26.1 for the residual probe-coupled question only when the interaction participates in the represented state and its output is being used as a passive read or export despite that decision-relevant effect.
6. Use a Claim Register row set only when the classified claim set is decision-bearing, reusable, contested, assurance-facing, or likely to be cited across faces; otherwise keep the atomic prose.

For a local working note, atomize the sentence mentally and write one or more atomic L/A/D/E-classified sentences, preserving every source claim. One sentence suffices only when one logical job remains. Use the Claim Register when the claim set must survive reuse or dispute; the phrase "quantum-like boundary" is not a substitute for its separate claims.

Useful outputs:

• a Claim Register row set when decision, reuse, contest, assurance, or cross-face citation needs it;
• one or more atomic L/A/D/E-classified sentences preserving every source claim for a local working note;
• an ordinary A.6.B L/A/D/E-classified claim set when no probe-coupled state-reading question remains;
• the C.26.1:4.2 decision and finish result for a residual probe-coupled question that meets the activation condition above;
• the evidence-support, assurance, measurement, or Bridge result or continuation required by A.10, B.3, C.16, or F.9 for the corresponding current question.

Do not write "the boundary is quantum-like" as one claim without L/A/D/E classification. Identify the interaction and its receiving use, split and classify the claims, then apply the C.26.1 activation condition above to any remaining question.

#A.6.B:End

#A.6.C — Contract Unpacking for Boundaries

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

Use this when. Use A.6.C when words such as contract, promise, guarantee, SLA, or interface agreement leave a consequential ambiguity about what was promised, instituted, governed, performed, produced, delivered, accepted, or evidenced.

First useful move. Rewrite the live passage so each asserted object has its actual subject, predicate, operands, and direct governor; apply only the questions that the passage makes live.

What changes in practice. Familiar contract language can remain in Plain prose while technical and normative claims become classifiable under A.6.B and adjudicable through their direct sources.

Ordinary non-use boundary. Clear local contract wording with no consequential ambiguity needs no unpacking record. A one-off repair may end in the repaired atomic prose; create or extend the Claim Register only when stable reuse, decision, audit, dispute, or cross-face projection needs it.

#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 can conflate a semantic guarantee with an undertaking, attribute a dated act to its description instead of its performer, encode runtime gates as if they were internal laws, or treat observability as a property of text rather than of carriers and work. A.6 and A.6.B already provide an L/A/D/E claim-classification discipline for boundary claims, but “contract” language remains a recurring entry point for category mistakes.

Service-cluster note (modularity + lexicon). When contract talk co-moves with service, service provider, server, SLA, SLO, or service-level and a relied-on boundary use still hides a concrete subject or relation, recover that hidden choice through A.6.P:4.11a while asking the four questions below. Mere co-occurrence does not trigger recovery, and clear, quoted, historical, illustrative, or harmless ordinary wording remains usable. U.PromiseContent is written as promise content, never as bare “service”.

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

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

• define “legal contract” doctrine (offer, acceptance, consideration, jurisdictional enforceability, etc.);
• resolve conflicts across scales or contexts: keep the current grant or prohibition as its own D claim, classify the conflict finding as E through A.6 A6-AW-CONFLICT, and use the exact mediation predicate and assertion only when mediation is current;
• redefine the core meanings of U.PromiseContent, U.Work, U.SpeechAct, U.Commitment, or the exact A.2.8.PER results—it only makes “contract talk” classifiable into those objects or claims.
• redefine quadrant semantics (L/A/D/E) or cross‑quadrant reference rules; those are defined normatively in A.6.B.

#A.6.C:2 — Problem

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

1. Act and commitment claims name compatible participants, without mistaking an interface description for the actual interface or its bearer,
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 by naming the exact Work, evaluation, or observation and its result, with an A.10 evidence path and exact carrier when a receiving decision relies on that support,
4. Multi-view publication (MVPK faces) does not create a parallel contract object or rival canonical claim set by paraphrase drift?

#A.6.C:3 — Forces

#A.6.C:4 — Solution

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

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

When “contract”, “guarantee”, “promise”, “SLA”, or “interface agreement” leaves a consequential ambiguity, ask only the live questions below. A question may yield zero, one, or several atomic claims. Add corresponding rows only when stable reuse, decision, audit, dispute, or cross-face projection needs the Claim Register; the question itself is not a bundle part or direct-object kind.

1. What was promised?

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

2. What was said, published, or instituted?

   • Speech-act Work: if the boundary decision depends on who stated, published, or approved something, identify that exact A.2.9 U.SpeechAct <: U.Work occurrence.
   • Description/publication: identify the versioned utterance epistemes separately from their publication occurrences, forms, renderings, and carriers. None is the speech act.
   • A speech act may institute or update a commitment or strong grant only when the exact context policy recognizes that act type and the subject pattern's obtaining conditions are met.
   • The published utterance descriptions (signature or mechanism descriptions plus MVPK faces) carry L/A/D/E-classified claims. The act is not “the contract”; it is the Work occurrence that created or updated those descriptions and may have a separately governed institutional effect.
   • World-side obtaining rule (normative). The predicates defined in A.2.8 and the cited context policy decide whether a commitment obtains; the predicate defined in A.2.8.PER together with that policy decides whether a strong grant obtains. For a commitment, use the actual instituting basis required by its constitutive rule: the current A.2.9 path uses an actual U.SpeechAct; another basis requires a subject pattern that admits it and gives its occurrence rule. A strong grant requires the actual instituting speech act under A.2.8.PER. Preserve the 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 by itself. For a commitment, a cited fact is constitutive only when the identified rule makes that fact current and the pattern for that subject supplies its test. Publication or approval may establish a publication/status relation only through that relation's exact predicate and obtaining facts.
   • Representation and reliance rule (normative). The model MAY assert or rely on a commitment or grant only through a separate atomic claim that identifies the exact U.Commitment or GrantedPermissionRelation@Context occurrence and cites its exact predicate, SubjectPatternLocator, participants, scope/window, and the currentness or evidence required by that use. For a commitment, cite the rule-required actual instituting basis and policy; for a strong grant, cite the actual instituting speech act and policy. Never infer the relation from Publish/Approve wording, a document, carrier, or completed-looking record alone.

3. What governance or permission-looking claim exists?

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

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

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

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

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

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

When “guarantee” leaves a consequential ambiguity, use the applicable distinction below:

• Semantic guarantee → L (“by definition or invariant”).
• Runtime-entry guarantee → A (“the mechanism admits this application iff …”).
• Governance guarantee → D (“provider commits or implementer must”).
• Operational result → E (the exact Work, evaluation, or observation and its measured or evaluated result; add an A.10 evidence path and exact carrier when the receiving decision relies on that support).

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 present that set for a bounded reader/use under E.17:

• Faces may select, summarize, and render claims for audiences. A selected episteme's U.View membership separately requires E.17.0 conformance to an exact viewpoint.
• Faces must not add a new boundary claim; they project the existing classified claims.
• Any face-level decision-relevant or normative-looking statement SHOULD cite the underlying claim ID(s) or canonical location(s). A new boundary claim MUST be added to its canonical source before publication on a face. Informative commentary may explain source claims without adding boundary semantics.

Keyword rule (faces). If a face contains a BCP-14 keyword, each sentence MUST cite its existing classified claim ID or canonical location 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. If the boundary claim is not traceable, put it in its canonical source before publishing it on the face; informative commentary is limited to explanation that adds no boundary semantics. To avoid keyword-evasion, equivalent deontic phrasings (e.g., “is required to…”, “is prohibited from…”) SHOULD follow the same claim-reference 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)

When stable reuse, decision, audit, dispute, or cross-face projection needs a record, use the A.6.B Claim Register (IDs, statements, quadrant, and canonical location). A one-off local repair ends with the repaired atomic prose. When the register is needed, add only the current A.6.C fields below without minting another record or ontology kind:

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

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

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

#A.6.C:5.1 — Tell

When boundary contract-language leaves a consequential ambiguity, recover the actual claim and referent, then answer only the live questions below. Keep ordinary metonymy when its capable participant and relation are locally recoverable; a literal act or individual commitment needs that participant and the governing conditions.

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

When those answers need stable reuse, decision, audit, dispute, or cross-face projection, write them in the one A.6.B Claim Register: one atomic statement, direct object, exact subject assertion, non-semantic pattern locator, and quadrant per row. Otherwise stop with the repaired atomic prose. Faces cite reused claim IDs or canonical locations; 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%.”

Source clauses and additional illustrative premises:

Preserve “We log all requests”; the draft supplies no particular logging Work or observation basis. “Availability is 99.9%” does not say whether 99.9% is a target, a promised bound, or an observed value; that meaning remains unresolved.

For the extended case below, assume the PaymentsAPI description/publication, definitions of idempotency and key uniqueness, a gate policy with an additional key-validity condition, and a generic provider-side idempotency prescription. These are additional case premises, not atoms recovered from the draft. The source's client requirement remains to provide Idempotency-Key.

• Description/publication: signature or mechanism publication for PaymentsAPI (MVPK faces: TechCard, InteropCard).
• L: define idempotency and the uniqueness semantics of Idempotency-Key. (“Idempotent” is a semantic property, not a duty.)
• A: admissibility predicate: request is admissible iff Idempotency-Key is present and valid. (Gate belongs to mechanism.)
• D: the API policy generically requires covered clients to provide Idempotency-Key. In this extended case it also states a provider-side idempotency prescription. No individual commitment follows from those clauses alone. If the case claims that ClientIntegrator-A or ProviderSystem-A bears one of those duties, cite that bearer's exact separately instituted A.2.8 commitment. (Responsibility, if claimed, needs its own direct relation.)
• E — additional hypothetical evaluation: suppose admitted system PaymentsAvailabilityEvaluator-A performed AvailabilityEvaluation-Payments-T1 : U.Work over the exact Payments API request population and window T using the availability metric stipulated for this evaluation. Exact A.6.1 application PaymentsAvailabilityApplication-T1 has result binding availabilityResult -> AvailabilityResult-Payments-T1; that C.2.1 result episteme states observedAvailability=99.9% for T. When the SLA decision relies on this result, an A.10 path links it to the exact request-log and measurement carriers used. This hypothetical observation does not select the meaning of the draft's unlabeled 99.9%.

(B) Hardware interface boundary

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

Source requirements and additional illustrative premises:

The draft leaves open whether “Devices must not exceed 20V” is a device-behavior constraint or an obligation on a capable bearer, and it does not identify the safe-operation predicate. Preserve the 20V upper bound and the requirement that negotiation succeed before power is applied. The additional gate and test below do not resolve the bearer or safety choices.

• Description/publication — additional case premise: assume a published interface spec supplying the pinout, electrical ranges, handshake procedure, and the test declaration used below.
• L: electrical invariants and allowable ranges are definitions and invariants (truth-conditional).
• A — additional gate premise: suppose the interface specification makes power delivery admissible only after the handshake state reaches an agreed mode.
• Requirement awaiting classification: retain “Devices must not exceed 20V”; recover its constraint or duty-bearer reading before assigning it to L or D. The negotiation-before-power requirement remains distinct from the additional gate predicate.
• E — additional hypothetical test: suppose admitted system HardwareTestSystem-A performed ConnectorSafetyEvaluation-T1 : U.Work over Connector-C1 under the declared method, load, and temperature window. Exact A.6.1 application ConnectorSafetyApplication-T1 has result binding safetyResult -> ConnectorSafetyResult-T1; that C.2.1 result episteme states maximumObservedVoltage=19.8V, handshakeState=agreed-before-power, and ConnectorSafetyCriterion-v3=satisfied for those conditions. When relied on, an A.10 path links this result to exact TestReport-C1-T1, VoltageTrace-C1-T1, and NegotiationLog-C1-T1 carriers. In this hypothetical test, 19.8V is below the retained 20V upper bound. The separately given criterion result does not by itself settle the draft's unspecified safe-operation claim.

(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.
• Speech-act Work: ReleaseGrantorAssignment is a declared U.SystemRoleAssignment species. Occurrence ReleaseGrantor-A has admitted System ReleaseAuthoritySystem as holder and the local release-grantor kind as assigned-kind value. That System performs dated Approve occurrence SA-4711 under the assignment. The assignment supplies only the holder and assigned-kind facts used by the policy. Any authority required by ReleaseGrantPolicy must obtain independently. Under the applicable policy, SA-4711 institutes—not merely publishes—grant occurrence PER-4711 only if the A.2.8.PER obtaining conditions hold.
• D — current grant (A6-AW-NORM-GRANT): ReleaseOperatorAssignment is another declared species. Occurrence Operator-A has admitted System DeploymentAgent-A as holder and covers this window. The grant's beneficiary participant cites that occurrence, and its permitted-action participant is U.EpistemeRef(Deploy-Release-4711). This Claim Register row uses U.RelationRef(PER-4711), constrained to GrantedPermissionRelation@Context, as its directObjectDesignation. SA-4711, the two assignments, policy, context, scope, and window remain grounds or qualifiers. The model may use this D claim only while the A.2.8.PER conditions make PER-4711 obtain and the row cites the named occurrence, act, and policy.
• 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. If an actual gate decision is also asserted, record its exact A.21 GateDecisionResult, bounded action, applicable profile application, complete required check-application result set, decision value, and consequence as a separate E claim.
• E — actual Work and exercise (A6-AW-EXERCISE): A.13 first recovers admitted System DeploymentAgent-A as the exact actual performer through obtaining assignment occurrence Operator-A of declared species ReleaseOperatorAssignment; A.15.1 independently admits dated U.Work occurrence DeployRun-4711. Because this permission-exercise branch expressly consumes precise assignment-bound attribution, F.6 then relates that already admitted Work through the same assignment and checks holder equality and coverage. The Work must instantiate the action specification inside the grant's scope and window. Only then may PermissionExerciseRelation@Context bind WorkRef(DeployRun-4711) to U.RelationRef(PER-4711), constrained to GrantedPermissionRelation@Context. The assignment contributes the beneficiary and attribution facts consumed here. Failed F.6 leaves the Work intact but blocks this attribution-dependent exercise branch. Planned work, the approval wording, and preflight alone are not exercise.
• E — optional result or delivery: if DeployRun-4711 returns ReleaseArtifact-4711, cite the exact A.6.1 result binding or an already governed subject-specific WorkResultRelation; if that artifact is transferred, cite the independently obtaining delivery/transfer relation defined by its subject pattern.
• 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.

#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.”

Source clauses and additional illustrative premises:

The progress guarantee still needs its semantic or operational meaning. For the illustrative case below, assume the published protocol description and the trace-admissibility criteria; the named trace evaluation is an additional hypothetical case.

• Description/publication: protocol description (could be a type spec or protocol spec plus explanatory views).
• L — when the guarantee is semantic: the progress property is a law over the protocol model (truth-conditional, within the theory).
• A: admissibility: when an interaction trace is considered valid or admissible (e.g., runtime checks; compilation checks; gating conditions for entering a session).
• D: the protocol description generically requires covered participants to follow the stated sequence. It asserts no individual commitment occurrence.
• E — additional hypothetical trace evaluation, not inferred from the progress guarantee: suppose admitted system ProtocolConformanceEvaluator-A performed ProtocolConformanceRun-T1 : U.Work over bounded interaction Trace-42. Exact A.6.1 application ProtocolConformanceApplication-T1 has result binding conformanceResult -> ProtocolConformanceResult-T1; that C.2.1 result episteme states conformanceVerdict=pass and observedTerminalState=completed under ProtocolConformanceCriterion-v5. For a disputed interaction, an A.10 path links this result to exact MessageTrace-42, ConformanceRunRecord-T1, and ProtocolAuditRecord-42 carriers.

(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, when present): a responsiveness promise for a defined incident class and window is separate from the SLA's generic prescription.
• Description/publication: SLA publication (and its views for different audiences).
• A: admissibility predicate for the promise: ticket qualifies iff severity classification meets stated conditions.
• D: the SLA clause generically requires the covered Provider to respond within 4 hours for Severity-1 incidents; only Severity-1 is covered. Claim that actual provider ProviderSystem-A bears the four-hour duty only after the SLA's individualizing rule and required actual basis establish one exact A.2.8 commitment; otherwise keep the clause generic.
• Evidence source clause: the draft names ticket logs as evidence; it supplies no measured response interval.
• E — additional hypothetical response evaluation: suppose admitted system SLAEvaluator-A performed ResponseEvaluation-Ticket-17 : U.Work over Severity-1 ticket Ticket-17 under the declared clock and measurement method. Exact A.6.1 application ResponseMeasurementApplication-Ticket-17 has result binding responseIntervalResult -> ResponseIntervalResult-Ticket-17; that C.2.1 result episteme states observedResponseInterval=3h42m and withinFourHourTarget=true. When the SLA decision relies on this result, an A.10 path links it to exact ticket, response-timestamp, clock-source, and severity-classification carriers. The four-hour requirement is from the source; 3h42m is the additional hypothetical observation.

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

• 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; requires compatible participants for literal agency claims without rejecting recoverable interface metonymy.
• 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). When contract-like wording leaves a consequential ambiguity, the text SHALL answer only the applicable four-question branches with atomic claims. Speech act, description/publication, generic prescription, individual commitment, selected permission-side claim, dated Work, each consequence, and each evidence claim SHALL retain its own direct object, exact subject assertion, non-semantic pattern locator, and quadrant.

2. CC‑A.6.C‑2 (No agency to epistemes). When a dated act or individual commitment is claimed, the text MUST identify its capable actual participant and MUST NOT substitute an API/interface label, description, publication carrier, kind, or assignment for that participant's basis. Ordinary metonymy may remain when its participant and relation are locally recoverable. A generic prescription SHALL name its exact normative source and applicable content without inventing an individual bearer. An individual duty or commitment SHALL name its actual bearer and exact separately obtaining U.Commitment; an assignment may appear only as an instituting rule's applicability ground.

3. CC‑A.6.C‑3 (Classify contract-language statements via A.6.B). When contract-language leaves a consequential ambiguity, its unpacked statements SHALL be atomic L/A/D/E claims. In that unpacking, permission-looking wording SHALL select one A.6 A6-AW-* row; A.2.8.PER membership alone MUST NOT set the quadrant.

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

5. CC‑A.6.C‑5 (Evidence hook for operational guarantees). If a “guarantee” is operational (requires reality to decide), the text SHALL include an E claim naming the exact Work, evaluation, or observation, predicate and object, scope or window, and measured or evaluated result. When a receiving decision relies on evidence, the claim SHALL cite the A.10 evidence path and exact carrier used for that reliance.

6. CC‑A.6.C‑6 (No second contracts via faces). MVPK faces MUST NOT add new boundary claims; they publish only the existing canonical L/A/D/E claims under E.17. Informative commentary may explain those claims without adding boundary semantics. An asserted U.View separately requires E.17.0 conformance.

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 or canonical location, direct object, and selected A6-AW-* row when permission-looking. Only norm/grant claims cite D; gate claims cite A; exercise and evaluated findings cite E.

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

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

#A.6.C:9 — Consequences

Benefits

• Category mistakes (“contract soup”) become systematically repairable.
• Generic prescriptions remain usable without invented occurrences, while individual commitments remain distinguishable and adjudicable through their actual bearer, rule, instituting basis, scope, validity, and any evidence needed for reliance.
• Boundaries remain evolvable: laws, gates, governance, and evidence can evolve with controlled coupling.

Trade-offs and mitigations

• Additional authoring effort; mitigated by applying the unpacking only when contract-like wording leaves a consequential ambiguity, and by persisting a Claim Register entry only when stable reuse, decision, audit, dispute, or cross-face projection needs it.
• Some stakeholders prefer “one sentence contract”; mitigated by MVPK faces that present curated projections while keeping the underlying claim set coherent.

#A.6.C:10 — Rationale

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

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

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

Informative. Alignment notes; not normative requirements.

• Adopt — BCP 14 (RFC 2119 + RFC 8174) keyword discipline. The visible keyword does not select a quadrant: generic prescriptions, separately instituted individual duties, and current grants enter D; entry predicates enter A; actual A.21 gate results, exercises, and 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. Viewpoint conventions constrain a selected episteme claimed as U.View; E.17.0 tests that conformance. A.6.3 governs any separately claimed construction. A.6.C keeps contract claims canonical across ordinary E.17 publication faces as well.

#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 “contract or guarantee” wording in a boundary use still leaves a consequential ambiguity after RPR, apply A.6.C to that ambiguity. (A.6.C is not a specialization of A.6.P; A.6.P is relation‑precision, A.6.C is boundary‑contract disambiguation.)

• Coordinates with

  • A.7 (EntityOfConcern, Description episteme, and carrier) for correct placement of evidence claims.
  • A.15.1 for the exact dated Work occurrence and its §4.6 dispatch to application/result, production, change, evaluation, evidence, delivery/transfer, and acceptance patterns.
  • F.12 (service acceptance) for structuring how promise-level commitments connect to evidence and acceptance windows.
  • E.17 MVPK “no new semantics” rule to prevent publication faces from becoming new contracts.
  • A.2.8.PER for the exact permission-side direct objects; A.6 A6-AW-* and A.6.B classify each atomic claim without treating pattern selection as its quadrant.

#A.6.C:End

#Relation Obtaining and Individuation: Distinguish Occurrences When Needed

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

#Problem frame

Plain name. Relation occurrence.

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

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

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

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

First useful move. State the direct relation and named participants using the subject pattern's meanings and obtaining predicate. Apply that test to the relevant world facts or constituting history and record the resulting polarity in a claim-bearing episteme. Ask whether later work must distinguish this occurrence from another, including a repeated episode with the same participants. If not, keep the direct sentence and stop; otherwise apply the identity and receiving-use steps in section 4.2.

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

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

Not this pattern when. If the wording does not yet identify the direct relation and participants, start with A.6.P or A.6.RSIR. If no exact ClaimGraph yet defines the participant meanings, applicability, and obtaining predicate, recover that content rather than inventing a case test here. If the current case lacks relevant world facts or constituting history, keep the statement as a C.2.1 claim under the exact direct predicate. Keep denials, forecasts, scenarios, counterfactuals, and permissions in their exact claim families; keep evidence and reliance results under their separate governors. Individuate an occurrence only when the relevant facts or history satisfy the predicate. Record supported, refuted, or unresolved reliance under A.10 or the current evaluation when that separate judgement is needed. When current-case facts satisfy the direct predicate, A.6.REL remains available only if later work must tell this occurrence from another occurrence of the same relation. If the question concerns only the SlotSpecs of a reusable relation declaration, apply A.6.5. If later work only reports the current relation, keep the direct sentence and stop.

#Problem

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

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

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

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

#Forces

#Solution

Local relation-occurrence mantra. State the direct relation. Ask whether later work must distinguish repeated occurrences. If no, stop. If yes, apply the direct identity rule and add only the exact receiving object.

Use A.22.CGUS when a receiving use needs a reusable constraint-governed unfolding structure for these continuations and stops.

#Apply the relation-object architecture discipline

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

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

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

#World-side objects

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

#Relation-kind settlement

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

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

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

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

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

#Reusable declaration episteme

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

#Claim and description epistemes

A receiving episteme contains a relation-participant designation in a content position corresponding to one declared SlotSpec. A concrete representation may carry that designation in a field, but the field keeps its source name and corresponds to the declaration-local SlotKind only through an explicit declaration or representation 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 the selected representation or representation-transition pattern; C.29 governs a declared mathematical-lens use. Structural equivalence goes to C.34, and cross-context sameness goes to A.6.9.

#Use the subject pattern for the current object

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

#Name only the minimum current object

The relation-object architecture organizes the distinct objects that may become current. For each relation sentence, select only the object needed by the current use. Stable relation-kind semantics belong once in the direct relation pattern or ontic. A reusable declaration belongs once in its RelationSignature. A durable name belongs once in its F.18 naming settlement. Later prose names the object current for its use and cites the subject pattern for already established neighboring objects.

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

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

#Apply the receiving-use test

Here receiving use is ordinary wording. First state the readable relation and ask what later work must distinguish. If occurrence identity is needed, name the exact receiving object: an assertion or description episteme under C.2.1, a direct relation that uses the occurrence as a world-side participant, or an assertion episteme stating that one already identified operation application binds the occurrence as the actual value of a named A.6.1 argument. Any acting system, enacted method, and performed work remain separately governed.

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

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

#Select an identity rule that survives repetition

Use participant-determined identity only when the direct ontology establishes that two distinct occurrences of this relation kind cannot have the same participant identities. The RelationSignature SlotSpecs declare how assertion or description episteme content designates those participants. SlotKinds identify declaration components; database-row and representation keys identify representation elements. Neither function supplies the world-side occurrence-identity rule; apply any constitutive-participant contribution declared by that rule.

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

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

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

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

A relational assertion is an episteme whose content affirms or denies the direct obtaining predicate for the designated participants. Keep forecasts, scenarios, counterfactuals, permissions, and other claim families under their exact direct governors. Record supported, refuted, or unresolved reliance separately under A.10 or the receiving evaluation. 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

The direct relation pattern states the shared participant meanings, obtaining predicate, applicability, and identity rule once; later uses cite only what their branch consumes.

The alternatives below show semantic dependencies within demand-driven progressive elaboration. They share one readable direct relation. 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 diagram shows the stop decision and optional increases in explicitness. Its indentation records one dependency: description, identifier assignment, occurrence participation, and later designation require a recoverable occurrence after the same-versus-new-occurrence rule.

#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. Revising an episteme about an occurrence does not by itself establish a change in that occurrence. Check whether the changed episteme or performed Work is constitutive under the direct rule. 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 does not by itself entail a new relation occurrence.

Use A.10 only for a separate evidence-based reliance question. Determine world-side continuation, cessation, or a new occurrence from current-case facts or constituting history under the direct identity rule.

#Archetypal Grounding

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

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

1. World-side participants and occurrence. Robot-7 remains an admitted U.System; InspectorSystemRole remains one exact local C.3 kind. InspectionAssignment-17 is an occurrence of directly declared MaintenanceInspectionAssignment <: U.SystemRoleAssignment. Robot-7 participates as the holder system and InspectorSystemRole as the assigned local system-role kind. Those two values are the complete participant set of this direct species.
2. Direct settlement. A.2.1 supplies the species' participant meanings, direct predicate, applicability, and same-versus-new-occurrence rule. The occurrence continues while that predicate obtains without interruption for the same complete participant set. A demonstrated predicate-false gap ends it; later resumption starts another occurrence. An evidence gap by itself does neither.
3. Reusable declaration. For typed reuse, the MaintenanceInspectionAssignment RelationSignature contains HolderSystemSlot : U.System / U.EntityRef and the declaration-local AssignedSystemRoleKindSlot with MaintenanceSystemRoleKindDomain as ValueKind and ByValue as refMode. In InspectionAssignment-17, InspectorSystemRole is the assigned-kind participant value. A stronger direct species adds only its real identity-bearing participants. assignmentInterval remains assertion or occurrence-description content, not another participant SlotSpec.
4. Assertion and participant designations. An InspectionAssignmentAssertion carries designations corresponding to the species' declared SlotSpecs and states the currently known assignmentInterval separately. Its claim may say that Robot-7 is currently assigned as inspector through InspectionAssignment-17. If later use only needs that current report, keep the assertion and stop without adding another occurrence object.
5. Occurrence identity, designator, and reference. Suppose two episodes of the same direct species have the same complete participant values but occur in inspection shifts separated by a demonstrated predicate-false period. To prepare a history or Work-attribution claim that must distinguish the episodes, a practitioner applies the A.2.1 continuity rule, distinguishes the second occurrence, and assigns a designator only if stable reference is needed. A roster-row identifier, copied field set, taxonomy edition, reference scheme, or reused source key cannot collapse or split the two episodes.
6. Representation. A roster row or diagram edge may represent the assignment assertion or an occurrence-description episteme. A roster row's fields and key retain their representation-side meanings; the source elements of a diagram edge retain their representation-side meanings. An explicit declaration or representation 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. In a current staffing report, keep the readable direct sentence. For typed reuse, consult the existing declaration. When history or Work attribution must distinguish a repeated episode, apply the A.2.1 continuity rule and distinguish that episode; assign a designator only if stable reference is needed.

#Hypothetical installed-part boundary

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

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

#Formal reduced case

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

#Relation occurrence as a participant

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

#Description and publication recursion through the relation-object architecture

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

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

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

#Bias-Annotation

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

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

Engineers can easily picture relation instances through data-model examples. When a representation must distinguish an obtaining occurrence, first apply the subject pattern's obtaining test to the relevant case facts or constituting history, then apply its occurrence-identity rule. A system introduces a database row, graph edge, reifier, or other representation for that declared use only after those steps. Representing an assertion or another claim family does not by itself require an obtaining relation occurrence or explicit individuation.

#Conformance Checklist

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

#Common Anti-Patterns and How to Avoid Them

#Consequences

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

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

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

#Rationale

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

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

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

#SoTA-Echoing

#Ontological SoTA and constructional sources

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

#Representation and implementation stress tests

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

The worked cases expose both boundaries outside information-system projects.

#Relations

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

#A.6.REL:End

#U.Signature - Reusable Law-Governed Declaration Episteme

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

Pattern kind. Ontic declaration pattern.

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

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

#Problem frame

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

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

Before opening declaration fields, ask:

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

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

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

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

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

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

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

#Problem

FPF uses a signature when the episteme itself performs the reusable declaration job above: it identifies the declared subject and value or result range, supplies terms and laws another use may rely on, and says where those laws apply. Current non-exhaustive declaration families include theory or A.3.3 U.Dynamics epistemes, mechanism or A.19.SelectorMechanism declarations, method-kind declarations, formal substrates, and direct relation-kind declarations. 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 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 identified by 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. Apply A.22.CGUS only when one independently identified A.22 structure has local loci and at least two potential continuations defined by its selected relations and applied constraints.

#Admit and identify U.Signature

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

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

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

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

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

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 representations remain separate objects and relations under their direct patterns; 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. C.3 governs the declared kinds; E.24.UK governs public U-kind admission. 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 tells how the declared kind's members are determined at one named slice. A time selector may be part of a U.ContextSlice; a value or result range stays in RangedValueKind or ResultKind; changing data stays with its subject pattern; and a claim-bearing mathematical set representation opens C.29 only for a mathematical-lens use. 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. Retain both the effective U.ReferenceScheme and exact U.ClaimScope when adding these applicability qualifiers.

#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. A RelationSignature 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.

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

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

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

#Declare participant meanings and operation parameters under different specializations

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

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

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

A formal or mechanism declaration may instead need named operation arguments and a result. A.6.1 governs that OperationAlgebra. A representation may use a mathematical operand order, product, function, or tuple. A.6.3.RT governs a same-EntityOfConcern representation-scheme transition; C.29 governs only a mathematical-lens use. 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 SignatureManifest heading co-locates entries with three functions: id is an identity-neutral display designator; signatureRef and its optional .edition pin form a governed reference to an already recoverable signature episteme; and imports and provides may carry or represent dependency and name-or-law introduction claims in the signature's exact U.ClaimGraph.

The SignatureManifest section may carry entries with these functions:

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

Use these dependency-manifest predicates:

• SM-1 Term-and-law resolution. Every required non-local term or exact law claim resolves under the effective reference scheme to the one named provider declaration that supplies it.
• SM-2 No redeclaration and legal direction. A provided term or law is not also supplied by a transitive import under the same effective reference scheme, and the claimed provider-to-consumer direction matches the predicate of the exact dependency or source-use relation rather than a drawn arrow or list order.
• SM-3 Replay order and cycles. A selected one-pass provider-to-consumer replay method requires an acyclic ordering of the recovered dependency designations. A cycle means that this replay method cannot run; it does not by itself prove that every semantic dependency in the cycle is prohibited. Apply each exact dependency governor to its edge. If no current governor decides whether the semantic cycle is legal, return an exact missing-governor blocker instead of deleting an edge or inventing an order. Keep the graph representation, cycle check, and ordering notation separate from the semantic dependency claims; use C.29 only when a mathematical-lens use is current.
• 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. 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. A provider or provider-edition change may require resolution, replay, or currentness review; it changes the consumer signature's identity only when the consumer's own claim content, exact EntityOfConcern, or effective reference scheme changes.

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

#Specialize declaration use without minting another root kind

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

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

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. For ordinary reuse, apply the frame's Applicability and the direct subject rules for any reference-plane or model-use-structure question. When the receiving claim needs an exact semantic relation between two local senses whose interpretation bases differ, first recover the two exact F.17 local senses; cite an F.9 Bridge only if its direct predicate obtains and state the bounded-use claim, direction, preservation, loss, and any required reliance separately. Cited declarations remain independently identified objects, not extra PrincipleFrame identity components.

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

#Rule-content actual-use predicate declaration

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

Its vocabulary includes SelectedRuleContentSubgraphDesignation@RuleContentBasisFindingDefinition-R7, derivedUsingRuleContent@RuleContentBasisFindingDefinition-R7, and evaluatedAgainstRuleContent@RuleContentBasisFindingDefinition-R7. The designation resolves one exact nonempty base subgraph selected for one identified use. RuleContentDerivationProfile@R7, RuleContentEvaluationProfile@R7, and RuleContentBasisFamilyAlgebra@R7 are named subgraphs of this signature's ClaimGraph.

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

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

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

#Candidate-basis establishment and family disposition

RuleContentBasisFindingDefinition@R8 is a changed-law successor of R7. It preserves R7's two actual-use predicate tests and adds the following laws to its named RuleContentBasisFamilyAlgebra@R8 subgraph. Candidate sufficiency is a separate operation: it asks whether a basis can support the exact derivation or bounded evaluation under named rules, not whether that basis was actually used. Existing R7 actual-use assertions retain their exact definition and use pins. R8 inherits no acceptance, actual use or reliance merely from succession.

For one exact analysis question and temporal cell under E.4.PFR §3.6, take a finite candidate universe V and its supported open/closed state. Each candidate is a finite nonempty conjunctive set of semantic-base subgraphs. The receiving contract fixes which axes are required before evaluation. Exactness, applicability and sufficiency are always required; acceptance and witness join that conjunction only when the receiving contract requires them. Each axis has an independently supported true/false result or remains unknown.

Sufficiency. In derive mode, the named inference rules derive the exact dependent proposition from the candidate basis with no undeclared premises. In evaluate mode, the basis supplies the criteria and facts required by the named evaluation rule to obtain its bounded result. That result may be negative: a supported failing evaluation does not make its basis insufficient. These laws neither establish derivedUsingRuleContent nor evaluatedAgainstRuleContent without their separate actual-use facts.

Establishment. A candidate is established iff all required axes are true. It is decisively defeated iff at least one required axis is false, even when another is unknown. Otherwise its establishment remains unresolved. Minimality is an additional result: a candidate is inclusion-minimal when no proper sub-basis in the stated comparison domain is sufficient under the same rules. Unknown or false optional minimality does not remove an established candidate. A request for a minimal family qualifies that additional answer separately.

Let F contain all and only established candidates. Keep independently sufficient alternatives even when a required overlapping pair has incompatible consequences. A required pair is one whose compatibility can change the cell disposition or named receiver action; its result is compatible, established incompatible, or unresolved. Apply conflict precedence, then exactly one row:

An unknown axis on an already defeated candidate is not unresolved establishment. With fewer than two established candidates, no required pair exists and the all-compatible pair condition is vacuously true. The supported needed-content claim retains its reconsideration condition. A closed empty universe alone proves no missing need. Without a named receiving analysis need, take E.4.PFR's no-analysis exit before this operation.

R8's succession claim names R7, R8, changeClass = reusable-law-change, the added sufficiency/required-axis/conjunction/minimality/partition laws and inheritedAcceptanceOrUse = none. A dependency pin chooses the exact definition edition; R8 does not retarget R7 consumers. The result remains a non-permissive analysis assertion under C.2.1.

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

The rows name the direct patterns that define or constrain these common adjacent objects and claims.

#Add explicit objects only for a named receiving use

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

1. State the direct relation and stop. Use this branch when the task only asks whether one direct relation's predicate holds for its actual participants under its subject pattern's conditions. State the affirmative or negative claim under that pattern, or an exact governed modal claim when that family is current. For example, During Shift-17, Robot-7 is assigned as inspector through InspectionAssignment-17 is a complete current A.2.1 assertion when the direct MaintenanceInspectionAssignment predicate holds. Add an A.10 or receiving-evaluation reliance judgment only when the task separately asks whether to rely on the assertion.
2. Share one declaration. Reuse or author a signature when at least two named claims or consumers must use the same participant meanings, vocabulary, laws, or applicability. For example, a staffing assertion and an F.6 Work-attribution consumer can cite the MaintenanceInspectionAssignment RelationSignature when both must interpret HolderSystemSlot, its declaration-local AssignedSystemRoleKindSlot with MaintenanceSystemRoleKindDomain as ValueKind and ByValue as refMode, any real species-specific participants, and the same direct predicate. In InspectionAssignment-17, InspectorSystemRole is the assigned-kind participant value. 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. That target motivates authoring, selection, reuse, or explicit individuation. Apply C.2.1 to episteme identity and the direct relation pattern to occurrence identity. Selecting or reusing an unchanged episteme leaves its identity unchanged. When entries, branches, returns, or stops form one reusable structure, apply A.22.CGUS only after the A.22 identity, local locus bindings, selected relations and constraints, and potential continuations are recoverable.

#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. State the applicable declaration, dependency, operation, lens, or carry-through relation for the receiving use.

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. For ordinary reuse, apply the frame's Applicability and the direct subject rules for any reference-plane or model-use-structure question. If the receiving claim needs an exact semantic relation between two local senses whose interpretation bases differ, recover the two exact F.17 local senses and test the direct F.9 predicate; cite a Bridge only when it obtains, state preservation and loss in a separate bounded-use claim, and establish any required reliance before use. A 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.

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, apply F.19 to the changed wording; use E.10 for unresolved lexical questions and F.18 for durable naming. Accept the rename only when a cold reader can still recover the same FPF kind, declaration use, and practical action; otherwise keep the old name or return the naming defect. Do not revise the signature merely because a realization, work occurrence, measurement, Bridge use, evidence-use relation, publication, provider currentness, or G.11 selection changed. Update that neighboring object under its subject pattern, and reopen the signature only if its own claim or dependency content must change.

#Archetypal Grounding

#Physical modeling: connector-equation FormalSubstrate

A multi-domain modeling team repeatedly uses one connector-and-equation calculus. The EntityOfConcernRef of its U.Signature(profile=FormalSubstrate) identifies that calculus. 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. 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; use A.6.1 for operations, A.15.1 for Work, and E.24.PUB for publication. Govern each representation and its declared correspondence through the applicable representation pattern, including A.6.3.RT for a same-EntityOfConcern representation-scheme transition. Open C.29 only for a mathematical-lens use.

Practical payoff: engineers can compare the connector vocabulary and equation laws across tools.

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

A selected assay-result episteme may support or refute the compound assertion. Use A.2.4/A.10 to qualify that evidence use and any intended reliance. When an assay result changes, reassess whether it supports or refutes the same bounded assertion; that assessment may stay the same, change, or be unresolved. The reusable predicate definition remains unchanged. A changed outcome meaning, population, dosing condition, or declared applicability changes the definition's claim content and C.2.1 identity.

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.

#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. 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 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: 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 and the lost coordinate or layout detail. State a blocked inference only when it passes F.19:4's full guard test.

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

#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 comparison result may show that the residual is below the chosen tolerance. The comparator and tolerance remain under their direct comparison and measurement patterns; operation admission remains under A.6.1, and a gate-passage verdict remains under A.21/C.11. If a laboratory measurement sense is proposed for use in a plant-model sense, resolve both exact F.17 local senses and apply F.9. Cite a Bridge only when its predicate obtains; state the bounded use and any preservation or loss of sign convention, unit, and boundary interpretation separately.

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

#Reduced ordinary-use case

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

#Bias-Annotation

Scope declaration: Universal across FPF-governed domains.

• Gov. Favors making the direct governor of declaration membership, declared content, and neighboring claims inspectable, together with explicit dependencies. Counter-risk: declaration administration can grow beyond reuse value. Mitigation: add SignatureManifest only for actual dependency.
• Arch. Favors a small declaration core with direct neighboring patterns. Counter-risk: the signature becomes a central container. Mitigation: keep realization, work, evaluation, and publication with their direct patterns.
• Onto-Epist. Favors strict separation of declaration episteme, declared subject, obtaining occurrence, assertion, and representation. Counter-risk: excessive explicitness. Mitigation: stop at the direct assertion unless two named consumers share declaration content or one later claim must distinguish the occurrence.
• Prag. Favors reusable named SlotSpecs and laws. Counter-risk: one-off work becomes formal paperwork. Mitigation: ordinary direct sentences remain sufficient.
• Did. Favors the four content groups and local mantra. Counter-risk: readers treat the mnemonic order as a required execution order. Mitigation: apply A.22.CGUS only to an independently identified structure of potential continuations; actual execution remains a separate Work or Transformation claim.
• Context transport. Interpret the signature's claims under the effective U.ReferenceScheme and use them within their stated scope. Counter-risk: the same label in another context is treated as equivalent or safely substitutable. Mitigation: when a proposed reuse relates two exact F.17 local senses, test the direct F.9 predicate and cite a Bridge only when it obtains; state direction, rule, tolerated loss, and polarity in a separate bounded-use claim. Without the needed semantic relation and use claim, do not transport the claim by label alone.
• Comparability. Two declarations do not become comparable because both expose numbers. Counter-risk: numeric appearance hides incompatible characteristics, measurement procedures, units, scales, comparators, or normalization. Mitigation: apply the current A.17/A.18/C.16 characteristic, measurement, and unit-and-scale patterns and A.19.CPM/A.19.UNM comparison and normalization patterns as the case requires, then state the resulting comparison boundary; keep their detailed legality and result-shape rules with those subject patterns.
• Register. Make technical declaration blocks and worked cases readable for their intended use. Counter-risk: a technically correct block remains unusable without private decoding. Mitigation: apply F.19's connected reading and local revalidation. Unpack decisive FPF terms or add an ordinary explanation only when needed to recover the claim or action and its relevant result; preserve the governed object, subject pattern, admissible use, and practical action.

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.

#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 an occurrence. Every worked case that uses a RelationSignature also names the already admitted relation kind, direct governor and predicate, participant meanings, Applicability, occurrence-identity rule, and one ordinary affirmative or negative assertion. A hypothetical domain-local relation kind is labelled and fully settled before the example uses it.
7. Direct relation-pattern governance. The direct relation pattern defines or constrains obtaining and occurrence identity.
8. Typed-declaration boundary. Reused participant meanings are declared inside a RelationSignature by A.6.5 SlotSpecs with exact SlotKind, ValueKind, and refMode. Operation arguments and results remain A.6.1 declaration content. Mathematical operands and field order remain representation-side under A.6.3.RT; C.29 opens only when a named mathematical lens changes the declared lens use or next comparison action. An operand-to-participant correspondence is stated only for an already governed relation claim.
9. Semantic locality. Meaning uses the effective reference scheme; applicability uses the exact claim scope and only qualifiers current for the declaration, such as a relevant time interval, selected CHR:ReferencePlane, or genuinely current model-use structure.
10. Dependency truth. Every import names the provider and exact term or law without which interpretation or law replay fails; every provide entry names a dependent declaration that relies on the introduced term or law. Citations and list order do not qualify. SM-1 through SM-4 hold, and a replay cycle is distinguished from a semantic-prohibition verdict.
11. Realization boundary. Mechanism behavior and admission conditions remain with A.6.1.
12. Progressive elaboration. A direct assertion is enough when the task only asks whether the predicate holds; a signature opens when at least two named consumers share declaration content; occurrence identity opens only for a later same-occurrence reference, comparison, qualification, history/change claim, or relation participation. A log or assertion identifier alone opens none of them.
13. CGUS boundary. Judge any condition-governed unfolding claim through A.22.CGUS, using the independently identified structure and continuation conditions stated in §4.
14. Profile boundary. FormalSubstrate and PrincipleFrame remain profiles of U.Signature rather than new root kinds. A PrincipleFrame names its postulates and the observable distinctions needed to check them, leaves operation and gate admission with their subject patterns, and uses F.9 for a relation between two exact F.17 local senses, citing a Bridge only when its direct predicate obtains.
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. F.19 self-application and reader use. Apply F.19 by value to every materially changed technical declaration, mantra, checklist instruction, and worked case; revalidate the changed span with its meaning-dependent neighbours. The cold intended reader must be able to recover the same governed object, subject pattern, admissible use, and practical claim or action, including any result that changes that use. Keep ordinary technical wording when it already carries the needed distinctions; unpack terms or add an explanation only when recovery needs it. Use E.10:11 item 16 when the value-substitution question is selected. State a nearby non-use or contrasting case only when F.19:4's full guard test warrants it. A Plain label without that reader-visible recovery does not pass.
17. Case-level witness. Each worked case names its exact EntityOfConcern, the direct pattern that defines or constrains the claim being made, and what the practitioner can now write, decide, or inspect. State the nearest category error it rejects only when F.19:4's full guard test warrants that contrast. 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.

#SoTA-Echoing

Sources:

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

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

#Relations

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

#A.6.0:End

#U.Mechanism - Reusable Law-Governed Operation Declaration

Status: Stable

Pattern kind. Ontic declaration pattern.

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

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

#Problem frame

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

Use this pattern when the working question is:

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

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

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

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

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

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

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

#Problem

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

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

The repair is a small set of exact distinctions applied with progressive explicitness.

#Forces

#Solution

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

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

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

#Admit and identify U.Mechanism

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

<content, EntityOfConcernRef, effectiveReferenceScheme>

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

Use this early object-and-relation guide:

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

#State mechanism content

The following is a conceptual content outline, not a mandatory record or publication layout.

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

The content components have distinct jobs:

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

OperationDeclaration, ArgumentDeclaration, and ResultDeclaration name parts of the declaration content. A bindingDesignationRule says whether a binding carries the value itself or one exact governed reference that resolves to it; a stored token or compatible reference does not establish a binding. An operation index may be derived from the operation designators for retrieval, but it is not another semantic content group.

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

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

#State meaning and applicability without a generic context slot

Meaning and applicability answer different questions:

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

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

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

• for ordinary reliance with no actual assurance claim, use A.10. Name the exact evidence-provenance relation, bounded use, unsupported stronger use, window, and reopen or stop condition; proceed only with RelianceDisposition=pass;
• when an actual named assurance claim about this use is current, use B.3 and require its result for that same bounded assurance use. Whether a direct domain rule requires the assurance claim or it is otherwise current, identify it independently under B.3.

A.6.1 AdmissibilityConditions decide whether the proposed operation application is admitted. Its actual application and bindings remain under A.6.1, while dated Work remains under A.15.1; the Bridge, bounded-use claim, and reliance result retain only their own predicates and results.

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

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

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 the finite result-value domain 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. Here unknown means that the governed values determined neither satisfaction nor failure; the application may still be admitted and occur. Candidate status and any receiving-work disposition remain separately governed.

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 records only the application's use of that value under the declared argument meaning. Criterion satisfaction, evidence support or warrant, and candidate identity remain independently governed.

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. For this three-valued operation, neither the separately materialized episteme nor its currentness is the returned 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 only this family of declaration-local binding occurrences. Public work-participant, input, output, result, evidence, and production relations remain with their direct patterns. A result binding records the value the application returned. Production or entity-identity inception, a result episteme, and later reliance each require their own governing claims.

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

#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. Any refinement or edition relation is a separate claim under its direct predicate. If a claimed realization relaxes a declared law, bypasses an admission condition, or relies on undeclared operation meanings, return to the exact realization predicate. State that the relation does not obtain when that predicate is known false; leave the exact claim unresolved when required meanings or case facts are unavailable.

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

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

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

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

A MethodDescription may cite a mechanism declaration. A Method selection requires an independently established selector result. When an actual A.6.1 application supplies that result, it must apply a declared selector operation whose obtaining result or SelectionSlot binding identifies the exact selected Method. A direct constraint relation may separately constrain the Method. An operation declaration may type a U.Method as an argument or result only when that is the operation's declared meaning; an actual application may bind the Method under that declared argument or result meaning. Planned assignment, actual enactsMethod, and a dated Work occurrence require their own governing predicates. One Work occurrence admitted under U.Work may enact the Method; the claim about that occurrence may cite the independently identified application and bindings under A.15.1. For that Work claim, recover each required actual performer and the temporal extent, enactment, and locally declared Work-to-System containment basis under A.13/A.15.1 as in §4.5; precise assignment-bound attribution remains conditional there. Add resource-use, affected-referent, continuity, and neighboring result or effect claims only when the account asserts them, each under its own governing predicate.

#State exact comparison claims among mechanism declarations

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

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

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

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

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

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

#Keep description, representation, and publication separate

U.Mechanism is already an episteme. A second episteme that explains, summarizes, or compares it is a C.2.1 meta-description whose EntityOfConcernRef identifies the mechanism episteme. A diagram, equation set, program, or table is a representation governed by A.6.3 and A.6.3.RT when representation transition matters. An E.24.PUB publication occurrence makes one selected episteme edition available for its declared audience and use. A presentation carrier bears or renders the selected publication form under PublicationFormBearingRelation.

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

Choose the explicitness needed by the current question:

• A direct sentence names one operation and its condition clearly enough for present work.
• A U.Signature is identified when reusable vocabulary, laws, or applicability matter.
• A U.Mechanism is identified when reusable operation and admission semantics matter.
• 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.
• A mechanism-realization relation occurrence is explicitly individuated only when another claim relies on that occurrence identity.

These conditions govern different objects. If entries, branches, returns, or stops form one reusable structure, apply A.22.CGUS only after its A.22 identity, local loci, selected relations and constraints, and potential continuations are recoverable.

#Change the exact object that changed

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

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

Treat a new particular application or binding, new realizer, failed evaluation, new evidence item, changed Work occurrence, returned value, or new publication as a change to that neighboring object and its affected relation. Reconsider the mechanism 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.

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 records only the range returned by that application. A prescription and any materialized result episteme require their own governing claims.

Practical payoff: protocol presentation, one treatment occurrence, and the declared calculation laws can change independently.

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

If a later claim needs this positive realization occurrence, 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.

Runtime contrast. 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: A.2.6 and A.19 remain the governing loci for scope and normalization meaning while reusing the mechanism declaration form.

#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: the declaration captures reusable publication-operation semantics while the released package and carrier retain their direct kinds.

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

RecognitionJudgmentValue is one local finite U.Kind under C.3, used here as the operation's RangedValueKind; its membership rule admits exactly true, false, and unknown. It is an operation-local kind, not a public U-kind or universal claim-status algebra. Candidate facts, evidence status, episteme-currentness values, and receiving-work dispositions use their direct kinds. The argument and result rows are A.6.1 declarations, not A.6.5 SlotSpecs.

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

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

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

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

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

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: choose the explicitness needed by the current question.
• Arch. Favors separate declaration, realization, method, work, and publication relations. Counter-risk: too many linked objects. Mitigation: make an object's identity or a relation's obtaining explicit only when the current assertion or receiving use needs it.
• Onto-Epist. Favors U.Mechanism as declaration episteme and preserves the direct kind of its subject and realizer. Counter-risk: the familiar word mechanism is overread as a machine part. Mitigation: the early object-and-relation guide and heterogeneous cases expose the distinction.
• Prag. Favors explicit argument and result declarations, application rules, laws, admission conditions, and applicability. Counter-risk: formal apparatus outruns value. Mitigation: ordinary direct statements remain admissible, and an actual binding opens only when a downstream claim asserts which value participated or was returned.
• Did. Favors a short mantra and concrete cases. Counter-risk: readers treat imperative recall as execution order. Mitigation: apply A.22.CGUS only to an independently identified potential-continuation structure and keep actual Work or Transformation separate.

#Conformance Checklist

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

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

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

#SoTA-Echoing