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

Preface node heading:a-6-b-boundary-norm-square-laws-admissibility-deontics-work-effects:6984

#Content

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.6.B (matrix module; referenced by A.6 cluster overview) Builds on: E.8 (authoring template), A.6.0 (U.Signature), A.6.1 (U.Mechanism), A.6.3 (U.EpistemicViewing), E.17.0/E.17 (MVPK + “no new semantics” faces), A.7 (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): Provide a canonical 2×2 norm square that classifies boundary statements (L/A/D/E), constrains how each quadrant is written, and defines explicit cross‑quadrant reference rules so boundaries remain evolvable and audit‑ready.

#A.6.B:0 — Conventions

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

Quadrant labels. This pattern uses the routing labels L / A / D / E as statement quadrants:

• L — Laws & Definitions
• A — Admissibility & Gates
• D — Deontics & Commitments
• E — Work‑Effects & Evidence

These labels are routing labels for statements, not MVPK face kinds and not pattern identifiers.

Statement identifiers (recommended). Routable statements SHOULD be given stable IDs with a quadrant prefix: L-*, A-*, D-*, E-*. Other sections and views SHOULD reference these IDs rather than restating the same constraint in new words.

Non-collision note (informative). The A-* prefix here is “Admissibility”, not Part‑A numbering and not MVPK’s AssuranceLane face kind. If this is a readability hazard in your program, prefer an explicit G-* (“Gate”) local convention while keeping the quadrant name “Admissibility”. Also avoid introducing single‑letter mnemonics for MVPK face kinds inside this cluster (MVPK has a legacy L,P,D,E mnemonic); spell face kinds in full to reduce collisions.

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

Adjudication substrate (for routing). For the purposes of this square, an atomic claim is classified by the primary substrate that decides its satisfaction:

• In‑description / in‑theory: satisfaction is decided from the description alone (e.g., proof/type validation), or the claim is itself a governance utterance whose content is fully determined by the text.
• In‑work / in‑execution: deciding satisfaction requires observing executed work and/or inspecting carriers produced in work.

Note (important). D-* claims are authored and interpreted in the description; whether they are met is typically established indirectly via referenced E-* claims (or other governance procedures). This does not move D-* into quadrant E; it clarifies the routing axis.

Modality family. A claim is either:

• Truth‑conditional: definitions, invariants, typing rules (“is”, “iff”, “∀”).
• Governance: permissions, prohibitions, obligations, commitments (“MUST/SHOULD/MAY”, “is permitted”, “is forbidden”, “commits to”).

#A.6.B:1 — Problem frame

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

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

#A.6.B:2 — Problem

When authors cannot reliably answer two questions—

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

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

A boundary needs a minimal, stable classification that:

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

#A.6.B:3 — Forces

#Solution — the Boundary Norm Square

#Two independent distinctions

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

1. Modality family: Truth‑conditional vs Governance
2. Adjudication locus: In‑description vs In‑work

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

#A.6.B:4.2 — The square

Clarification (do not conflate). The Governance column includes two different “normative” roles:

• D is agent/role governance (duties, commitments, prohibitions).
• A is mechanism governance (permission/admission predicates: what the mechanism admits at application time). A-* is not an obligation on an actor; obligations belong in D-* and may reference A-*.

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

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

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

The quadrants have canonical “homes” in the boundary stack:

• L → Signature layer: U.Signature.Laws (and mechanism‑local semantic laws if present).
• A → Mechanism layer: U.Mechanism.AdmissibilityConditions (entry gates / runtime permission predicates).
• D → Norms & commitments layer: role‑anchored duties, commitments, publication/accountability duties (often rendered inside MVPK TechCard).
• E → Evidence bindings layer: work‑adjudicated effects tied to carriers and measurement conditions (authored canonically in an Evidence/Carriers section; commonly rendered inside MVPK AssuranceLane as a projection).

A published view MUST NOT introduce new semantic claims outside this routed claim set. E.17 (MVPK) is a specialization that enforces this rule for a fixed set of publication face kinds.

#A.6.B:5 — Quadrant specifications

This section is the normative “API” of the square: what each quadrant is for, how it is written, and what it must not contain.

#A.6.B:5.1 — Quadrant L: Laws & Definitions

