#A.6.C — Contract Unpacking for Boundaries

Preface node heading:a-6-c-contract-unpacking-for-boundaries:7628

#Content

Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.6 Signature Stack & Boundary Discipline Builds on: A.6 (stack + routing intent), A.6.B (L/A/D/E), A.6.8 (RPR‑SERV) (service‑cluster polysemy unpacking), A.7 (Object≠Description≠Carrier), A.2.3 (U.PromiseContent / promise content), A.2.4 (U.EvidenceRole), A.2.8 (U.Commitment), A.2.9 (U.SpeechAct), A.15.1 (U.Work), E.10 (L‑SERV / LEX‑BUNDLE), E.17 (MVPK “no new semantics” faces), F.12 (service acceptance/evidence discipline) Lexical anchor: F.18 (NQD front for the service (promise) / utterance / commitment triad; naming, not ontology) Mint/reuse (terminology): Reuses “contract / SLA / guarantee” as Plain-level boundary shorthand; mints Contract Bundle as an unpacking lens (not a new entity kind), plus optional register columns (bundleId / bundlePart / faceRefs). NQD-front seeds (informative): contract packet, agreement bundle, boundary bundle (chosen: Contract Bundle for low collision with existing “bundle” terms). Purpose (one line): Prevent “contract soup” and agency misattribution by unpacking contract-language into distinct promise‑content, utterance package, commitment, and work+evidence (adjudication substrate) parts and routing each part into the Boundary Norm Square.

#A.6.C:1 — Problem frame

Boundary descriptions frequently use “contract” as a shorthand for “the thing that governs the interaction”. That shorthand is useful in conversation, but it collapses distinct layers that FPF deliberately keeps separate:

• Promise-level intent (what is promised to be true or provided),
• Published description (what is written and versioned),
• Deontic commitment relation (who is accountable for which obligations/permissions),
• Operational work and evidence (what actually happens and what can be observed).

When these layers are collapsed, authors accidentally assign agency to epistemes (“the interface guarantees…”), encode runtime gates as if they were internal laws, or treat observability as a property of text rather than of carriers and work. A.6 and A.6.B already provide a routing discipline (L/A/D/E) for boundary claims, but “contract” language remains a recurring entry point for category mistakes.

Service-cluster note (modularity + lexicon). Boundary “contract talk” commonly co‑moves with the service cluster (service, service provider, server, SLA/SLO/service‑level). When those tokens appear, their referents MUST be disambiguated per A.6.8 (RPR‑SERV) before (or while) applying the four‑part Contract Bundle below. In particular, U.PromiseContent is promise content and is written in normative prose as promise content (not as bare “service”).

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

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

• define “legal contract” doctrine (offer/acceptance/consideration, jurisdictional enforceability, etc.);
• resolve conflicts between incompatible commitments across scales/contexts (capture them as separate D-* claims and route to conflict/mediation patterns when they exist);
• redefine the core meanings of U.PromiseContent, U.Work, U.SpeechAct, or U.Commitment—it only makes “contract talk” routable into those objects/claims.
• redefine quadrant semantics (L/A/D/E) or cross‑quadrant reference rules; those are defined normatively in A.6.B.

#A.6.C:2 — Problem

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

1. Agency is not misattributed to descriptions (signatures, docs, specs, “interfaces”),
2. Governance statements (obligations/commitments) are distinguishable from admissibility gates and from semantic laws,
3. Operational “guarantees” become adjudicable via explicit evidence expectations, without smuggling evidence into semantics,
4. Multi-view publication (MVPK faces) does not create “multiple contracts” by paraphrase drift?

#A.6.C:3 — Forces

#A.6.C:4 — Solution

A.6.C introduces a Contract Bundle lens for boundary writing. It is not a new foundational entity kind; it is a disciplined way to interpret and rewrite contract-language so it becomes routable under A.6.B.

#A.6.C:4.1 — The Contract Bundle (four-part unpacking)

Whenever a text uses “contract / guarantee / promise / SLA / interface agreement” language, unpack it into four parts:

1. Promise Content (Promise content)

   • The promised value/effect (the promise content) in the intended scope.

