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

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 06:45:03 UTC

A.2.3:0 - Use This When

Use this pattern when a project needs to state what is promised to a consumer before asking who is obligated, what work occurred, which system exposes access, or which evaluation method and A.10 evidence relations support a fulfilment assertion.

Typical moments:

  • an SLA publication, service catalog, product offer, public API promise, utility offer, or government-service description contains a statement about what a consumer may rely on;
  • a team says “the service” but might mean promise content, provider organization, API, access point, delivery system, method, ticket, or performed work;
  • a fulfilment claim needs evaluation work that applies declared acceptance criteria to exact delivery-work facts, affected entities and post-work states, and any exact delivery or acceptance relation current for the use; the actual evaluation-operation result binding, optional verdict episteme, and A.10 evidence relations remain separate;

Primary EntityOfConcern. The EntityOfConcern of this pattern is U.PromiseContent: a consumer-facing promise-content episteme. For each PromiseContent episteme, the exact C.2.1 EntityOfConcern is the A.2.3:4.1.1 OutcomeSpec episteme designated by promisedOutcomeSpecRef. Its claim graph states the promised outcome, any eligibility predicate, and acceptance claims; accessSpec separately describes the access method when that description is current.

First useful move. Write the promise content as a clause: what outcome is promised, under which exact effective U.ReferenceScheme and U.ClaimScope, which exact local consumer system-role kind or other eligibility predicate applies, how access is described when relevant, and which acceptance criteria selected work facts and post-work states must satisfy. Name the evaluation method, evidence epistemes, and A.10 evidence relations separately so a fulfilment assertion can be checked. Use U.Commitment only for an actual duty bearer after the applicable constitutive rule and its required instituting basis obtain.

What goes wrong if missed. The word “service” starts naming provider, API, method, ticket, work, department, and promise at once. Teams then judge work against an implicit promise, treat access systems as obligations, or count performed work without knowing which promised outcome it was meant to satisfy.

What this buys. One consumer-facing promise-content episteme with explicit outcome and acceptance claims. Each neighboring claim keeps its named EntityOfConcern and direct relation, defined or tested by its own pattern.

Not this pattern when. If the current EntityOfConcern is an individual deontic relation, use A.2.8; if it is performed delivery Work, use A.15.1; if service or access wording hides its concrete subject or direct relation, start with A.6.P:4.11a. An exact bearer or access-providing arrangement is only one possible recovered reading; code or another episteme, Method, Work occurrence, participation, promise, permission, status, and direct relations keep their own readings. Use A.1 or A.1.SCR only when a separate repaired claim depends on that exact entity being a system. If source agreement or SLA wording combines several objects, use A.6.C to unpack them.