#A.6.C:4 — Solution

Preface node heading:a-6-c-4-solution:10531

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

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 under A.6.B.

#A.6.C:4.1 — The Contract Bundle (four-question lens; every atomic claim keeps its own quadrant)

Whenever a text uses “contract”, “guarantee”, “promise”, “SLA”, or “interface agreement”, ask the four questions below. A question may yield zero, one, or several atomic Claim Register rows; the question itself is not a bundle part or direct-object kind.

1. What was promised?

   • The promised value or 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 or service promise clause) and SHALL NOT rely on the bare head noun service. If the surrounding text also talks about endpoints, systems, and operations, apply A.6.8 to select facet‑typed phrases (service access point, service delivery system, service delivery work, and so on) 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.
• Claim-classification discipline: keep the semantics and 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-* and E-* claims as needed).

2. What was said, published, or instituted?

   • Speech-act row: if the boundary decision depends on who stated, published, or approved something, record that exact A.2.9 U.SpeechAct <: U.Work occurrence.
   • Description/publication rows: record the versioned utterance epistemes separately from their publication occurrences, forms, renderings, and carriers. None is the speech act.
   • A speech act may institute or update a commitment or strong grant only when the exact context policy recognizes that act type and the direct owner's obtaining conditions are met.
   • The published utterance descriptions (signature or mechanism descriptions plus MVPK faces) carry L/A/D/E-classified claims. The act is not “the contract”; it is the Work occurrence that created or updated those descriptions and may have a separately governed institutional effect.
   • World-side obtaining rule (normative). A.2.8 and the cited context policy decide whether a commitment obtains; A.2.8.PER and that policy decide whether a strong grant obtains. They use the actual instituting speech act, participants, scope/window, current policy, and any revocation or supersession conditions. A Claim Register row, utterance description, publication, carrier, or identifier creates or proves neither relation. Publication or approval may establish a publication/status relation only through that relation's own direct owner.
   • Representation and reliance rule (normative). The model MAY assert or rely on a commitment or grant only through a separate atomic claim that identifies the exact U.Commitment or GrantedPermissionRelation@Context occurrence and cites its direct owner, instituting act and policy, participants, scope/window, and the currentness or evidence required by that use. Never infer the relation from Publish/Approve wording, a document, carrier, or completed-looking record alone.

3. What governance or permission-looking claim exists?

   • When the model asserts or relies on an accountable obligation, recommendation-as-duty, or prohibition, write a separate atomic D claim whose direct object is the exact U.Commitment governed by A.2.8. The claim records the relation for use; it neither institutes it nor proves that it obtains.
   • For permission-looking wording, select one A.6 A6-AW-* row. Only A6-AW-NORM-GRANT enters D; A6-AW-GATE enters A; exercise, weak evaluation, conflict, and observed-source claims enter E when their closing facts are present. A.2.8.PER ownership alone selects no quadrant.
   • Commitment-branch checklist (A.2.8 minimal structure):
     • id (stable; often the D-* claim ID),
     • subject (accountable role or party; never an episteme),
     • modality (the exact A.2.8 DeonticModalityToken: MUST | MUST_NOT | SHOULD | SHOULD_NOT),
     • scope (U.ClaimScope) and validityWindow (U.QualificationWindow),
     • referents (by reference or ID: promise content IDs like SVC-*, plus L-*, A-*, MethodDescriptionRef(...), or PromiseContentRef(...) as needed),
     • optional owedTo (beneficiary or counterparty),
     • optional adjudication.evidenceRefs when the commitment is meant to be auditable (point to E-*),
     • optional source when authority or provenance matters (issuer + instituting speechActRef + description reference),
     • optional notes for explicitly informative commentary (not part of the binding).
   • Permission-branch pointer: cite the selected A6-AW-* row, its exact A.2.8.PER object when applicable, and that atomic claim's quadrant. Preserve the object's own schema, participants, and references; do not reuse the commitment checklist.
   • A commitment is not “the spec text”: utterance descriptions carry the statement, but the binding is the U.Commitment object (A.7 and A.2.8).

4. What happened, what followed, and what supports reliance?

   • Work: A.15.1 owns one exact dated W : U.Work with performer system, covering assignment, enacted method, extent, and containing system. The Work can exist without a result, production, delivery, evidence-use, or acceptance claim.
   • Result or consequence: only when the sentence asks for one, select the matching A.15.1:4.6 row—an A.6.1 application/result binding or already governed WorkResultRelation, A.15.PROD production branch, A.3.4 change, evaluation result, subject-owned delivery/transfer relation, or acceptance relation. An absent row stays absent.
   • Evidence: only when a receiving use relies on Work or one of those consequences, state an A.10 claim-bound evidence path and carrier. Evidence supports the named claim; it creates neither the Work nor its result.

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

