#Signature Stack & Boundary Discipline

A.6 · Stable · Architectural (A) · Mixed (normative only where explicitly marked; claim-classification semantics live normatively in A.6.B) · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

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

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

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

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

What goes wrong if missed. Boundary prose starts doing too many jobs at once: invariants 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 stable claim IDs, source references, stack placement, and publication-face citations, so work, reliance, evidence, commitment, and gate uses can return to their subject patterns.

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

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

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

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

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

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

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

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

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

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

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

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

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

Adversarial wording guard. When authority wording is intentionally ambiguous, split the sentence, select one A6-AW-* row per permission-looking claim, and keep every other work, evidence, gate, or assurance use with its own source.

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

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

Practitioner prompts for boundary wording use:

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

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

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

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

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

Admissibility-predicate distinction (informative): An A-* claim is a mechanism admissibility predicate or entry condition inside the L/A/D/E-classified boundary claim set. It is not an A.21 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). Use the Claim Register mini‑record in A.6.B:7. In this cluster the register is additionally used to record stack placement (Signature, Mechanism, Norms, and Evidence) and the MVPK faces that cite each claim (viewRef/viewpointRef), so “no paraphrase drift” can be audited mechanically.

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:

#Keywords

• signature and mechanism declarations
• actual occurrence
• publication face
• atomic L/A/D/E claims
• six-way authority-word branch
• Work versus non-Work effect
• separate result
• delivery
• acceptance
• and evidence.

#Relations

#Content

#Problem frame

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

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

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

This cluster overview makes one disciplined move:

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

Terminology note (informative): In this pattern:

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

#Problem

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

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

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

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

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

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

#Forces

#Solution — A stack + a classification matrix

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

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

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

The Signature Stack (as used in this cluster) is the ordered family of canonical claim layers for a boundary package. Each 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 the signature and adds AdmissibilityConditions (the entry gate) plus operational blocks (e.g., Transport, Audit and observability). These blocks specify runtime gates and observability interfaces; they are still descriptions. Use A.10 to identify the evidence sources and carriers; name carrier-producing Work only when that occurrence is claimed.

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

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

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

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

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

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

#AssuranceLane skeleton (informative)

An MVPK AssuranceLane is a 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 Mechanism’s Audit and observability semantics without restating them.

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 every new normative sentence first enters the canonical claim set. A changed permission-looking claim cites its selected A6-AW-* row and subject pattern rather than being introduced inside the face.

Example (conceptual, no tools):

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

Default placements (quadrant → stack layer / section):

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

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

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

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

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

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

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

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

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

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

Atomicity rule:

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

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

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

Action outputs after classification:

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

Informative example. Example rewrite (mixed → atomic):

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

After (classifiable + lintable):

• A-AC-1 (Quadrant A, Mechanism.AdmissibilityConditions): 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): “When a request is rejected because header X is absent (A-AC-1), an AuditLogEntry{code="NotAdmissible"} carrier is produced and can be observed in the audit stream.”

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

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

After (classifiable + adjudicable claims, with the unresolved penalty clause retained):

• D-SLA-1 (Quadrant D, Commitments and SLA): “Provider SHALL meet E-SLA-AVAIL-1 and E-SLA-LAT-1 under the stated exclusions.”
• E-SLA-AVAIL-1 (Quadrant E, Evidence-and-carriers): “availability ≥ 0.999 over calendar month T, with measurements recorded in carrier UptimeProbeSeries from viewpoint VP.ExternalMonitor.”
• E-SLA-LAT-1 (Quadrant E, Evidence-and-carriers): “latency_p95 < 200ms under workload W, with measurements recorded in carrier LatencyMetricSeries from viewpoint VP.Client.”
• D-OPS-ALERT-1 (Quadrant D, Ops duty): “Operators MUST page on breach of E-SLA-AVAIL-1 or E-SLA-LAT-1 within 5 minutes (policy).”
• E-ALERT-1 (Quadrant E, Evidence-and-carriers): “Pages are evidenced by carrier AlertEvent{ruleId,firedAt,target} and can be joined via incidentId.”
• Penalty clause (unresolved): Retain “breaches are penalized”. Recover the breach trigger, penalty and applicable parties from the governing contract terms, then use A.6.C to unpack and A.6.B to classify the resulting atomic claims.

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

After (classifiable + source-ready):

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

In this split, A-API-1 applies A6-AW-GATE, while any approval badge remains A6-AW-SOURCE unless another row's closing facts are present.

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

Then:

• if a user is deciding whether the wording may guide action, enter A.15;
• if evidence, currentness, or provenance is live, attach the A.10 evidence relation;
• if trust, readiness, compliance, or release confidence is being raised, build the B.3 assurance tuple;
• if an actual gate decision or 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 class is not any of those objects.
• Calling the selected episteme a U.View requires E.17.0 conformance; a face label, viewpoint reference, projection history, or publication does not establish it.
• Per E.17 (“no new semantics”), a face MUST NOT introduce a new semantic commitment or any new object or claim selected through A6-AW-*. A face MAY add informative explanation, examples, and cross-references. Every normative sentence cites the canonical L/A/D/E claim ID and direct object or moves into the canonical claim set.
• Per E.17 and publication-face and publication-form discipline (face‑kind closure), a publication package that claims MVPK alignment MUST NOT mint additional MVPK face kinds (e.g., “EvidenceCard”, “NormsCard”) as if they were first‑class kinds; if you need local headings, keep them as sections within the canonical face kinds.

#“Contract” unpacking: avoid assigning agency to epistemes

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

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

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.

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-*), (D) either a general prescription or a claim about one exact U.Commitment borne by an actual System or other admitted party (D-* referencing the gate ID), and (E) an evidence claim (E-*) if observability matters. A system-role kind or assignment may establish applicability only through an independently obtaining rule; neither bears the duty.
• When something needs to be enforceable but is mathematical, prefer predicate blocks rather than deontic language in the L/A blocks, per E.8’s deontics vs admissibility guidance.

#Classification sanity rules (informative, concept-level)

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

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

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

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

#Tell (universal rule)

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.
  • Transport: HTTP headers, idempotency key transport, canonical currency conversions.
  • Audit and observability: specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their semantics (fields, correlation IDs, retention class).

• Actual occurrence and work layer.

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

• Publication faces (MVPK).

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

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

Classification example:

• “Defined iff tokenValid” belongs in Quadrant A (admissibility gate).
• “Clients MUST include Idempotency-Key” belongs in Quadrant D as a normative prescription and should reference the same gate semantics to avoid divergence. It becomes a claim about one obtaining individual U.Commitment only after A.2.8 identifies the actual bearer, constitutive rule, required instituting basis, and direct predicate.
• “System emits AuthorizationRecord” belongs in Quadrant E (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: defines operations like Evaluate(model, dataset) → Report and truth‑conditional definitions of metrics (AUROC, calibration error) as Laws.

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

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

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

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

• Multi‑view (MVPK 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 (concrete format mapping lives outside Part E).
  • 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

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

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

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

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 (post-2015 practice alignment)

Informative. Alignment notes; not normative requirements.

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

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

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

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

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

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

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

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

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

#Relations

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

#Quantum-like boundary-claim classification note

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

Action classification:

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

Minimum boundary discipline before a quantum-like boundary reading:

Useful outputs:

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

#A.6:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)