Intent. State truth‑conditional content: definitions, invariants, typing/well‑formedness constraints, equational laws.

Adjudication. In‑description: can be checked by inspection, proof, type validation, or model reasoning.

Canonical form. Definition: / Invariant: / predicate‑style constraints using “is / iff / for all”.

Prohibitions.

• An L-* statement MUST NOT contain RFC deontic keywords (MUST/SHALL/SHOULD/MAY) as operators inside the law/definition itself.
• An L-* statement MUST NOT encode runtime gate predicates (those are A-*).
• An L-* statement MUST NOT assert evidence availability or measurement outcomes (those are E-*).

A.7 anchoring. L-* claims are Descriptions: they specify semantics of the signature/mechanism description, not work.

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

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

Intent. Specify when a mechanism application is permitted/admissible: runtime entry predicates, authorization gates, validity gates, applicability checks that require context or execution environment.

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 your prose reads like “clients must satisfy the applicability”, you almost certainly want a D-* duty + an A-* gate (linked by ID) instead.

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

Canonical form. Predicate style, e.g.:

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

Prohibitions.

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

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

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

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

Intent. State governance: obligations, permissions, prohibitions, commitments, publication duties, operational duties, contractual commitments—always with accountable agents/roles.

Adjudication. In‑description (governance is stated in the spec); compliance may be audited via E-*.

Canonical form. A deontic statement MUST have an accountable subject (agent/role), e.g.:

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

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

• id (often the D-* claim ID),
• subject (accountable role/party; never an episteme),
• modality (BCP‑14/RFC keyword family normalized),
• scope + validityWindow,
• referents (by ID; e.g., SVC-*, L-*, A-*, E-*, MethodDescriptionRef(...)),
• optional adjudication.evidenceRefs when the commitment is meant to be auditable,
• optional source when authority/provenance matters.

Prohibitions.

• A D-* statement MUST NOT use “the system/service/interface/spec” as the grammatical subject unless the accountable role/party is explicitly named (so the statement is representable as a U.Commitment with an explicit subject, A.2.8). (F.18 is a lexical anchor only.)
• A D-* statement MUST NOT restate L-* or A-* predicates in new words when an ID exists; it SHOULD reference the ID.
• A D-* statement MUST NOT pretend that commitments are laws. A commitment is an agent relation, not a truth‑conditional invariant.

A.7 anchoring. D-* claims are primarily about Objects (roles/agents and their duties) or about Carriers (retention/exposure duties), but they are still written as Descriptions.

Required references (explicit).

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

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

Intent. State what happens in work and how it can be evidenced: observed effects, emitted events, traces/logs/metrics, produced reports, measurement outcomes.

Adjudication. In‑work: checked by running/operating and inspecting carriers produced in work.

Canonical form. An E-* statement SHOULD include the minimum fields needed for adjudication:

1. Observation/measurement conditions (when/where/how observed; workload/window; triggers)
2. Carrier class/schema reference (A.7 Carrier) that bears the evidence
3. Viewpoint/consumer (who uses this evidence and why; ties to viewpointRef discipline)

Prohibitions.

• E-* statements SHOULD NOT use RFC deontic keywords (they are not obligations; they describe adjudicable effects/evidence).
• An E-* statement MUST NOT hide a gate predicate; gate predicates are A-*.
• An E-* statement MUST NOT assign agency (“the interface guarantees …”); if enforceability/commitment is intended, express it as D-* referencing the E-*.

A.7 anchoring. E-* claims are primarily Carrier‑anchored: they assert what carriers exist and how they relate to observed work.

Required references (explicit).

• If the effect/evidence is conditioned on a gate decision, the E-* statement SHOULD reference the relevant A-* ID(s).
• If the evidence is interpreted using metric definitions or invariants, the E-* statement SHOULD reference relevant L-* ID(s).

#A.6.B:6 — Cross‑quadrant link discipline

The square is not just classification; it is a dependency discipline. Claims often depend on each other; such dependencies MUST be explicit (by claim ID) rather than duplicated prose.

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

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

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

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

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

#(D → A) Duty-to-gate linkage

When governance requires someone to comply with a gate:

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

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

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

When gate decisions must be observable:

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

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

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

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

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

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

#(A/E → L) Semantic grounding linkage

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

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

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

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

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

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