• In FPF terms (A.2.3), U.PromiseContent is promise content—a promise content, not an execution event (U.Work) and not (by itself) an accountable deontic binding (U.Commitment).
• Prose head rule (normative). When referring to U.PromiseContent in normative prose, authors SHALL use the head phrase promise content (or service offering clause / service promise clause) and SHALL NOT rely on the bare head noun service. If the surrounding text also talks about endpoints/systems/operations, apply A.6.8 to select facet‑typed phrases (service access point / service delivery system / service delivery work / …) rather than collapsing them into “service”.
  • Recommendation: give the promise-content a stable local ID (e.g., SVC-*) so it can be cited from commitments, gates, evidence, and MVPK faces without paraphrase drift.
• Routing discipline: keep the semantics/definitions of the promised behavior in L; express who is accountable for satisfying the promise as a D claim (U.Commitment) that references the U.PromiseContent (plus any A-*/E-* claims as needed).

2. Utterance Package (speech act + published descriptions)

   • The work occurrence of stating/publishing/approving (a U.SpeechAct <: U.Work, A.2.9) and the utterance descriptions it produces or updates (versioned epistemes on carriers) that host the routed claim set.
   • A speech act may institute/update commitments, but only under an explicit context policy that recognizes that actType as having such institutional force.
   • The published utterance descriptions (signature/mechanism spec + MVPK faces) host routed claims (L/A/D/E). The act is not “the contract”; it is the work occurrence that created/updated the descriptions and (when recognized) the associated commitments.
   • Default interpretation rule (normative). A conformant boundary model MUST NOT infer or assume any U.Commitment objects solely from the presence of a Publish/Approve U.SpeechAct. Publication creates/updates utterance descriptions and MAY institute publication/status claims (e.g., “Published”, “Approved as Standard”, “Deprecated”), but commitments exist only when represented explicitly as U.Commitment records (A.2.8).
   • If a bounded context defines a policy that maps certain publish/approve act types to commitment-instituting effects (e.g., a named SpecPublicationPolicy@Context), the model MUST cite that policy, and any resulting commitments MUST still be represented explicitly as one or more U.Commitment objects with accountable subjects (not inferred from publication alone).

3. Commitment (Deontic accountability relation)

   • The accountable agent/role bound to obligations/permissions/prohibitions (including being accountable for satisfying a promise content).
   • This bundle part is the D‑side commitment object: by default, one or more U.Commitment records (A.2.8).
   • Default checklist (A.2.8 minimal structure):
     • id (stable; often the D-* claim ID),
     • subject (accountable role/party; never an episteme),
     • modality (normalized deontic token / BCP‑14 family),
     • scope (U.ClaimScope) and validityWindow (U.QualificationWindow),
     • referents (by reference/ID: promise content IDs like SVC-*, plus L-*/A-*/MethodDescriptionRef(...)/ServiceRef(...) as needed),
   • referents (by reference/ID: promise content IDs like SVC-*, plus L-*/A-*/MethodDescriptionRef(...)/PromiseContentRef(...) as needed),
     • optional owedTo (beneficiary/counterparty),
     • optional adjudication.evidenceRefs when the commitment is meant to be auditable (point to E-*),
     • optional source when authority/provenance matters (issuer + instituting speechActRef + description reference),
     • optional notes for explicitly informative commentary (not part of the binding).
   • A commitment is not “the spec text”: utterance descriptions carry the statement, but the binding is the U.Commitment object (A.7 / A.2.8).

4. Work + Evidence (Adjudication substrate)

   • The executed work and the observable carriers/traces that can adjudicate whether a commitment was met.
   • This is E quadrant: “what evidence is produced/exposed/retained, under what conditions, and how it is interpreted”.
   • Work is not “the contract”; it is what makes any operational claim testable.
   • In FPF terms, evidence is normally expressed as carrier‑anchored E-* claims (often backed by U.EvidenceRole assignments on epistemes with provenance from Work).

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

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

• Promise content → L/A (promise semantics + eligibility).
  • Put meanings, invariants, and metric definitions for what is promised in L (L-* in signature laws/definitions).
  • Put “eligible/covered/valid iff …” predicates as A (A-* admissibility/gate predicates), not as deontic obligations.
• Commitment → D (who is accountable).
  • Put “MUST/SHALL/commits to …” statements as D (D-*), preferably as U.Commitment payloads (A.2.8).
  • If compliance requires satisfying/enforcing a gate, the commitment MUST reference the relevant A-* ID(s) (D→A).
  • If the commitment is meant to be auditable, include evidence hooks by referencing E-* (D→E), preferably via U.Commitment.adjudication.evidenceRefs.
