FPF Reference

    A.6.C:1 — Problem frame

    Preface node heading:a-6-c-1-problem-frame:8532

    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

    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 an L/A/D/E claim-classification discipline 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 or contexts (capture them as separate D-* claims and apply conflict or 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.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)