This keeps governance text from accidentally redefining semantics in prose.

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

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

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

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

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

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

Normative rule (no upward dependencies).

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

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

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

A Claim Register is a drift‑control device that lists every routable statement verbatim with routing metadata. It is not a new semantic layer.

Guidance (informative):

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

#Archetypal Grounding (Tell–Show–Show)

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

#Tell (universal rule)

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

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

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

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

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

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

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

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

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

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

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

#Goal

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

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

#Micro-procedure (Atomize → Route → Triangle → Link → Anchor → Recompose)

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

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

• L if the claim is truth‑conditional and adjudicable in‑description (inspection, proof/type validation, or model reasoning over declared assumptions): definitions, invariants, typing/well‑formedness constraints.
  Guardrails: L-* MUST NOT (i) use RFC deontic keywords as operators, (ii) encode runtime entry predicates (those are A-*), or (iii) assert evidence existence/measurement outcomes (those are E-*).
• A if it is an in‑work gate predicate: what the mechanism admits/permits at application time (“admissible iff …”). It is not a duty and MUST NOT be phrased as one.
  Guardrails: A-* SHOULD be written in predicate form and MUST NOT (i) use RFC deontic keywords as if it were an agent obligation, (ii) claim that evidence/carriers exist (that is E-*), or (iii) assign responsibility/enforcement (that is D-*).
  (Do not confuse this with Signature.Applicability: applicability scopes intended meaning/use; it is not a runtime entry gate.)
• D if it assigns duties/commitments to an accountable role/agent (RFC keywords belong here; “the interface/system promises” does not).
  Guardrails: D-* MUST name an accountable subject and SHOULD reference L-*/A-*/E-* by ID rather than restating them in new words (to prevent paraphrase drift).
• E if it is an in‑work truth‑conditional claim about adjudicable effects/evidence: what carriers exist, under what observation conditions, and/or what was observed.
  Minimum fields (recommended): (1) observation/measurement conditions, (2) carrier class/schema reference, and (3) viewpoint/consumer.
  Guardrails: E-* SHOULD NOT use RFC deontic keywords, MUST NOT hide a gate predicate (that is A-*), and MUST NOT cite D-*.
  (If the sentence is “Role SHALL measure/retain/expose …”, route that obligation to D, even if it is about evidence.)

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

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

Note (routing sanity). D-* claims are authored in the description even when their compliance is audited via E-* claims. Auditing via evidence does not move D-* into quadrant E.

Guideline. Keep gate semantics independent of specific evidence carriers: write the gate predicate in A-*, then bind observability in E-* that references the gate (E → A). A-* claims MUST NOT reference E-* (no upward dependencies), even though E-* is used to adjudicate gate satisfaction.

Step 4 — Link by ID, not by paraphrase. Allowed directions (no upward deps):

• A-* may cite L-*
• E-* may cite L-* and A-*
• D-* may cite L-*, A-*, E-*
• Forbidden: L-* citing anything; A-* or E-* citing D-*.

Common link motifs (informative). The most reusable boundary rewrites use the canonical motifs: D→A, E→A, D→E, A/E→L, and D→L.

Step 5 — Anchor (minimal A.7 discipline).

• Anchor L claims in Signature.Laws (and mechanism‑local semantic laws if present), and A claims in Mechanism.AdmissibilityConditions.
• Anchor D claims to accountable roles/agents and prefer ID references (no restatement of L-* / A-* content in new words).
• Anchor E claims to carriers + observation conditions and SHOULD include viewpoint/consumer (minimum: conditions + carrier class/schema + consumer/viewpoint).

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

Step 6 — Recompose into readable text. Produce two surfaces:

• Tech surface: a short routed claim bundle (sometimes called a “contract skeleton”) listing routed claims + ID references.
• Plain surface: a one-paragraph narrative that summarizes the bundle and points to IDs (no new semantics). If you need a new constraint, add a new atomic routed claim; do not smuggle it into Plain.

#Anti-pattern (quick)