• Work + Evidence → E (how we can tell).
  • Put observable traces, audit records, measurement windows, and carrier semantics as E (E-*) with explicit carrier and observation/measurement conditions (A.6.B:5.4). Keyword placement rule (canonical claim set). Within the canonical routed claim set, BCP‑14 norm keywords (RFC 2119 + RFC 8174)—and their common synonyms (e.g., SHALL, REQUIRED, RECOMMENDED, OPTIONAL)—belong in D claims only, expressed as U.Commitment.modality and normalized per A.2.8. Authors SHOULD avoid using these keywords in L/A/E claims; phrase L as definitions/invariants (“is defined as…”, “holds iff…”), A as predicates (“is admissible iff…”), and E as observable/evidenced properties. If a BCP‑14 keyword (or synonym) appears in an L/A/E claim, it SHOULD be rewritten into predicate/definition form (or explicitly marked informative) before publication.

A helpful rewrite rule:

If a sentence mixes “when allowed” + “who must comply” + “how we can tell”, decompose it into an A predicate, a D duty referencing that predicate, and an E evidence claim referencing that predicate (per A.6.B triangle decomposition).

#A.6.C:4.3 — “Guarantee” disambiguation

Treat “guarantee” as ambiguous until routed:

• Semantic guarantee → L (“by definition / invariant”).
• Governance guarantee → D (“provider commits / implementer must”).
• Operational guarantee → E (measured property with evidence expectations; optionally referenced by D as the adjudication target).

If none of these fits, the statement is likely rhetorical and should be rewritten or explicitly marked as aspirational/informative.

#A.6.C:4.4 — MVPK faces are not second contracts

A contract bundle has one canonical claim set. Publication faces are views of that set under viewpoints:

• Faces may select, summarize, and render claims for audiences.
• Faces must not introduce new semantic commitments beyond the underlying claim set.
• Any face-level decision-relevant / normative-looking statement SHOULD cite the underlying claim ID(s). If it cannot be traced to claim IDs, it MUST be explicitly presented as informative commentary.

Keyword rule (faces). If a face contains BCP‑14 norm keywords (RFC 2119 + RFC 8174), including common synonyms (SHALL, REQUIRED, RECOMMENDED, OPTIONAL), then each such sentence MUST be a projection of an existing D‑* claim (U.Commitment) and MUST cite the underlying D claim ID(s). If a sentence cannot be traced to D‑* claim IDs, it MUST be rewritten to remove BCP‑14 keywords (e.g., turn it into explanatory prose that cites the relevant claim IDs) or moved out of the face. To avoid keyword‑evasion, equivalent deontic phrasings (e.g., “is required to…”, “is prohibited from…”) SHOULD follow the same trace-by-ID discipline even when no BCP‑14 keyword is present.

Projection may be paraphrased for audience fit, but it MUST NOT change the deontic/semantic content; if exactness is critical or disputed, use verbatim.

This prevents faces from becoming “second contracts” by paraphrase drift.

#A.6.C:4.5 — Default artefact: Contract Claim Register (recommended)

Use the A.6.B Claim Register (IDs + statements + quadrant + anchor). Add two optional columns that make A.6.C auditable without adding new ontology:

• bundleId: ContractBundleId (local stable ID grouping the claims that constitute one boundary “contract bundle”)
• bundlePart ∈ {PromiseContent, Utterance, Commitment, WorkEvidence}
• faceRefs = {PlainView|TechCard|InteropCard|AssuranceLane : …} (where the claim is rendered)

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

#A.6.C:5.1 — Tell

If you use contract-language for a boundary, do not treat “the interface/spec” as an agent. Instead:

1. Identify the promise content (promise content) being promised,
2. Identify the accountable Commitment holder(s) (roles/agents),
3. Identify the Utterance surfaces that publish the boundary (signature/mechanism + MVPK views),
4. Identify the Work + Evidence carriers that could adjudicate whether commitments were met,
5. Route each claim through L/A/D/E and reference across quadrants rather than paraphrasing.

#A.6.C:5.2 — Show (System archetypes)

(A) Software API boundary

Draft wording (contract soup): “The Payments API guarantees idempotency. Clients must provide Idempotency-Key. We log all requests. Availability is 99.9%.”

Unpack + route:

• Utterance: signature/mechanism publication for PaymentsAPI (MVPK faces: TechCard, InteropCard).
• L: define idempotency and the uniqueness semantics of Idempotency-Key. (“Idempotent” is a semantic property, not a duty.)
• A: admissibility predicate: request is admissible iff Idempotency-Key is present and valid. (Gate belongs to mechanism.)
• D: client implementers are obligated to satisfy the gate; provider implementers are accountable for the idempotency behavior as defined in L when the gate holds; provider commits to the availability target (scoped by window/exclusions). (Name the committing role; do not say “the API commits”.)
• E: evidence expectations: audit/log carriers include request id, idempotency key, rejection reason; availability measurement uses defined window and signal definition.

(B) Hardware interface boundary

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

Unpack + route:

• Utterance: published interface spec (pinout, electrical ranges, handshake procedure).
• L: electrical invariants / allowable ranges are definitions and invariants (truth-conditional).
• A: admissibility predicate: power delivery is admissible only after handshake state reaches an agreed mode.
• D: manufacturer/integrator obligations: implement handshake; enforce voltage constraints.
• E: evidence: test-report carriers; measurement traces; observable negotiation logs (if exposed), or lab measurements under a declared method.

#A.6.C:5.3 — Show (Episteme archetypes)

(C) Multiparty protocol boundary (behavioural/session type motif)

Draft wording: “The protocol guarantees progress. Participants must follow the sequence.”

Unpack + route:

• Utterance: protocol description (could be a type/protocol spec plus explanatory views).
• L: safety/progress properties as laws over the protocol model (truth-conditional, within the theory).
• A: admissibility: when an interaction trace is considered valid/admissible (e.g., runtime checks; compilation checks; gating conditions for entering a session).
• D: obligations on implementers/operators: implement the protocol; do not send messages outside the allowed state machine; publish conformance artefacts if required.
• E: evidence: message trace carriers; conformance test run artefacts; audit trails for disputed interactions.

(D) Socio-technical “SLA + audit trail” boundary

Draft wording: “Provider shall respond within 4 hours for Severity‑1 incidents. Only Severity‑1 is covered. Evidence is provided by ticket logs.”

Unpack + route:

• Promise content (service promise clause): responsiveness promise for a defined incident class and window.
• Utterance: SLA publication (and its views for different audiences).
• A: admissibility predicate for the promise: ticket qualifies iff severity classification meets stated conditions.
• D: provider commitment to meet the target; client duties (e.g., provide required info); auditor duties if applicable.
• E: evidence: ticket carriers, timestamps, classification records, and the measurement procedure binding “4 hours” to a time window and clock source.

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

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for “contract talk” in boundary descriptions.

• Gov bias: prefers explicit accountability and adjudication hooks; increases clarity but adds authoring overhead.
• Arch bias: optimises evolvability by preventing hidden coupling (contract soup) across stack layers.
• Onto/Epist bias: enforces Object≠Description≠Carrier separation; discourages “interface-as-agent” metaphors in Tech prose.
• Prag bias: accepts that “contract” is common vocabulary; offers a disciplined rewrite rather than prohibition.
• Did bias: aims to be teachable via repeated unpacking examples across boundary types.

#A.6.C:7 — Conformance Checklist

A boundary description conforms to A.6.C iff it satisfies all items below:

1. CC‑A.6.C‑1 (Unpacking when contract-language appears). If the text uses “contract/guarantee/promise/SLA” language, it SHALL explicitly disambiguate the statement as referring to at least one of: Promise content (promise content), Utterance (published description), Commitment (deontic binding), Work+Evidence (adjudication).

2. CC‑A.6.C‑2 (No agency to epistemes). The text MUST NOT attribute promising/committing/obligating agency to signatures, mechanisms, interfaces, or documents. Any duty/commitment SHALL name an accountable role/agent.

3. CC‑A.6.C‑3 (Route contract-bearing statements via A.6.B). Contract-bearing statements SHALL be routable as atomic claims to L/A/D/E, with dependencies expressed by explicit references rather than paraphrase.

4. CC‑A.6.C‑4 (Promise content ≠ Work discipline). Statements about what is executed/observed SHALL be expressed as E claims about work/evidence/carriers. Promise‑content language SHALL refer to the promise content (U.PromiseContent, A.2.3) and its L‑defined semantics (and to explicit D‑* commitments represented as U.Commitment, A.2.8), not to execution events (U.Work) or runtime effects. Unqualified head‑noun service (and the co‑moving cluster service provider / server) in normative boundary prose SHALL be unpacked per A.6.8 (RPR‑SERV).

