fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 13113–13133

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 07:10:10 UTC

A.6.C:1 — Problem frame

Boundary descriptions frequently use “contract” as shorthand for “the thing that governs the interaction”. That shorthand collapses four practical questions and the separately governed objects needed to answer them:

  • What was promised? — the exact promise content, if any,
  • What was said, published, or instituted? — the speech-act Work, descriptions, publication occurrences/forms/carriers, and any separately governed institutional effect,
  • What governance or permission-looking claim exists? — the one atomic norm, grant, gate, exercise, evaluation, conflict, or source claim selected by its job,
  • What happened, what followed, and what supports reliance? — dated Work, each separate result or delivery claim, and each evidence claim.

When these questions are answered with one undifferentiated object or row, authors can conflate a semantic guarantee with an undertaking, attribute a dated act to its description instead of its performer, 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). When contract talk co-moves with service, service provider, server, SLA, SLO, or service-level and a relied-on boundary use still hides a concrete subject or relation, recover that hidden choice through A.6.P:4.11a while asking the four questions below. Mere co-occurrence does not trigger recovery, and clear, quoted, historical, illustrative, or harmless ordinary wording remains usable. U.PromiseContent is written as promise content, never 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 across scales or contexts: keep the current grant or prohibition as its own D claim, classify the conflict finding as E through A.6 A6-AW-CONFLICT, and use the exact mediation predicate and assertion only when mediation is current;
  • redefine the core meanings of U.PromiseContent, U.Work, U.SpeechAct, U.Commitment, or the exact A.2.8.PER results—it only makes “contract talk” classifiable into those objects or claims.
  • redefine quadrant semantics (L/A/D/E) or cross‑quadrant reference rules; those are defined normatively in A.6.B.