#Signature Stack & Boundary Discipline

A.6 · Stable · Architectural (A) · Mixed (normative only where explicitly marked; routing 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-memory 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; routing 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 (U.EpistemicViewing — views as episteme-level projections under viewpoints), E.17.0 (U.MultiViewDescribing), E.17 (MVPK — fixed face kinds & “no new semantics” publication), A.7 (Object≠Description≠Carrier), F.18 (promise/utterance/commitment), E.10.D2 (I/D/S vs Surface), E.10/L‑SURF (Surface token discipline) Purpose (one line): Keep boundary claims evolvable by routing each statement to 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 existing FPF meanings of U.View/U.Viewpoint (E.17.0/A.6.3) and reserves “Surface” for PublicationSurface/InteropSurface (L‑SURF). The labels L/A/D/E used below are routing 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 routed claim set. If anything in this overview conflicts with A.6.B, A.6.B is authoritative.

Start here when. The dominant question is an API, protocol, contract, compliance, SLO/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 routed atomic claim set with stable L-* / A-* / D-* / E-* identifiers, stack placement, and face citations by ID rather than paraphrase.

Boundary-routing load posture. Use only as much routing structure as the live stronger use requires. Split a statement only where one sentence carries more than one claim kind, governing source, or stronger-use consequence, or where evidence, gate, duty, assurance, work occurrence, or admissible action would otherwise remain ambiguous. For a local first-pass repair, an equivalent routed 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.9, or A.15.1. Do not atomize ordinary modifiers when one governing source and one stronger-use consequence are already clear.

Typical next governing patterns/sources. A.6.B for the quadrant semantics, A.6.C for contract unpacking, A.6.P, A.6.Q, or A.6.A for lexical repair, and E.17 faces for audience-specific publication of the same routed claim set.

Common wrong escalations / reroutes. If the real object is still cue preservation or early route-bearing articulation, reroute to A.16 / A.16.1; if a qualified relation, quality term, or action invitation is itself being repaired, continue into A.6.P, A.6.Q, or A.6.A; if agent duties are being mixed into one contract sentence, split them through A.6.B rather than minting one more contract-soup paragraph.

Causal/deontic split. A mixed boundary sentence such as "deploy because it would reduce harm" is not owned by one hidden pattern. C.28 carries the causal-use question, rung, estimand, support basis, support verdict, and supported/unsupported causal use. A.6.B routes deontic duties, boundary admissibility gates, and work-effects as atomic L/A/D/E claims. A.6.C unpacks contract, promise, commitment, utterance, and boundary-publication language when the sentence is agreement-like or release-facing. A causal support record does not by itself create a duty, commitment, promise, release gate, or boundary admissibility predicate.

Authority wording split (subordinate boundary-claim stress case). When a boundary, policy, API, schema, connector, or compliance statement uses "approved", "allowed", "authorized", "guaranteed", "certified", "recommended", or equivalent wording, do not decide by the word. The object under repair is still the routed boundary claim set: split the statement into A.6.B L-* definition/invariant, A-* admissibility/gate, D-* commitment, and E-* evidence/work-effect claims before treating it as action guidance. When "guaranteed", "promise", "contract", "SLA", "SLO", or certified-under-agreement wording is agreement-like, service-facing, promise-bearing, or release-facing, unpack promise content, utterance package, deontic commitment, and work/evidence substrate through A.6.C, A.2.3, A.2.8, and A.2.9 before using the routed claims. When "recommended" wording is cue, advice, or action invitation, route to A.16 / A.16.1 or A.6.A; when it is an admissibility criterion, route to A-* and any live A.21 gate decision; when it is evidence-supported advice, route to E-* plus A.10; only recommendation-as-duty routes to D-* / A.2.8. If the encountered item is a dashboard/status display rather than boundary prose, do not turn color, label, or visible status into an A-* admissibility claim; return through A.15, A.10, and, when a gate decision is live, A.21. If the split result will guide work, release, permission, role/status reliance, evidence reliance, or assurance, return through A.15 to the exact source exit.

Positive repaired path. A repaired boundary statement is not merely "less vague"; it is a routed claim set that tells the user which statement is definitional, which is an admissibility predicate, which is a deontic commitment, which is an evidence/work-effect claim, and which exact source must be cited before action or reliance proceeds.

Credential-currentness boundary. A displayed credential can support only issuer/holder/verifier/status/currentness after an A.10 evidence path verifies it for the relying context. Boundary permission, admissibility, authorization, deontic commitment, role/status effect, or gate passage still needs the exact A.6.B, A.2.8, A.2.9, A.2.1, or A.21 source.

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

Adversarial wording guard. Do not let intentionally ambiguous "allowed", "approved", "authorized", "certified", "recommended", or "guaranteed" wording collapse L-*, A-*, D-*, and E-* claims. Split the boundary statement first, then route action, evidence, gate, commitment, and assurance use to the exact supporting source.

Lint trigger. In boundary/API/schema/policy text, approved, authorized, allowed, guaranteed, certified, or recommended should trigger the A.6 split: identify the L-*, A-*, D-*, and E-* claims, then cite the exact source before action, evidence, gate, commitment, or assurance use.

Boundary-source repair route. If splitting boundary wording exposes a missing or broken L-*, A-*, D-*, or E-* source, route repair to the accountable boundary source role: boundary author, policy/schema maintainer, gate source, commitment source, evidence-carrier source, or publication face maintainer. Keep only cue/source-finding or bounded reversible use available until that source is exposed or repaired.

Role prompts for boundary wording use:

Recurring boundary ambiguity repair. If the same boundary/API/schema/interface wording repeatedly needs the same split or source recovery, repair the boundary package rather than making each user reinterpret it: replace misleading labels, expose routed claim IDs, cite the gate/commitment/evidence/work-effect source, add currentness or supersession refs, or remove the phrase that invites unsupported stronger use. Repetition is a signal that the boundary source or publication face needs repair, not a normal per-use task.

Display guidance for boundary wording: a publication face, API doc, schema page, connector card, or compliance statement that uses approval-, authorization-, permission-, recommendation-, certification-, or guarantee-like wording should expose the routed L-*, A-*, D-*, and E-* claim IDs, the source for each live stronger use, freshness/supersession refs where currentness matters, and unsupported stronger uses. If it cannot expose those, keep the wording as source-finding or repair the boundary package.

Incident-learning fields for boundary wording overread: displayed phrase, intended stronger use, missing or ambiguous routed claim ID, exact L-*/A-*/D-*/E-* source needed, plausible overread, safe disposition used now, and upstream repair item for labels, routed claim IDs, source refs, currentness/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/should” in explanatory prose is descriptive, not normative.

Statement identifiers (recommended): Adopt the quadrant‑prefixed ID scheme from A.6.B:0 for routable statements: L-* (law/definition), A-* (admissibility gate), D-* (deontic/commitment), E-* (effect/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” anchors (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 routed 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‑artifact in A.6.B:7. In this cluster the register is additionally used to record stack placement (Signature/Mechanism/Norms/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

• boundary
• signature stack
• boundary route fields
• A.6.B L/A/D/E claims
• authority-wording split
• promise/commitment/API/policy wording
• probe/order/frame/export/state-reading claims.

#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 publication discipline via U.MultiViewDescribing (views + viewpoints).
• Strict separation of Object vs Description vs Carrier so we do not accidentally attribute agency or work to an episteme (or treat a file as “the thing”).

Yet boundary descriptions in practice fail in a predictable way: authors blend several fundamentally different kinds of claims into one “contract soup”. 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/evidence story.

This cluster overview makes one disciplined move:

1. Treat a boundary as a stack of boundary layers (Signature → Mechanism → Work/Evidence carriers) plus publication views/faces, and
2. Provide a boundary discipline matrix (2×2) that routes statements to the correct 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 → Work/Evidence carriers → Publication).
• View (U.View) is an episteme‑level projection, not a file/document.
• Viewpoint (U.Viewpoint) is an intensional accountability spec that constrains views.
• Face (MVPK sense) is a named publication view kind (PlainView, TechCard, InteropCard, AssuranceLane) whose rendering lives on a PublicationSurface (carrier). Do not coin “signature/mechanism …Surface” terms; “Surface” is reserved for publication surfaces (L‑SURF).

#Problem

When boundaries are described without a routing 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/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 intended use/bounded context; it is not a runtime entry gate. Runtime entry checks and permission predicates belong in U.Mechanism.AdmissibilityConditions as A-*. If an agent is obligated to satisfy/enforce such a gate, express that as a D-* duty that references the A-* claim ID (per A.6.B), not by rewriting the gate as “X MUST …”.

2. Admissibility vs deontics. “MUST/SHOULD/MAY” is used both for agent obligations and for world‑state admissibility predicates. E.8 already demands keeping deontics distinct from admissibility/definitions and recommends predicate‑style constraints for admissibility rather than RFC keywords.

3. Contract talk category errors. “The interface promises…” is a metaphor. A promise (and a contract) is an agent‑level phenomenon; an episteme is an utterance; a running service is the delivered work. FPF provides an ontological anchor for this via promise/utterance/commitment distinctions (F.18).

4. Effects without evidence or carriers. Effects happen only in work; therefore, “effect claims” must be anchored to observation and carriers. Without A.7’s Object≠Description≠Carrier discipline, writers conflate the published description with runtime traces or treat a file as the system itself.

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

#Forces

#Solution — A stack + a routing matrix

#Why “stack”: what is stacked, and what “higher/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/evidence. “Higher” and “lower” are not metaphysical claims; they are engineering guidance for evolvability:

• Higher in the stack = closer to public, reusable intent (conceptual contract).
• 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 “landing zone” for one quadrant of statements (L/A/D/E), with a canonical boundary artefact/section that carries those statements:

1. Signature layer (L: laws/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/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/Observability block defines the required semantics of an observability/evidence interface (carrier classes and required fields, correlation keys, exposure interface). Retention/access/enforcement are D‑claims (agent duties) that reference the same carrier classes by ID. An MVPK AssuranceLane is a projection for auditors that explains how to read/check the evidence interface. This is a special case of CC‑A.6.6: the lane references the Mechanism section and the relevant claim IDs rather than restating semantics.

3. Norms & commitments layer (D: duties/commitments). Deontic statements are anchored to accountable agents/roles (authors, implementers, operators, providers, reviewers). Canonical placement is a Norms/Commitments section in the boundary package (typically rendered inside TechCard), and those statements reference L-*/A-*/E-* by ID rather than duplicating predicates.

4. Evidence bindings layer (E: effects/evidence). E-* claims bind observed behaviour to carrier classes and measurement conditions. Canonical placement is an Evidence/Carriers section in the boundary package (typically rendered in AssuranceLane), and adjudication happens against carriers produced in work.

5. Work & realizations (outside the description stack). Realizations (substitutable implementations) are exercised by doing work; actual executions produce state changes, traces, and measurements. Effects exist only in work. A.6.0 already frames realizations as substitutable behind signatures and warns against smuggling bridge mechanics into the signature layer.

6. Publication faces (MVPK views rendered on PublicationSurfaces). MVPK yields audience‑specific U.View instances (faces) that are typed projections over the canonical claim layers above and carry viewpoint accountability (viewRef + viewpointRef). Physical documents/files live on carriers (PublicationSurface), not in the U.View itself.

Observability compatibility note (informative): When specifying evidence carriers and correlation rules, it is often convenient to describe the carrier layer in terms familiar from contemporary observability practice (post‑2015): traces/spans, logs/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/Observability semantics.

Minimal content (suggested):

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

No new semantics reminder. The lane may include procedural adjudication guidance (queries, joins, dashboards) as informative text. Any normative thresholds/criteria that would change the boundary’s commitments MUST be authored as E-* claims in the canonical Evidence/Carriers section and cited by ID, rather than being introduced only inside the lane text.

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/Auditor pipeline"
        correlation: ["traceId", "requestId"]
      adjudication:
        check: "query audit stream for code=NotAdmissible and join to traceId"
        criteriaRef: "E-OBS-1 (pass/fail lives canonically in the E-claim)"
      references: [A-AC-1, D-RET-1, Mechanism.AuditObservability]

Default landing zones (quadrant → stack layer / section):

• L → Signature.Laws (and, where appropriate, mechanism‑local semantic laws; never runtime gates)
• A → Mechanism.AdmissibilityConditions
• D → Norms/Commitments (agent/role duties; publication/accountability duties)
• E → Evidence/Carriers (claims adjudicated against work via carriers; the publication face for these is typically AssuranceLane)

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

• A.6.1 ↔ A‑quadrant: U.Mechanism.AdmissibilityConditions is the canonical claim layer for A-* gate/admissibility claims.
• A.10 / B.3 ↔ E‑quadrant: E-* claims should be anchored to evidence carriers + provenance (A.10); without an explicit evidence anchor they are treated as AssuranceLevel:L0 (Unsubstantiated) in the Trust & Assurance calculus (B.3).
• A.2.3 / 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/or E-* by ID.

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 contract evolution and typically require explicit compatibility reasoning (and therefore explicit versioning and communication).

#Boundary Discipline Matrix: route 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 not strong enough, because real sentences reuse the same visible words (“must”, “guarantees”, “valid”) across different logical roles. A 2×2 matrix is stronger because it arises from crossing two independent distinctions:

• Modality family: truth‑conditional vs governance (permissions/obligations/commitments).
• Adjudication substrate: in‑description vs in‑work (whether satisfaction is decided from the description alone or requires observing executed work/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 / permission checks)
• D (Deontics & Commitments) → Norms/Commitments (agent/role duties and commitments; may be audited via E-*)
• E (Work‑Effects & Evidence) → Evidence/Carriers (work‑adjudicated effects tied to carriers and measurement conditions)

Atomicity rule:

If a sentence mixes roles (e.g., “MUST” + a gate predicate + an effect claim), it is not routable 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 → Route → Place → Anchor (A.7) → 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/artefact (stack layer + section).
4. Anchor A.7: for each claim, name the primary A.7 layer it is about (one of {Object, Description, Carrier}) and ensure the grammatical subject matches (agents/roles for D-*, carriers for E-*).
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 routing:

• implement or repair an admissibility predicate when the live claim is A-*;
• assign, remove, or clarify an accountable role/commitment when the live claim is D-*;
• add, repair, or expose evidence-carrier instrumentation when the live claim is E-*;
• publish or update an MVPK face that cites routed claim IDs rather than paraphrasing them;
• reopen an A.21 gate decision, A.20 constraint-validity witness, A.2.9 speech act, A.2.8 commitment, A.10 evidence path, or B.3 assurance claim when the routed statement is being used beyond boundary wording;
• downgrade the visible wording to cue/source-finding only when the exact source is missing;
• keep the action local, reversible, or blocked only for the unsupported stronger use while the source is repaired.

Informative example. Example rewrite (mixed → atomic):

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

After (routeable + lintable):

• A-AC-1 (Quadrant A, Mechanism.AdmissibilityConditions): admissible(req) iff hasHeader(req, "X").
• D-CL-1 (Quadrant D, Norms/Commitments): “Client implementers MUST satisfy A-AC-1.”
• E-OBS-1 (Quadrant E, Evidence/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 soup): “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 (routeable + adjudicable):

• D-SLA-1 (Quadrant D, Commitments/SLA): “Provider SHALL meet E-SLA-AVAIL-1 and E-SLA-LAT-1 under the stated exclusions.”
• E-SLA-AVAIL-1 (Quadrant E, Evidence/Carriers): “availability ≥ 0.999 over calendar month T, measured by carrier UptimeProbeSeries from viewpoint VP.ExternalMonitor.”
• E-SLA-LAT-1 (Quadrant E, Evidence/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/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 (routeable + 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/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.

Then:

• if a user is deciding whether the wording may guide action, enter A.15;
• if evidence/currentness/provenance is live, attach the A.10 path;
• if trust/readiness/compliance/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 or constraint witness is asserted, cite A.20 ConstraintValidity status/witness;
• if release, deployment, rollback, or execution work is asserted, cite A.15.1 dated U.Work occurrence plus its A.10 evidence carrier path;
• if the phrase is only an action invitation or cue, keep it in A.6.A or A.16 / A.16.1.

Policy-as-code, dynamic authorization, credential, provenance, attestation, and assurance practices support complementary parts of this split: policy engines support bounded authorization decisions; credentials support issuer/holder/verifier/status claims; provenance and attestation support bounded origin/process claims; assurance practice supports claim-argument-evidence confidence claims. None of them lets wording, a displayed credential, a provenance label, or a schema cue stand in for the exact subject, action, affected object, context, policy/gate version, evidence refs, validity/revocation window, gate decision, or work occurrence needed for stronger reliance.

#Viewpoint is not optional: projections live under accountable viewpoints

“Projection” language is useful (a view is a projection), but FPF does not drop viewpoint. U.MultiViewDescribing makes viewpoints explicit and treats views as epistemes; MVPK specialises this for publication and fixes a closed set of face kinds (PlainView, TechCard, InteropCard, AssuranceLane) under Surface token discipline (L‑SURF).

A disciplined stack therefore requires:

• Every published face is a Description (A.7) that is about an Object and is carried by some Carrier; do not conflate these layers.
• Each face must declare the viewpoint that justifies its projection (ISO/42010 discipline operationalised by MVPK).
• Per E.17 (“no new semantics”), a face MUST NOT introduce new semantic commitments beyond the boundary’s canonical routed claim set (the authoritative L-* / A-* / D-* / E-* statements at their canonical locations). A face MAY add informative explanation, examples, and cross‑references, provided they are clearly marked as informative. Any normative sentence on a face MUST cite the routed claim ID(s) it depends on (or be moved into the canonical claim set); paraphrase is allowed only as explicitly informative text.
• Per E.17 / L‑SURF (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 multiple distinct things into one word. The core naming split is the F.18:16.1 triad; boundary engineering adds the missing adjudication substrate (see also A.6.C):

• 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/published and versioned (signature/mechanism + MVPK faces), plus the U.SpeechAct <: U.Work that published/approved it when provenance matters (A.2.9).
• Commitment (deontic binding; U.Commitment, A.2.8): what an accountable role/agent is obligated/permitted/prohibited to do (often: to satisfy a promise content).
• Work + Evidence (adjudication substrate; U.Work + carriers): what actually happens and what carriers/traces can adjudicate whether commitments and operational guarantees were met.

In A.6 terms:

• The signature is the utterance substrate for the boundary; it is not itself a promiser or obligor (A.7).
• Deontics belong to accountable roles/agents and should be expressed as D-* commitments (U.Commitment) that reference L-*/A-*/E-* by ID (A.6.B, A.2.8).
• Operational “guarantees” are empty rhetoric unless they are routed as either L (truth‑conditional law), D (agent commitment), or E (measured property with evidence).

This paragraph is a compact reminder; the reusable expansion (including “Service ≠ Work” discipline, claim‑ID link hygiene, and MVPK face projection rules) is A.6.C — Contract Unpacking for Boundaries.

#Where statements go (routing examples)

Informative. Routing 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 routing 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 an agent/role (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.

#Routing 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/Admissibility predicate → routing error (rephrase as predicate; move obligation to D-*).
• E-* without (carrier + measurement conditions + viewpointRef) → incomplete evidence claim (cannot be adjudicated).
• 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 underlying Signature/Mechanism → view-fork (make it informative only, or move the commitment to the underlying artefact).
• “The system/service SHALL …” where no accountable agent is named → likely misrouted deontic (rewrite as E-* behavior + D-* duty on implementers/operators).

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

Informative. Worked examples for learning the routing 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 routed by the boundary discipline matrix to its proper layer (Laws, Admissibility, Deontics/Commitments, Effects/Evidence), while preserving Object≠Description≠Carrier separation.

#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/Observability: specifies required evidence carriers (e.g., AuthorizationRecord event, log entry) and their semantics (fields, correlation IDs, retention class).

• Realization/work layer.

  • Actual side effects: reservation entry in ledger, emission of event, timers, retries.
  • Evidence: traces, logs, metrics.

• Publication faces (MVPK).

  • PlainView: narrative for stakeholders (what the service promise is, in plain terms).
  • TechCard: signature/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/access duties by reference).

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

Routing example:

• “Defined iff tokenValid” belongs in Quadrant A (admissibility gate).
• “Clients MUST include Idempotency‑Key” belongs in Quadrant D (agent 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/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 an agent commitment).

• Effects/evidence: the produced report file, logs of evaluation runs, cryptographic hashes, and trace IDs are carriers. A.7 discipline prevents calling the report “the evaluation” (object) and prevents treating the file as the model.

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

  • PlainView for decision makers: what this protocol means for assurance.
  • TechCard for engineers: exact metric definitions, admissibility predicates, and a clearly marked Norms/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, Onto/Epist, Prag, Did. Scope: Universal for boundary descriptions in A.6.*.

• Arch bias: Strongly 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.
• Onto/Epist bias: Treats signatures/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 interface description (stable intent, evolvable implementations),
• a governance object (commitments, responsibilities, deontics), and
• an operational phenomenon (effects happen only by doing work and observing traces).

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 routing 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 & 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/behavioural types for protocol boundaries. Post‑2015 practice in behavioural typing treats boundaries as typed interaction protocols with progress/safety properties. A.6’s routing matrix makes “protocol laws” (Quadrant L) explicit and separates entry gates (Quadrant A) from agent duties (Quadrant D) and runtime evidence (Quadrant E), reducing ambiguity.

• Adapt — categorical optics / lenses / bidirectional transformations. Contemporary lenses treat boundaries as paired transformations with coherence laws; this mirrors the signature/mechanism split plus cross‑context view morphisms. In FPF, the “projection faces” (views) remain governed by viewpoints, and any cross‑context reuse must remain explicit (Bridge/CL discipline).

• Adapt — ISO/IEC/IEEE 42010 viewpoint discipline and views‑as‑queries (SysML v2 motif). A.6 explicitly preserves viewpoint as a first‑class accountability handle: MVPK requires viewRef and viewpointRef, turning “views” into disciplined projections rather than informal screenshots.

• Adapt — DDD bounded contexts / microservice contracts. Modern architecture practice keeps meaning local and makes crossings explicit. A.6’s stack and routing discipline provide a precise placement scheme for what is “inside the context contract” vs “at the entry gate” vs “governance duties” vs “observability evidence”.

• Adapt — observability as evidence discipline. Post‑2015 observability practice treats traces/logs/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/schema text from a decision over subject, action, affected object/resource, context, policy/gate version, decision source, and evidence. Cedar-style policy language and Zanzibar-style relation authorization are useful practice anchors for this split: the wording is not the decision. A.6 keeps policy/API/schema wording in routed L-* / A-* / D-* / E-* claims and sends action reliance back through A.15 rather than letting "allowed" or "authorized" wording decide by itself.

• Adopt/adapt/reject stance for authority-looking boundary wording. A.6 adopts policy-as-code separation of policy text from evaluated decision, adapts credential/provenance/attestation practice as source, evidence, and currentness support rather than as the L/A/D/E split itself, and rejects visible wording, schema cues, credential displays, or provenance labels as permission, gate passage, work occurrence, evidence, or assurance by themselves.

• Adapt — Markov blankets / active inference as probabilistic boundary views. Markov‑blanket thinking can help pick observables and diagnose “boundary leaks”, but it does not replace deontics, invariants, or admissibility gates; therefore it is a complementary view under a viewpoint, not the primary boundary-description object.

#Relations

• Implements authoring discipline: Follows canonical section order and style expectations from E.8.
• 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 Object≠Description≠Carrier discipline: Uses A.7 to prevent category mistakes; ties evidence to carriers and publication faces to descriptions.
• Operationalises view/viewpoint accountability: Uses MVPK / U.MultiViewDescribing (E.17.0) so each face is a projection under a viewpoint, not a viewpoint‑free snapshot.
• Unpacks “contract” talk: Reuses F.18’s promise/utterance/commitment separation to keep agency and responsibility explicit.
• Connects to signature engineering patterns: A.6.5 (slot discipline) and A.6.6 (anchor/base discipline) can be read as “constructor/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 support to justify deployment, release, duty, commitment, or admissibility, A.6 splits the boundary sentence while C.28 carries the causal-use question, rung, estimand, support basis, support verdict, and supported/unsupported causal use.
• Coordinates with A.15, A.10, B.3, A.21, A.20, and A.15.1: When routed boundary wording is then used for action/reliance, evidence/currentness/provenance, assurance strength, gate decision, constraint-validity witness, or release/deployment work occurrence, the stronger use is carried by the exact source: A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef; A.20 for ConstraintValidity status/witness; A.15.1 for dated U.Work occurrence.

#Quantum-like boundary-route 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/state-reading distinction that ordinary boundary routing would otherwise erase.

Action path:

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. Route the ordinary boundary content through A.6/A.6.B/F.9/A.15/C.16/C.25 as applicable.
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, route only that remaining residual question through C.26.1; keep the ordinary boundary pattern active.
7. If no, keep the text in the ordinary boundary/bridge/work/measurement/quality pattern and remove QL wording.

Minimum boundary routing before a quantum-like boundary reading:

Useful outputs:

• a routed 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 through A.6.P / F.18 when coupling words become reusable relation candidates.

#A.6:End