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

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:40:10 UTC

A.2.3:6 - Mapping the common “service” picture to FPF (didactic bridge)

A common service diagram is a representation. Recover the represented systems, epistemes, work occurrences, and relation occurrences as follows:

  • Provider participation -> when this mapping needs the provider’s assignment, name its occurrence and declared species under U.SystemRoleAssignment. The occurrence supplies its holder System, assigned local kind, and any other participants; the species defines their meanings. For each selected delivery-work occurrence, follow the §4.3 route to identify the actual performer and admit the Work independently. Add F.6 only if the mapping must also say exactly under which assignment that delivery was performed; a missing or failed check leaves the delivery Work intact.
  • Acceptance criterion -> an evaluation-criterion episteme in U.PromiseContent.acceptanceSpec; its target values, verdict scale, and GammaTimePolicyRef remain explicit. A U.WorkPlan is added only when planned delivery or evaluation work is current.
  • SLA obligation -> one A.2.8 U.Commitment occurrence whose actual duty bearer is explicit and whose referents include the relevant U.PromiseContent; assert it only after the applicable constitutive rule and required instituting basis obtain. Use A.6.C when one SLA publication combines wording about commitment, promise content, evidence specification, and publication relations.
  • Published SLA terms -> the selected U.PromiseContent / U.Episteme, the exact publication form that expresses it for the bounded use, the U.PresentationCarrier bearing that form, and the obtaining EpistemePublicationRelation occurrence that makes the selected edition available to the declared audience. When publication work also communicates or institutes a commitment, add the named A.2.9 speech-act and A.2.8 commitment relation occurrences; publication alone neither creates the commitment nor establishes fulfilment.
  • Operating conditions -> the named U.ClaimScope under A.2.6. The acceptance specification may cite that scope; it does not replace it.
  • Promised subject -> resolve promisedOutcomeSpecRef and follow the declared mode. Use workSpec for promised Work conditions and, when resultSpec is present, use its postcondition and any entityOfConcernRef to identify the required affected referent and post-work state. State only the direct delivery or acceptance relations required by the current claim.
  • Customer material—“ours versus theirs.” -> If the current claim depends on who owns or has custody of data, an asset, or a case, name the exact obtaining system-role assignment when work-facing assignment matters, and name the ownership or custody relation with its actual participants when that is the claim. Neither relation substitutes for the other, and neither becomes a kernel-global property of U.PromiseContent.
  • Access -> accessSpec : U.MethodDescription describes the Method enacted when an eligible consumer holder requests access. Recover the endpoint, desk, manifold, or other exact bearer through A.6.P:4.11a. Its label and addressability establish no U.System membership. Apply A.1 or A.1.SCR only when a current access-point, delivery-system, performer, or assignment claim depends on systemhood; otherwise keep the bearer claim separate.
  • One PromiseContentUse occurrence -> consumer request Work and provider delivery Work remain separate occurrences. Follow the §4.3 performer-and-Work route for each. If this mapping must also state the assignment under which either occurrence was performed, add its separate F.6 relation against the same assignment used by A.13; a missing or failed check leaves the Work intact. When request Work follows accessSpec, its A.15.1 methodDescriptionRef resolves to that same U.MethodDescription; following the description does not by itself introduce a second relation occurrence. PromiseContentUse obtains between selected delivery Work and the selected promise-content edition during PromiseUseIntervalSlot.
  • Consumer-side changed entity or relation -> recover the exact affected-referent and actual-transformation facts, plus any local entity-identity-inception, delivery, acceptance, or receiving-use claim that the current promise evaluation needs. If the changed entity is a holder system and its post-work state changes the truth of a qualified ability claim, use A.2.2 to restate that claim and reassess its support and currentness.
  • Service-enabled consumer-side capability or activity -> If the question is about ability, identify the consumer holder and state its qualified ability, support and currentness under A.2.2. If the question is about activity, identify the consumer-side dated U.Work under A.15.1. If the claim also says that delivery changed the consumer or was used by that Work, state only the exact actual-change or receiving-use relation that currently obtains; otherwise keep the objects separate. Do not create another U-kind or a generic capability-use relation. When a domain claim concerns catalog entries, exposure relations, charging relations, or entitlement relations, govern those entries, participants, and relations directly. Relate them to U.PromiseContent only through named relations; do not treat them as components of U.PromiseContent or replace their direct relations with a locally minted context relation.