After unpacking, classify 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 and definitions).
  • Put “eligible, covered, or valid iff …” predicates as A (A-* admissibility or gate predicates), not as deontic obligations.
• Governance and permission-looking claims → claim-specific quadrant.
  • Put “MUST, SHALL, or commits to …” statements as D (D-*), preferably as U.Commitment payloads (A.2.8).
  • For authority-looking wording, select one A.6 A6-AW-* row: norm/grant → D, gate → A, and actual exercise or evaluated finding/conflict/source → E. Cite the exact A.2.8.PER object only where that row requires it; do not let its owner family choose the quadrant.
  • If compliance requires satisfying or 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.
• Performed Work → E (did it happen?).
  • Name the exact A.15.1 Work occurrence and its performer, assignment, method, extent, and containing system. Do not add an output or delivery field.
• Result or consequence → E when current (what else happened?).
  • Use the one applicable A.15.1:4.6 direct owner for the returned value, production, change, evaluation result, delivery/transfer, or acceptance claim.
• Evidence → E when relied on (how can the claim be used?).
  • Name the exact A.10 path, observation conditions, and carrier for the Work or consequence claim being supported. Carrier presence establishes none of those objects. Keyword placement rule (canonical claim set). Within the canonical L/A/D/E-classified claim set, BCP-14 keywords are statement operators, not ontology or quadrant selectors. MUST, MUST NOT, SHOULD, and SHOULD NOT enter D only for an accountable duty, recommendation-as-duty, or prohibition. MAY, OPTIONAL, and authority-looking synonyms trigger the A.6 A6-AW-* branch: a current norm/grant enters D, a mechanism entry predicate enters A, and an actual exercise or evaluated finding enters E. If the wording does not expose the branch and direct object, rewrite it or mark it informative.

A helpful rewrite rule:

First recover what “allowed” asserts by selecting one A.6 A6-AW-* row. Put only the current norm/grant in D, the entry predicate in A, and actual exercise or evaluated findings in E; cite each direct object and source. The word and A.2.8.PER membership select neither quadrant nor obtaining.

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

Treat “guarantee” as ambiguous until classified:

• Semantic guarantee → L (“by definition or invariant”).
• Governance guarantee → D (“provider commits or 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 or informative.

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

The atomic claims grouped for one boundary use live in one canonical A.6.B Claim Register set; the four-question lens creates no parallel claim set. Publication faces are views of that set under viewpoints:

• Faces may select, summarize, and render claims for audiences.
• Faces must not introduce a new commitment or any new object or claim selected through A6-AW-*; they project the existing classified claim.
• Any face-level decision-relevant or 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 a BCP-14 keyword, each sentence MUST cite its existing classified claim ID and direct object. Duty/recommendation/prohibition and current-grant projections cite their D claim; a gate projection cites its A claim; exercise or evaluated-finding projections cite their E claim. Use the selected A.6 A6-AW-* row for permission-looking wording. A face-level keyword manufactures no object or quadrant; without a traceable claim, remove the keyword or mark the sentence informative. 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 or semantic claim; if exactness is critical or disputed, use verbatim.

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

#A.6.C:4.5 — A.6.B Claim Register additions (recommended)

Use the A.6.B Claim Register (IDs, statements, quadrant, and canonical location). Add the following A.6.C fields without minting another record or ontology kind:

• bundleId (optional local ID grouping atomic claims discussed together)
• questionRef (optional pointer Q1, Q2, Q3, or Q4 to the four questions above; it selects no kind, owner, or quadrant)
• directObjectRef (the exact U.EntityRef(...), or the canonical claim ID when the row's direct object is itself a claim)
• ownerPatternRef (the exact pattern ID that owns that direct object)
• faceRefs (optional mapping from PlainView, TechCard, InteropCard, or AssuranceLane to where this same claim is rendered)

Each row still uses the A.6.B fields for one exact statement, claim ID, quadrant, and canonical location. Do not create a second Contract Bundle record or a Permission, Utterance, WorkEvidence, or result/evidence umbrella kind.

---

Last Updated: 2026-07-28 — upstream FPF commit 17edd955 (github.com/ailev/FPF)