• AP-1 Evidence-free guarantees. “X guarantees Y” with no E-claims.
• AP-2 Interface-as-promiser. Non-agent objects “promise/commit”.
• AP-3 Gate-as-evidence. Treating the gate predicate (A) as if it were an observation (E).
• AP-4 Gate-as-law. Entry predicates as signature “laws/definitions” (L) instead of A-*.
• AP-5 Adjective smuggling. “fast/secure/approved/aligned” used instead of qualifiers/slots.
• AP-6 Paraphrase drift. Restating L/A content in D or E with changed meaning (instead of citing by ID).
• AP-7 Deontics in predicates. RFC keywords (“MUST/SHALL/…”) used as operators inside L-* or A-* predicates (should be D-* that references L-*/A-*).
• AP-8 View-fork semantics. Recomposition/face text introduces new L/A/D/E meaning not present in the routed claim set (violates “no new semantics” discipline).
• AP-9 Applicability-as-gate. Using Signature.Applicability (intended use) as a substitute for A-* runtime admission predicates.

#Example 1 — Software engineering (SLO-ish API latency)

#Draft sentence (non-conformant)

“This API guarantees p95 latency < 200ms.”

#Atomize + Route (L/A/D/E)

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

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

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

D-API-01 (Commitment). ServiceOwner SHALL meet the latency target p95_latency < 200ms when A-API-01 holds, adjudicated per L-API-01 using the carriers/observation conditions in E-API-01. (References L-API-01 and A-API-01 by ID; does not restate them.)

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

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

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

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

#Triangle decomposition (explicit)

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

#Readable recomposition

Tech recomposition (contract bundle, short):

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

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

#Example 2 — Mechanical engineering (fit / coaxiality)

#Draft sentence (non-conformant)

“This fit ensures coaxiality.”

#Atomize + Route

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

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

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

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

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

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

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

#Readable recomposition

Tech bundle:

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

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

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

#Draft sentence (non-conformant)

“The project is approved.”

#Atomize + Route

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

A-PRJ-01 (Gate predicate: stage entry). For starting execution work, ExecutionAdmissible(project) holds iff required approvals are present and required prerequisites are satisfied (e.g., risk review completed, budget line exists, key roles staffed). (This is the real “may start work” gate; references L-PRJ-01 for what counts as approvals.)

D-PRJ-01 (Duty). ProjectOwner SHALL not initiate execution unless A-PRJ-01 holds, SHALL keep the approval registry current, and SHALL retain/expose the evidence carriers referenced in E-PRJ-01. (References A-PRJ-01 and E-PRJ-01 by ID.)

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

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

#Readable recomposition

Tech bundle:

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

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

#A compact “recomposition pattern” you can reuse verbatim

#Tech register (2–5 lines)

“This boundary claim is defined by L-…, is applicable only under A-…, is accountable under D-…, and is adjudicated using evidence carriers E-…. Observed status/value is E-… for Γ_time=….”

#Plain register (1 paragraph)

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

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

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for boundary descriptions.

• Arch bias: favors explicit separation and explicit references; mitigated by allowing narrative faces while keeping commitments routed and referenced by ID.
• Gov bias: makes accountability explicit (D) and auditability explicit (E); mitigated by keeping evidence conceptual and carrier‑anchored rather than tool‑specific.
• Onto/Epist bias: insists on Object≠Description≠Carrier and on work‑adjudicated effects; mitigated by providing clear cross‑quadrant link patterns so authors can still express real‑world governance needs.

#A.6.B:10 — Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#A.6.B:12 — Consequences

#A.6.B:13 — Rationale

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

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

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

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

Informative. Alignment notes; not normative requirements.

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

• ISO/IEC/IEEE 42010:2022 (view/viewpoint discipline).

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

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

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

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

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

#A.6.B:15 — Relations

• Used by A.6: supplies the canonical matrix and cross‑quadrant link discipline that A.6 references as “Boundary Discipline Matrix”.
• Constrains A.6.0 (U.Signature): enforces that L-* laws are truth‑conditional and do not include admissibility predicates.
• Constrains A.6.1 (U.Mechanism): enforces that admissibility lives in AdmissibilityConditions (A-*) and that evidence semantics are routed as E-* with carrier anchors.
• Requires A.7: anchors quadrants to Object/Description/Carrier so agency and evidence are not misattributed.
• Interacts with MVPK/E.17: faces are projections that cite routed claims; faces must not mint new semantic commitments.

#A.6.B:End