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

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 05:55:15 UTC

A.2.3:4.3 - Promise content, delivery work, and evaluation work

  • Before delivery work: The promise-content episteme declares its effective U.ReferenceScheme, named U.ClaimScope, promised outcome specification, access specification when current, and acceptance specification. A.2.2 states the provider System’s qualified ability. A separate capability-fit predicate compares that claim’s work conditions and attained bounds with the conditions and thresholds selected for the planned delivery work, including any threshold stated by the chosen method description. Method-selection work may yield a C.11 ChoiceResult; enactsMethod obtains between the later delivery-work occurrence and the selected U.Method. A relied-on episteme is a U.MethodDescription only when it meets A.3.2 membership, and the promise-content or acceptance claim may cite it for the named use.

  • Run‑time: For request or visit Work, use A.13 to identify the actual consumer System S, then let A.15.1 admit requestWork independently. If the current use must also state under which assignment the request was performed, F.6 checks performedUnderAssignment(requestWork, consumerRA) against the same assignment used by A.13 and compares S with consumerRA.HolderSystemSlot. For delivery Work, use A.13 to identify the actual provider System S, then let A.15.1 admit deliveryWork independently. If the current use must also state under which assignment the delivery was performed, F.6 checks performedUnderAssignment(deliveryWork, providerRA) against the same assignment used by A.13 and compares S with providerRA.HolderSystemSlot. For evaluation Work, use A.13 to identify the actual evaluator and let A.15.1 admit the dated occurrence before saying that it enacts the Method selected by acceptanceSpec. Add F.6 only if the current use must also state under which assignment the evaluation was performed. Cite the optional MethodDescription only when the evaluation claim depends on that edition. The actual evaluation-operation application carries its argument bindings and result value. When another use needs a durable verdict episteme, C.2.1 governs that episteme and A.15.PROD governs any current identity-inception claim. The counting rule in unitOfDelivery maps admitted fulfilment occurrences to unit counts. The verdict episteme may assert whether a named service-level objective or another acceptance criterion was satisfied during the declared window. When a separately obtaining U.Commitment has the same U.PromiseContent in its referents position, the supported assertion concerns fulfilment of content that is also a referent of the obligation. Neither the operation-result binding, verdict episteme, nor commitment is a property of the promise-content episteme.

    When a separate F.6 performedUnderAssignment(W, RA) claim is made, W is already admitted and RA is the same assignment used by A.13. F.6 compares that assignment’s holder with the actual performer already identified through A.13 and used by A.15.1. A missing or failed F.6 check leaves the Work intact.

Memory hook: Promise content states what is promised. A method constrains possible work. A system performs work. Evaluation binds a result value. A verdict episteme states the judgment. Evidence supports that assertion.