#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 — fixed face kinds & “no new semantics” publication), A.7 (EntityOfConcern and Description-episteme boundary; specification use and publication-carrier distinction), A.6.C, A.2.3, A.2.8, A.2.8.PER, and A.2.9 for promise-content, commitment, permission, speech-act, and dated-Work and separate result, delivery, acceptance, and evidence unpacking, F.18 only when recovered boundary terms need durable naming, E.10.D2 (EntityOfConcern and Description-episteme boundary; specification use and refinement discipline), E.10 publication face, form, unit, and carrier discipline Purpose (one line): Keep boundary claims evolvable by classifying each statement under the right layer of the Signature Stack and the right quadrant of the Boundary Norm Square (A.6.B).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Role prompts for boundary wording use:

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

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

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

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

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

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

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

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

2. Admissibility vs deontics. MUST, SHOULD, MAY, and authority-looking words do not reveal whether a statement is a duty, one A6-AW-* permission branch, or an entry predicate. Classify the claim by its job; the word and owner family decide nothing.

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

4. Effect claims without an actual occurrence. A description, diagram, log, or metric can state or support an effect claim, but none creates the effect. Ground the exact actual occurrence first: use U.Work only when role-method-work facts obtain; use A.3/A.3.4 or the exact interaction or causal owner for natural, spontaneous, formal, or other non-Work change. Then name the observation and A.10 evidence path needed for reliance.

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

#Forces

#Solution — A stack + a classification matrix

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

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

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

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

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

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

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

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

3. Deontic layer (D: duties, commitments, and grants). Put here an accountable duty, recommendation-as-duty, prohibition, commitment, or A6-AW-NORM-GRANT claim. Cite the exact A.2.8 or A.2.8.PER object selected by that row; other A6-AW-* claims keep their own placement. Reference related L-*, A-*, or E-* IDs rather than duplicating them.

4. Observable-effects and evidence layer (E: Work-Effects & Evidence). E-* is the boundary's observable-effect/evidence claim family. Each claim names the exact actual occurrence or evaluated finding under its direct owner and, when reliance is current, the observation conditions and A.10 evidence path. U.Work is named only when role-method-work grounding obtains; a natural, spontaneous, or formal transformation may instead use A.3/A.3.4. Canonical placement is an Evidence-and-carriers section, typically rendered in AssuranceLane.

5. Actual occurrences and realizations (outside the description stack). Substitutable realizations are exercised through dated Work when A.15.1's performer, assignment, method, time, and containing-system facts obtain. A Work occurrence may participate in change, production, speech-act effect, evaluation, or evidence production, but each of those remains a separately governed relation or claim. A.3/A.3.4 also admits natural, spontaneous, and formal transformations without a performer, assignment, method, or Work occurrence.

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

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

#AssuranceLane skeleton (informative)

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

Minimal content (suggested):

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

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

Example (conceptual, no tools):

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

Default placements (quadrant → stack layer / section):

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

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

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

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

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

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

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

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

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

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

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

Atomicity rule:

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

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

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

Action outputs after classification:

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

Informative example. Example rewrite (mixed → atomic):

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

After (classifiable + lintable):

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

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

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

After (classifiable + adjudicable):

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

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

#Authority-wording split examples

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

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

After (classifiable + source-ready):

• L-API-1 (Quadrant L): the API operation and rollback terms are defined in the signature vocabulary.
• A-API-1 (Quadrant A): a request is admissible only under the named subject, action, object, context, and policy-version predicate.
• D-API-1 (Quadrant D): the accountable provider or operator commits to maintain or enforce A-API-1 under the named window and exclusions.
• E-API-1 (Quadrant E): rollback success is evidenced only by the named work traces, audit records, or metrics; a gate decision carrier can support gate passage, but not rollback execution by itself.

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

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

Then:

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

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

#View membership needs exact viewpoint conformance

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

A disciplined stack therefore requires:

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

#“Contract” unpacking: avoid assigning agency to epistemes

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

• Promise content (promise content; U.PromiseContent, A.2.3): what is promised to be made available to eligible consumers — a promise, not execution (U.Work).
• Utterance package (published descriptions + instituting act): what is said and published and versioned (signature or mechanism descriptions plus MVPK faces), plus the U.SpeechAct <: U.Work that published or approved it when provenance matters (A.2.9).
• Commitment (deontic commitment relation; U.Commitment, A.2.8): what an accountable role assignment, U.Role, or admitted acting system is obligated, recommended-as-duty, or prohibited to do (often: to satisfy a promise content).
• Permission-looking claim: do not make Permission a bundle part or quadrant. Select one A6-AW-* row for each atomic claim and cite its direct object.
• Performed Work (A.15.1): whether one exact dated Work occurrence happened, with its performer system, covering assignment, enacted method, extent, and containing system. This claim supplies no result, delivery, or acceptance by itself.
• Result or consequence (A.15.1:4.6 dispatch): only when current, name the exact A.6.1 application/result binding or subject-specific WorkResultRelation, A.15.PROD production branch, A.3.4 change, evaluation result, delivery/transfer relation, or acceptance relation.
• Evidence (A.10): only when a receiving use relies on one of those claims, name the claim-bound evidence path and carrier. Evidence supports that claim; it creates neither Work nor its result.

In A.6 terms:

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

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

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

#Where statements go (classification examples)

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

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

Notes:

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

#Classification sanity rules (informative, concept-level)

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

• RFC keyword inside Definition, invariant, or admissibility predicate → classification error (rephrase as predicate; move obligation to D-*).
• E-* with no exact actual occurrence or evaluated predicate, or with a carrier but no evidence relation for the claimed use → incomplete effect/evidence claim. Ground Work through A.15.1 only when it actually obtains; otherwise use A.3/A.3.4 or the exact interaction/causal owner. A carrier supports the claim but does not create the effect.
• D-* that re-states an A-*/L-* predicate instead of referencing its ID → drift risk (prefer “MUST satisfy A-…”).
• A face introduces new L/A/D/E content not present in the canonical claim set → view-fork (make it informative only, or repair the exact direct object and classify its claim: duty/commitment/grant in D; exercise/evaluated finding/evidence in E; gate in A).
• “The system or service SHALL …” where no accountable role assignment or admitted acting system is named → likely misclassified deontic (rewrite as E-* behavior + D-* duty on implementers and operators).

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

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

#Tell (universal rule)

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

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

System: A “Payment Authorize” service.

• Signature layer (A.6.0).

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

• Mechanism layer (A.6.1).

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

• Actual occurrence and work layer.

  • The payment-handling occurrence is U.Work only when its admitted performer system, covering assignment, enacted method, time, and containing system are grounded through A.15.1.
  • The ledger reservation change, event emission, timer transition, or retry effect is a separate actual-occurrence claim under A.3/A.3.4 or its exact interaction/causal owner. Check each effect separately: knowing that the payment Work occurred does not show that the ledger changed, an event was emitted, or a retry happened.
  • Traces, logs, and metrics enter an A.10 evidence path for the exact effect being relied on; carrier presence creates neither Work nor change.

• Publication faces (MVPK).

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

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

Classification example:

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

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

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

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

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

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

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

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

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

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

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

#Bias-Annotation

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

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

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

A boundary is simultaneously:

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

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

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

#SoTA-Echoing (post-2015 practice alignment)

Informative. Alignment notes; not normative requirements.

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

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

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

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

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

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

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

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

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

#Relations

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

#Quantum-like boundary-claim classification note

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

Action classification:

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

Minimum boundary discipline before a quantum-like boundary reading:

Useful outputs:

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

#A.6:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)