5. CC‑A.6.C‑5 (Evidence hook for operational guarantees). If a “guarantee” is operational (requires reality to decide), the text SHALL include an E claim that states what evidence would adjudicate it (even if the evidence surface is abstract/conceptual).

6. CC‑A.6.C‑6 (No second contracts via faces). MVPK faces MUST NOT add new commitments beyond the underlying routed claims; faces may only project/summarize/select from the canonical claim set under a viewpoint.

7. CC‑A.6.C‑7 (RFC‑keyword discipline inside faces). If an MVPK face contains BCP‑14 norm keywords, each BCP‑14 sentence MUST cite the underlying D‑* claim ID(s) (U.Commitment) it is projecting. If it cannot, the face is non‑conformant until rewritten (no BCP‑14 keyword) or moved out of the face.

8. CC‑A.6.C‑8 (No commitment-by-publication default). A Publish/Approve utterance (including publishing a …Spec) MUST NOT be treated as instituting U.Commitment objects by default. If a Context policy maps publication acts to binding effects, the policy SHALL be cited, and any resulting bindings SHALL still be represented explicitly as U.Commitment objects with accountable subjects.

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

#A.6.C:9 — Consequences

Benefits

• Category mistakes (“contract soup”) become systematically repairable.
• Commitments become accountable (named roles) and adjudicable (evidence expectations).
• Boundaries remain evolvable: laws, gates, governance, and evidence can evolve with controlled coupling.

Trade-offs / mitigations

• Additional authoring effort; mitigated by applying the unpacking only when contract-language appears or when a claim is used for decision/publication.
• Some stakeholders prefer “one sentence contract”; mitigated by MVPK faces that present curated projections while keeping the underlying claim set coherent.

#A.6.C:10 — Rationale

FPF already distinguishes signatures, mechanisms, and work/evidence layers. Contract-language is a high-frequency linguistic entry point that collapses these layers unless a disciplined unpacking is applied.

F.18 provides the naming intuition (service/promise vs utterance vs commitment) via an NQD example; A.6.C makes that split operational for boundaries and extends it with the missing fourth part: work+evidence as the adjudication substrate. This keeps “contract” language routable under A.6.B and compatible with MVPK multi‑view discipline without relocating ontology into the naming chapter.

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

Informative. Alignment notes; not normative requirements.

• Adopt — BCP 14 (RFC 2119 + RFC 8174) norm keyword discipline for spec language. Modern spec-writing practice treats these keywords as a disciplined modality family; A.6.C constrains where such modality belongs (D) versus where predicate-style constraints belong (A/L).
• Adopt — behavioural/session types for protocol boundaries (post‑2015 practice). Protocols as typed interactions emphasize separating safety/progress properties (L) from runtime admission (A) and from implementer obligations (D), with trace-based evidence (E).
• Adopt/Adapt — algebraic effects & handlers / effect systems. The “operation signature vs handler semantics” split mirrors “utterance substrate vs work/evidence”, preventing execution semantics from being conflated with contract surfaces.
• Adapt — ISO/IEC/IEEE 42010:2022 viewpoint discipline. Multi-view publication is treated as viewpoints governing projections; A.6.C applies this to contract talk to avoid face-level semantic forks.

#A.6.C:12 — Relations

• Uses / is used by

  • Uses A.6.B for routing (L/A/D/E), atomicity, and cross-quadrant reference discipline.
  • Used by A.6 cluster conformance (“contract unpacking”) as the detailed, reusable form of that discipline.
  • Complements A.6.S (signature engineering): contract unpacking is a common constructor step when turning prose boundaries into publishable signatures.
  • Coordinates with A.6.P families: when an RPR pattern touches “contract/guarantee” language, apply A.6.C to avoid category errors. (A.6.C is not a specialization of A.6.P; A.6.P is relation‑precision, A.6.C is boundary‑contract disambiguation.)

• Coordinates with

  • A.7 (Object≠Description≠Carrier) for correct placement of evidence claims.
  • F.12 (service acceptance) for structuring how promise-level commitments connect to evidence and acceptance windows.
  • E.17 MVPK “no new semantics” rule to prevent publication faces from becoming new contracts.

#A.6.C:End