#U.PromiseContent (Promise Content)

A.2.3 · Stable · Definitional promise-content episteme pattern · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Definitional promise-content episteme pattern Status: Stable

U.PromiseContent is a dependent durable promised-outcome episteme under the episteme settlement. It is not a root beside U.Episteme, not a commitment, not work, and not a U.PresentationCarrier.

#Keywords

• promise content
• accessSpec
• acceptanceSpec
• SLO
• SLA
• claim scope (G)
• Work evidence
• provider/consumer roles.

#Relations

#Content

#Kind Settlement

U.PromiseContent is a dependent durable promised-outcome episteme under the episteme settlement. It is not a root beside U.Episteme, not a commitment, not work, and not a U.PresentationCarrier.

#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. At species level, its C.2.1 EntityOfConcernSlot is filled by the A.7 OutcomeSpec episteme denoted 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 consumer role is eligible, 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. Then use U.Commitment only when an accountable subject is assigned to that content.

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 direct exits to commitment, role assignment, access, PromiseContentUse, performed delivery work, affected entities and states, evaluation-operation results, optional verdict epistemes, evidence, acceptance, and publication patterns. Each neighboring claim keeps its named EntityOfConcern and direct relation instead of being collapsed into one undifferentiated service referent.

Not this pattern when. If the current EntityOfConcern is the accountable deontic relation, use A.2.8; if it is performed delivery Work, use A.15.1; if service/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/run, participation, promise, permission, status, and direct relations keep their own readings. Use A.1/A.1.SCR only when a separate repaired claim depends on that exact entity being a system. If the current move is Contract Bundle unpacking, use A.6.C.

#Problem frame

Across domains the word service is used for many different things: a server or provider, an API, a procedure, a run, a department, even a product bundle. Such polysemy is productive in everyday speech but toxic in a normative model.

FPF therefore reserves U.PromiseContent for one kernel meaning: a consumer-facing promise content clause. When service denotes something else, use A.6.P:4.11a to recover whether it denotes code or another episteme, a Method, Work/run, provider participation, an exact bearer or access-providing arrangement, permission, status, or a direct relation. A product label chooses none of these readings, and bare service has no default system reading. Apply A.1/A.1.SCR only when a separate repaired claim depends on an exact recovered entity being a system; normative prose then names that referent or relation and its direct owner.

This keeps the kernel minimal while keeping the prose readable to non‑mathematicians: the canonical symbol is U.PromiseContent, and the head kind in normative text is always promise content.

Modularity note. A.2.3 defines the promise-content episteme and PromiseContentUse. Role assignment, access specification, delivery work, actual operation application and result binding, result-episteme identity, affected-subject change, A.10 evidence relations, evaluation, commitment, delivery, acceptance, speech act, and publication remain with their direct governing patterns. A.6.P:4.11a recovers which concrete service/access referent or relation the wording denotes; it does not replace the named participants and their direct relations with a locally minted service-situation relation. A.6.C governs the Contract Bundle lens when contract, SLA, or guarantee wording must be unpacked.

Plain reading. Promise content says what a consumer may rely on. A system holding the provider role through a named U.RoleAssignment occurrence performs delivery work by enacting a U.Method; a U.MethodDescription describes that method. PromiseContentUse obtains between the delivery-work occurrence and the selected promise-content edition during the named interval. Exact work-participation, affected-referent, actual-change, delivery, and acceptance relations state what happened. A separately performed evaluation applies the declared operation or method; its actual result binding states the evaluation value. If another use needs a verdict episteme, C.2.1 governs that episteme and A.15.PROD governs any current entity-identity-inception claim. Evidence relations support the relied-on assertions. No universal work-result relation is presumed.

Lexical note (L-SERV and A.6.P:4.11a). Bare service does not determine one FPF referent. When that word carries a relied-on claim, use A.6.P:4.11a to recover the concrete referent or relation: for example, a promise-content episteme and an access-point system have different kinds and participate in different relations. E.10 L-SERV triggers that recovery; after the referent or relation is known, its direct governing pattern applies.

#Problem

Without a first-class U.PromiseContent, a project description tends to make five recurring category errors:

1. Provider = Service. Calling the provider system or team “the service” collapses that provider referent with the promise-content episteme.
2. API = Service. Treating an interface or endpoint as the service hides the promised consumer-side outcome and its acceptance criteria.
3. Method or plan = promise content. Treating a semantic method, a method-description episteme, or a work plan as the promise content hides the consumer-facing outcome and acceptance claims.
4. Run = Service. Logging Work as "a service" erases the promise-content episteme and acceptance specification needed for SLA reasoning.
5. Business ontology lock-in. Large domain schemes are imported wholesale, losing FPF universality and comparability across projects and domains.

#Forces

#Solution - Define U.PromiseContent as the promise-content episteme

Definition (normative). A U.PromiseContent is an externally oriented promise-content episteme. Its claim content states a promised consumer-side outcome, any eligibility predicate, and acceptance criteria by which fulfilment is evaluated. Its optional accessSpec describes the access method. Interpretation is fixed by its effective U.ReferenceScheme; U.ClaimScope states where the claims hold.

U.PromiseContent is not a deontic commitment relation. One or more explicit U.Commitment occurrences under A.2.8 may have the promise content in their referents position; the promise-content episteme does not obligate an actor by itself.

In normative prose, the head phrase is promise content. Service offering clause and service promise clause are admissible Plain twins for that promise-content use; bare service does not identify a promise-content episteme.

Species-level identity follows C.2.1:

PromiseContentIdentity = <
  content,
  promisedOutcomeSpecRef,
  effectiveReferenceScheme
>

promisedOutcomeSpecRef is the species-level realization of EntityOfConcernSlot; it is a U.EpistemeRef that resolves to the A.7 OutcomeSpec episteme about which the promise claims are made. OutcomeSpec is a specification-use episteme form, not a separately admitted U-kind. The exact claimScope qualifies where the promise-content claims hold and remains outside the identity tuple. A selected model-use structure is not an episteme constituent or generic identity qualifier: it may be designated only by a receiving assertion or use whose interpretation actually depends on that structure. A direct dependent species may strengthen identity only through its own governing pattern.

• FPF kind: U.Episteme.
• Time stance: the promise content can be authored before delivery; later exact delivery-work facts, affected entities, post-work states, and any current delivery or acceptance relations are tested against the declared outcome and acceptance predicates. Evaluation work and the actual operation-result binding remain separate; when a verdict episteme is constituted, C.2.1 and A.15.PROD govern its identity and inception, while A.10 evidence relations support the relied-on assertions.
• Orientation: consumer-facing promise claims, not provider capability claims.
• Publication boundary: isCarriedBy may obtain between a U.EpistemePublication and a U.PresentationCarrier. Promise-content identity follows the C.2.1 episteme identity rule; neither the isCarriedBy occurrence nor carrier identity enters that rule.

#Promise-content schema

U.PromiseContent : U.Episteme {
  content                  : U.ClaimGraph,
  promisedOutcomeSpecRef   : U.EpistemeRef, resolving to OutcomeSpec,
  effectiveReferenceScheme: U.ReferenceScheme,
  providerRole             : U.Role,
  consumerRole?            : U.Role,
  claimScope               : U.ClaimScope,
  accessSpec?              : U.MethodDescription,
  acceptanceSpec           : U.Episteme,
  unitOfDelivery?          : U.Episteme
}

• content carries the promised-outcome, eligibility, and acceptance claims together with the optional accessSpec value when an access-method description is current; it is not an untyped text slot.
• providerRole and consumerRole are U.Role values carried by value in the claim graph. accessSpec, acceptanceSpec, and unitOfDelivery are episteme values carried by value in the claim graph; a publication or other declared representation may express them through U.EpistemeRef values that resolve to those same epistemes without changing their kinds. Changing any of these values changes content and therefore the promise-content identity.
• promisedOutcomeSpecRef resolves to the A.7 OutcomeSpec episteme. It is neither a U.Work occurrence, an affected or delivered entity, an actual operation-result binding, nor a verdict episteme.
• effectiveReferenceScheme makes the claim graph and its references interpretable.
• providerRole and consumerRole are role values; actual providers and consumers enter through named U.RoleAssignment occurrences.
• claimScope is the exact U.ClaimScope over which the promise claims hold; it states the applicable operating conditions, populations, locales, and other admitted slices instead of leaving extent implicit.
• accessSpec describes the access method enacted when a holder system under an eligible consumer U.RoleAssignment requests access; an access-point system remains separate.
• acceptanceSpec states the acceptance criteria, identifies the evaluation method through its U.MethodDescription, and states evidence-admissibility conditions for supported assertions; actual evidence relations remain separate.
• unitOfDelivery states how accepted delivery work is counted when counting is current.
• There is no generic modelUseStructureRef field. When an independently selected BoundedModelUseStructure changes one actually model-local receiving interpretation, the receiving assertion or use designates that structure separately; the structure neither identifies the promise content nor becomes an optional participant of PromiseContentUse. A genuinely structure-dependent relation species would require its own direct pattern, mandatory structure participant, stronger predicate, and occurrence-identity rule.
• An internal delivery method remains U.Method. An already identified episteme is a U.MethodDescription only when its exact EntityOfConcern resolves to that Method and at least one claim says how that Method is done. A promise-content or acceptance claim may cite that episteme for one named use; Method-selection work, performed work, and PromiseContentUse remain separately governed.

#Promised outcome spec (disambiguation: work vs post-work result)

promisedOutcomeSpecRef points to an A.7 OutcomeSpec episteme that makes explicit what is promised in kind form and specification form without collapsing it into either:

• the promise content clause itself (U.PromiseContent),
• the delivery work that happens at run‑time (U.Work), or
• the post-work state or affected referent after the work.

This is a controlled semantic precision restoration for the everyday metonymy "outcome" or "service outcome", which different communities use to mean (i) the work performed, (ii) the achieved result, or (iii) both.

Terminology bridge (informative). In loose contract talk people say promiseOutcomeSpec (the description of what will be delivered) and promiseOutcome (what was actually delivered). Those lexical forms are metonymic: sometimes they mean “the work performed”, sometimes “the post‑work result”, and sometimes the pair.

In FPF:

• promiseOutcomeSpec -> A.7 OutcomeSpec, referenced via promisedOutcomeSpecRef.

• promiseOutcome -> an extensional delivered outcome instance. It does not have one kernel kind; it is the run-time reality that satisfies the outcome specification, interpreted according to OutcomeSpec.mode:

  • WorkOnly → the set of delivery U.Work episode(s) that satisfy workSpec (and, if present, the promised methodConstraintRef).
  • ResultOnly → the post‑work state of the described referent(s) on the declared statePlaneRef that satisfies resultSpec.postConditionRef (regardless of how it was achieved).
  • Composite → the pair: (delivery Work episode(s), post‑work state).

  FPF identifies the extensional delivered outcome by citing the relevant U.Work occurrences, exact affected or delivered entities, applicable actual-change and delivery relations, and the selected Delta expression for affected referents together with their pre-work and post-work states on the declared state plane (A.15.1:4.2 item 10). Evidence epistemes derived from telemetry may enter A.10 evidence relations supporting claims about those facts and states and about later evaluation-result epistemes; neither an evidence episteme nor the U.PresentationCarrier filling the carrier position of its isCarriedBy relation is the delivered outcome.

When bundling, invoicing, or dispute handling needs a downstream claim to identify the delivered instance, that claim's episteme separately references the delivery-work occurrences, affected entities, post-work states, evidence epistemes, and A.10 evidence-relation occurrences under their direct governing patterns. It does not create a local OutcomeInstance kind, collapse the delivered reality into OutcomeSpec, or let an invoice, dispute record, other record form, or U.PresentationCarrier become either the episteme or the delivered instance.

A conforming OutcomeSpec uses this explicit-RefKind reading of the specification-use shape in A.7:5.10.2:

OutcomeSpec : U.Episteme ::= {
  mode: WorkOnly | ResultOnly | Composite,

  workSpec?: {
    methodConstraintRef?: U.EpistemeRef,          // resolves to the U.MethodDescription constraining the promised work
    workPredicateRef: U.EpistemeRef               // resolves to a predicate on selected facts about U.Work occurrences
  },

  resultSpec?: {
    entityOfConcernRef?: U.EntityRef,             // affected referent whose declared FPF kind is named
    statePlaneRef?: StatePlaneRef,                // where the predicate lives (A.7:3 pins)
    postConditionRef: U.EpistemeRef               // resolves to the post-state predicate; evidence supports the resulting claim separately
  }
}

• workSpec corresponds to the work-as-promised facet: it states the consumer-facing kind of work (optionally constraining method) and the work predicate (e.g., duration, method ban, safety limit).
• resultSpec corresponds to the result-as-promised facet: entityOfConcernRef identifies the affected entity, statePlaneRef identifies the state plane when current, and postConditionRef identifies the required post-work state predicate.
• Counting is not part of OutcomeSpec. Counting lives in U.PromiseContent.unitOfDelivery as the countingRule mini-schema (A.7:5.10.3). Outcome specifications say what counts as delivery; unit-of-delivery specifications say how much to count and how to avoid double counting.

Examples (informative):

• “Work 5 minutes” → mode=WorkOnly; workPredicateRef states duration ≥ 5 min; methodConstraintRef may be omitted.
• “Dig a hole” → mode=ResultOnly; postConditionRef describes the hole’s target state; method choice remains provider‑autonomous.
• “Hairstyle in ≤ 20 min, must be haircut+styling (not a wig)” → mode=Composite; workSpec expresses time + method constraint; resultSpec expresses the target hairstyle state.

Naming note (normative). The head noun outcome is intentionally broad. Do not replace it with result when referring to the combined work-and-result specification. If a passage means the affected entity, name that entity and link it to resultSpec.entityOfConcernRef. If it means the required post-work state, name the state predicate and link it to resultSpec.postConditionRef. If it means the promised work occurrences, say work as promised and link them to workSpec.

#Recommended acceptanceSpec mini‑schema (informative, non‑kernel)

Projects may express acceptanceSpec with the following small schema when downstream evaluation work requires replayable criteria and verdict semantics:

AcceptanceSpec (recommended) ::= {
  targetOutcomeSpecRef?: U.EpistemeRef,          // resolves to OutcomeSpec; default is SC.promisedOutcomeSpecRef
  criterionRefs: [U.EpistemeRef],                // each resolves to one evaluation-criterion episteme
  evaluationMethodDescriptionRef: U.EpistemeRef, // resolves to the U.MethodDescription for evaluation work
  verdictScaleDescriptionRef: U.EpistemeRef,     // resolves to one declared scale description
  GammaTimePolicyRef?: U.EpistemeRef             // resolves to the policy selecting the evaluation window
}

• targetOutcomeSpecRef makes explicit which promised outcome is being judged; if omitted, it is the containing promise content’s promisedOutcomeSpecRef.
• criterionRefs resolve to evaluation-criterion epistemes. Their predicates are evaluated over the same selected work facts and post-work state references used for the targeted OutcomeSpec; direct evidence relations separately support assertions about those facts and states.
• evaluationMethodDescriptionRef resolves to the U.MethodDescription for the method enacted by evaluation work. The description does not perform the evaluation.
• verdictScaleDescriptionRef resolves to one scale-description episteme governed by the characteristic and scale patterns. That description states the admitted verdict values and how non-delivery is represented. Informative examples include Boolean pass/fail, trichotomy pass/partial/fail, or named graded values, with non-delivery represented as fail, N/A, or Inconclusive; these values are examples, not defaults.
• GammaTimePolicyRef keeps temporal selection explicit and non-retroactive (F.10 and F.12): it resolves to the policy stating whether judgement is per work occurrence, reporting window, or another named temporal selection. Population and locale remain in U.ClaimScope; they are not temporal-policy values.

This mini-schema is a recommendation only: it does not admit another U-kind. An acceptance-specification episteme may contain these declared schema fields by value or refer to their values through the declared RefKinds. The resulting episteme remains inspectable and bridge-ready without turning its publication form into identity.

#What U.PromiseContent is not

• Not a provider: use a named provider U.RoleAssignment occurrence whose holder is the provider U.System.
• Not a deontic commitment: that is U.Commitment (A.2.8) whose referents include the promise content when that accountable relation is current.
• Not an access point or bearer: addressable service, server, desk, endpoint, process, component, application, host, or cluster wording first goes to A.6.P:4.11a. Recover whether it denotes code or another episteme, a Method, Work/run, an exact bearer or access-providing arrangement, or another directly governed object; apply A.1/A.1.SCR only when a separate repaired claim depends on an exact recovered entity being a system.
• Not a method or method description: the semantic way of doing is U.Method; a recipe or other episteme describing that way is U.MethodDescription.
• Not delivery work or its description: performed delivery is U.Work; a ticket, case description, or incident description is a separately governed episteme about planned or performed work.
• Not a schedule: that is U.WorkPlan.
• Not a capability: capability is the provider system's admitted ability to perform a declared work family and meet any declared result-class predicate within its U.WorkScope, measure set, qualification window, and currentness condition. Delivery under a promise may depend on one or more capability instances, but the promise-content episteme is not a capability.
• Not its scope or use interval: U.ClaimScope states where the promise claims hold, U.WorkScope states where a provider capability can deliver work, and PromiseUseIntervalSlot states when one PromiseContentUse occurrence obtains. These are three different values.

#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. The provider system's ability remains a holder-dependent U.Capability instance under A.2.2. A capability-fit predicate tests that instance against the 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. That citation establishes neither Method selection, later enactsMethod, PromiseContentUse, evidence, nor acceptance.

• Run‑time: The admitted holder system S = consumerRA.HolderSystemSlot of the named consumer U.RoleAssignment performs request or visit U.Work under that assignment. When the attribution is stated explicitly, use performedUnderAssignment(requestWork, consumerRA). The admitted holder system S = providerRA.HolderSystemSlot of the named provider U.RoleAssignment performs delivery U.Work under that assignment. When the attribution is stated explicitly, use performedUnderAssignment(deliveryWork, providerRA). A system performing evaluation work enacts the evaluation method described by acceptanceSpec; the actual evaluation-operation application carries its exact argument bindings and evaluation-result value. When another use needs a durable verdict episteme, C.2.1 governs that episteme and A.15.PROD governs any current entity-identity-inception claim. The counting rule stated by 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.

  In each performedUnderAssignment(W, RA) occurrence, WorkOccurrenceSlot is filled by W and RoleAssignmentSlot by the named A.2.1 assignment occurrence RA; the admitted holder system S = RA.HolderSystemSlot is the actual performer. The assignment does not act, and no provider-assignment or consumer-assignment pseudo-kind is introduced.

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.

#Didactic card: Relations around one service-delivery evaluation

Didactic (non-normative). This representation keeps each promise-content episteme, access-description episteme, work occurrence, and direct relation in one delivery evaluation visible without prescribing an order of work. Promise content and an access description remain epistemes; commitment and role assignment remain relations; delivery and evaluation remain work occurrences; evidence remains in its A.10 relations. When order matters, describe semantic method order in U.MethodDescription, intended dated order in U.WorkPlan, and transformation dependencies in the governing TransformationFlowStructure.

U.PromiseContent states the promise. An A.2.8 U.Commitment relation may refer to that content; its accountable-subject position is filled by the accountable subject. In a provider U.RoleAssignment, the holder-system and role-value positions are filled by the provider system and provider role. Delivery U.Work occurs. Evidence relations support claims about selected delivery-work facts and post-work states. A system performing evaluation work enacts the evaluation method; the actual operation application carries its result binding, while any verdict episteme is separately governed by C.2.1 and any current identity-inception claim by A.15.PROD.

This informative diagram is a publication-side representation, not new ontology. It prevents two category errors: treating U.PromiseContent as the addressable access system, and treating a publication-side list or diagram of service senses as a relation occurrence that replaces the direct relations shown here.

flowchart LR
  SC["Promise content<br/>(U.PromiseContent episteme)"]
  C["Commitment<br/>(deontic relation, when current)"]
  RA["Provider role assignment<br/>(A.2.1 relation occurrence)"]
  W["Delivery work<br/>(U.Work occurrence)"]
  EV["Evidence epistemes<br/>(observations used as evidence)"]
  EW["Acceptance evaluation<br/>(U.Work occurrence)"]
  ER["Evaluation result<br/>(U.Episteme with verdict value)"]

  C -->|"refers to"| SC
  %% The accountable-subject position of the commitment is filled directly; no universal commitment-to-assignment relation is asserted.
  W -->|"performedUnderAssignment"| RA
  EW -->|"evaluates selected facts about"| W
  EW -->|"criteria from"| SC
  EW -->|"evaluation operation; result binding stated in ER"| ER
  EV -->|"A.10 evidence relation supports verdict assertion in"| ER

Reading guide (one breath).

• The promise content is the consumer-facing outcome and acceptance statement.
• In the A.2.8 commitment relation, the accountable-subject position is filled directly and the referents position contains the promise-content clause.
• The provider role assignment identifies the holder system, provider role, role-taxonomy episteme, effective reference scheme, and assignment window. The holder system acts under that assignment.
• A.6.P:4.11a recovers the concrete referent or relation denoted by service wording. It adds no service-situation participant: provider assignment, access description, access-point system, delivery system, delivery method, promise content, and work occurrence retain their direct kinds and governing patterns; A.10 separately governs the evidence relations.
• Delivery work is what happened. Evidence relations support claims about selected facts concerning that occurrence and any post-work state expressed by its selected effect Delta. A system performing evaluation work enacts the declared evaluation method over those facts and states; the actual evaluation operation has its own result binding, and a separately constituted evaluation-result episteme may carry the verdict assertion.

Litmus rule (addressability). If the current claim is about invocation, connection, visitation, restart, or scaling, first use A.6.P:4.11a to recover the exact process, deployed component, endpoint, application, host, cluster, desk, or other bearer. That cue establishes neither U.System nor a whole delivery-system boundary. Apply A.1/A.1.SCR only when the repaired claim depends on systemhood; after recognition, call the entity a service access point or service delivery system only when that exact boundary claim is current. Otherwise keep the exact bearer and keep promise content separate.

#Archetypal grounding (engineer‑manager friendly)

Worked-case premise. E.24.UK has already admitted the public U.System kind. Every exact entity named as a system in the rows below independently satisfies the complete A.1 criterion, including acting eligibility. If that premise cannot be established, keep the exact entity without system membership and stop only the provider-assignment, access-point, delivery-system, or Work-attribution claim that depends on it; other direct claims may continue under their owners.

Key takeaway. The same pattern yields one promise-content episteme in each domain without treating the promise as the provider, access point, method, work occurrence, evidence, operation-result binding, or verdict episteme. Direct role-assignment, PromiseContentUse, evaluation-operation, evidence, acceptance, and publication relations retain their own participants and governors; evaluation remains separately performed U.Work.

Locality replay. In the cloud-storage row, identify CloudStoragePromiseContent-v3, CloudStorageOfferScheme-2026, and EligibleStorageAccounts-EU-2026Q3 as the exact promise-content edition, its effective scheme, and its U.ClaimScope. Then PromiseContentUse(PUT-2026-07-14-1042, CloudStoragePromiseContent-v3, Interval-PUT-1042) ties one dated delivery-work occurrence to that edition. Name a selected model-use structure only in a receiving assertion or use that is actually model-local. If another catalog scheme must be consumed, add the exact obtaining F.9 Bridge and the separate current claim that it is suitable for this bounded use, then follow F.9's two reliance branches: ordinary below-threshold use with no assurance claim requires the exact A.10 evidence-provenance graph relation and RelianceDisposition=pass for this use; assurance-bearing or threshold use enters B.3, decides first whether a current assurance claim exists, and requires either a positive current assurance claim carrying the same bounded assurance use with its sufficient minimum reliance safety assurance record or an explicit non-positive disposition that stops or narrows the use. None of those objects creates the promise use, delivery work, fulfilment, result, or publication.

#Bias-Annotation

A.2.3 repairs the collapse of several service-related referents into one service label. A visible service name often denotes provider, access point, method, work, commitment, ticket, evidence, and promised outcome without saying which claim is current. The pattern recovers the promise-content episteme first; A.2.8 then governs commitment, A.2.1 provider participation, A.3.2 access description, A.15.1 delivery work, A.10 evidence claims, and the direct outcome and acceptance patterns their respective relations.

In a contract or SLA agreement, an A.2.8 U.Commitment may have promise content in its referents position. A contract document, SLA publication, service catalog, API page, or offer publication may be a U.PresentationCarrier for U.EpistemePublication values describing the agreement, promise content, commitment, or fulfilment work. These relations, epistemes, and carriers retain separate identities.

#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 -> one named U.RoleAssignment occurrence with holder system, provider role value, role-taxonomy episteme, effective reference scheme, and assignment window. The admitted holder system performs each selected delivery-work occurrence under that assignment; when stated as a direct relation, use performedUnderAssignment(deliveryWork, providerRA).
• 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 -> an A.2.8 U.Commitment occurrence whose referents position is filled by the relevant U.PromiseContent. Use A.6.C when one SLA publication combines wording about commitment, promise content, evidence specification, and publication relations and must be unpacked through its Contract Bundle lens.
• Published SLA terms -> the U.EpistemePublication for the promise content, together with its isCarriedBy relation to a U.PresentationCarrier. 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, then use the resulting OutcomeSpec.resultSpec.entityOfConcernRef together with the exact affected referent, post-work state, and any direct delivery or acceptance relation current for the 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 governed role assignment or ownership/custody relation and its actual participants. Do not make ownership or custody 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/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, each attributed through its own performedUnderAssignment(W, RA) relation to a named assignment whose holder system actually performs the work. 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 calls for a new or revised U.Capability instance, use A.2.2 for that capability instance and its currentness relations.
• Service-enabled consumer-side capability or activity -> If the question is about ability, identify the consumer holder's U.Capability instance and state its A.2.2 qualification and currentness claim. 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.

#Conformance Checklist (normative)

CC‑A2.3‑0 (Prose head phrase). In normative prose, an instance of U.PromiseContent SHALL be referred to as a promise content (or service offering clause or service promise clause) and SHALL NOT be referenced by the bare head noun service. Separately, apply E.10 L-SERV and A.6.P:4.11a when service or access-like wording occurs in a relied-on FPF claim, recommendation, decision, gate, assurance, publication, or reuse and hides the concrete subject, participant, predicate, kind, permission, Work occurrence, or next route. Quoted, historical, illustrative, and harmless ordinary wording remains outside this recovery rule.

CC‑A2.3‑1 (Type). U.PromiseContent IS a consumer-facing promise-content U.Episteme. One or more U.EpistemePublication values may be related to U.PresentationCarrier values through isCarriedBy without changing the promise-content episteme identity; no presentation carrier is the promise content. U.PromiseContent is not a U.System, U.Method, U.MethodDescription, U.Work, or U.WorkPlan.

CC-A2.3-2 (Semantic locality). Every promise content names its effective U.ReferenceScheme, promisedOutcomeSpecRef, and exact U.ClaimScope. A selected BoundedModelUseStructure may be designated only by the receiving assertion or use when it changes one actually model-local interpretation; it is neither a promise-content field nor an optional participant or identity discriminator of PromiseContentUse. CC-A2.3-3 (Role values stay distinct from holders and assignments). providerRole and, when present, consumerRole are U.Role values interpreted through a named role-taxonomy episteme and effective reference scheme. Actual provider and consumer systems enter through named U.RoleAssignment occurrences; a role label alone does not identify a performer.

CC-A2.3-4 (Acceptance). acceptanceSpec MUST be present and MUST define how delivered U.Work is judged as pass, fail, or a declared grade against named evaluation criteria and target values. Any SLA deontics are represented through U.Commitment. The promise content MUST declare Claim scope (G) where operating conditions, populations, locales, or another claim extent matter. Every verdict cites an explicit Gamma_time window. If the acceptance criteria mention measurable characteristics such as availability, latency, accuracy, cost, or safety, each characteristic MUST be introduced through C.16 and C.25 with its scale, unit when applicable, U.DHCMethod measurement template, and direct evidence relation. If the reading depends on a particular way of measuring, cite the U.MethodDescription that describes that measurement method. The characteristic is referenced by its exact identifier rather than by an unqualified KPI label.

CC‑A2.3‑5 (Access). When the promised use relies on a request-facing access Method, accessSpec MUST identify the A.3.2-admitted U.MethodDescription that describes it. Separately recover the endpoint, desk, manifold, or other exact bearer through A.6.P:4.11a. Apply A.1/A.1.SCR only when a current claim depends on that bearer being an access-point U.System; otherwise keep the bearer without the stronger claim. If no access-method description is current because access is ambient, accessSpec may be omitted. In either branch, keep an eligibility predicate in the promise content when eligibility is promised; when eligibility depends on a separately obtaining admission relation, refer to that relation under its direct owner.

CC‑A2.3‑6 (Unit of delivery + counting rule). When fulfilment work is counted, declare unitOfDelivery (for example, one request, kWh, or case). The resulting count may fill a declared quantity position in a separately governed charging relation; that charging relation does not determine the unit-of-delivery specification. When declared, unitOfDelivery MUST include a countingRule that maps accepted delivery work episodes (W✓) to unit counts (A.7:5.10). If omitted, the default is “1 unit per accepted delivery work episode”.

CC‑A2.3‑7 (No actuals on Promise Content). Resource and time actuals belong to the performed U.Work occurrence under A.15.1. An incident-log episteme may describe that occurrence and may separately participate in an evidence relation for a stated claim; neither the log nor its participation in that evidence relation fills a U.PromiseContent slot.

CC-A2.3-8 (Provider capability stays separate). When delivery depends on provider ability, use the A.2.2 U.Capability instance for the provider holder system and the separate capability-fit predicate for the planned delivery work. Do not insert capability into promise-content identity or infer capability or fit from the role name. CC-A2.3-9 (Edition and promise-use interval). A change to content, promisedOutcomeSpecRef, or effectiveReferenceScheme creates a new promise-content episteme edition under the C.2.1 identity rule. Each PromiseContentUse occurrence has one promise-content edition and one delivery-work occurrence as participants and PromiseUseIntervalSlot as its temporal qualifier; an untyped version or timespan entry fills none of those positions.

CC‑A2.3‑10 (Lexical rule). Apply E.10 L-SERV and A.6.P:4.11a only when service or access-like wording occurs in a relied-on FPF claim, recommendation, decision, gate, assurance, publication, or reuse and hides the concrete subject, participant, predicate, kind, permission, Work occurrence, or next route. The author MUST name that hidden choice or stop the relied-on use; quoted, historical, illustrative, and harmless ordinary wording is outside this rule.

CC‑A2.3‑11 (No mereology). Do not place a promise content clause in PBS or SBS, or treat it as a part or component. Structural assemblies live in PBS and SBS; the promise clause is an episteme (A.2.3). When relied-on service wording still hides a concrete referent or relation, recover that hidden choice through A.6.P:4.11a; clear, quoted, historical, illustrative, and harmless ordinary wording creates no additional recovery duty.

CC-A2.3-12 (Plan, work, and evidence stay distinct). Windows and calendars belong to U.WorkPlan (A.15.2). Performed delivery belongs to U.Work (A.15.1). Evidence epistemes and evidence relations support claims about selected facts concerning that work and any post-work state expressed by its selected effect Delta; they are not slots or parts of the work occurrence.

CC-A2.3-13 (Claim scope, work scope, and promise-use interval). The promise-content episteme names one exact U.ClaimScope; an intended maximal extent is stated as that scope rather than represented by omission. A provider capability instance separately names U.WorkScope. PromiseUseIntervalSlot is the temporal qualifier of each PromiseContentUse occurrence. The ScopeCoverage predicate is satisfied only when the selected context slice is covered under an explicit Gamma_time selector; neither temporal extent nor capability scope replaces claim scope.

CC-A2.3-14 (Scheme and scope bridges). Cross-scheme reuse first names the exact obtaining F.9 Bridge occurrence. A separate current C.2.1 claim with affirmative polarity must say that this Bridge is suitable for the named bounded promise-content use, in the stated direction, under the use-specific correspondence rule, and within the permitted-loss tolerance. Positive reliance then branches by use. Ordinary below-threshold use with no assurance claim requires the exact A.10 evidence-provenance graph relation with RelianceDisposition=pass for that same use. When an assurance claim is made or B.3's material-reliance threshold is met, enter B.3 and first decide whether a current assurance claim exists. Positive B.3 reliance is available only when a positive current assurance claim carries the same bounded assurance use together with its sufficient minimum reliance safety assurance record; otherwise state the exact no-assurance-claim, insufficient-record, narrowed, rejected, withdrawn, abstaining, or blocked disposition and stop or narrow that use. Cross-scope reuse separately names the mapped U.ClaimScope and its A.2.6 scope relations. A Bridge, its profile, a Bridge Card, a label, or a publication establishes none of PromiseContentUse, delivery, fulfilment, evidence, assurance, work, result, or publication occurrence; a missing premise stops positive reuse without mutating the original promise content. CC-A2.3-15 (OutcomeSpec typing). promisedOutcomeSpecRef MUST be a U.EpistemeRef resolving to an A.7 OutcomeSpec specification-use episteme. It MUST NOT point at a concrete U.Work occurrence, affected or delivered entity, actual operation-result binding, verdict episteme, or downstream effect, and OutcomeSpec MUST NOT be written as an independently admitted U.OutcomeSpec.

CC-A2.3-16 (OutcomeSpec is explicit and mode‑complete). promisedOutcomeSpecRef MUST be present and MUST reference an OutcomeSpec that declares mode in {WorkOnly, ResultOnly, Composite} and satisfies A.7:5.10 mode completeness:

• WorkOnly → workSpec present, resultSpec absent
• ResultOnly → resultSpec present, workSpec absent
• Composite → both workSpec and resultSpec present

CC-A2.3-17 (OutcomeSpec predicates and delivery-work relations). For any delivery U.Work occurrence named by PromiseContentUse, let OS be the A.7 OutcomeSpec resolved from SC.promisedOutcomeSpecRef.

• If OS.workSpec is present, the selected facts about the work occurrence satisfy OS.workSpec.workPredicateRef; when methodConstraintRef is present, the enacted method is compatible with that constraint.
• If OS.resultSpec is present, the exact affected referent and post-work state expressed by the selected effect Delta satisfy OS.resultSpec.postConditionRef on its declared state plane; any production, delivery, acceptance, or receiving-use claim remains separately governed.
• A.10 evidence relations obtain between each relied-on satisfaction assertion and its supporting evidence epistemes. Those evidence epistemes are neither delivery-work occurrences, affected or delivered entities, operation-result bindings, verdict epistemes, nor values of OutcomeSpec.workSpec or OutcomeSpec.resultSpec.

Explicitly individuate PromisedOutcomeDeliveryRelation only when a downstream relation or claim must refer to its occurrence identity and only after these mode-specific conditions are established; otherwise retain the readable deliversPromisedOutcome(W, OS) assertion. CC-A2.3-18 (Acceptance evaluation supports rather than constitutes fulfilment). A holder system performs evaluation work by the evaluation method described in acceptanceSpec over the same selected work facts and post-work states used to test delivery under SC.promisedOutcomeSpecRef. The actual evaluation-operation application carries its exact argument and result bindings. When a durable verdict episteme is needed, C.2.1 governs its identity and A.15.PROD governs any current entity-identity-inception claim. That episteme may assert an admitted fulfilment verdict only when the selected work facts and post-work state satisfy the acceptance criteria. A.10 evidence relations support the relied-on assertions; the operation-result binding, verdict episteme, and evidence relations support knowledge of PromiseContentFulfilmentRelation but do not make it obtain. A multi-grade verdict-scale description states how non-delivery is represented.

CC-A2.3-19 (OutcomeSpec ↔ unitOfDelivery coherence). If unitOfDelivery is present, its counting rule states a selectorRef that selects only work occurrences eligible to satisfy SC.promisedOutcomeSpecRef in the declared mode. When one occurrence can fulfil several promise contents, the rule states either dedupeKeyRef or a reference to a counting-policy episteme under its direct governing pattern. A selector may denote work occurrences filling FulfilmentWorkOccurrenceSlot in obtaining PromiseContentFulfilmentRelation occurrences; it does not count work for which fulfilment has not been established.

CC-A2.3-20 (Unit-of-delivery is computable from work facts). If unitOfDelivery is present, it MUST declare its counting rule over selected facts about fulfilment work, cite the U.DHCMethod used for any measurement reading, name the U.MethodDescription when a particular measurement method constrains that reading, state evidence-admissibility conditions, and refer to the evidence epistemes and A.10 evidence relations used, per A.7:5.10.3. The default "1 unit per fulfilment work occurrence" is permitted only for a pure count of fulfilment occurrences.

#Promise-content use, delivery, evaluation, and evidence

Keep PromiseContentUse, PromisedOutcomeDeliveryRelation, evaluation U.Work, the actual evaluation-operation application and result binding, any verdict episteme, and A.10 evidence relations separate. A direct relation may obtain even when the current episteme about it is unresolved; evidence supports the claim and does not become the relation.

#Core relations

PromiseContentUse : U.Relation. This direct use relation obtains between one delivery-work occurrence and one promise-content edition during one named promise-use interval; it makes no fulfilment claim.

PromiseContentUse : U.Relation
  DeliveryWorkOccurrenceSlot: U.Work, U.EntityRef
  PromiseContentSlot: U.PromiseContent, U.EpistemeRef
  PromiseUseIntervalSlot: temporal interval, byValue

Its occurrence key is <DeliveryWorkOccurrenceSlot, PromiseContentSlot, PromiseUseIntervalSlot>. Obtaining of this relation implies neither successful delivery nor intention, judgement, or claim-making by either participant.

PromisedOutcomeDeliveryRelation : U.Relation. This derived relation obtains between one delivery-work occurrence and the A.7 OutcomeSpec resolved from the PromiseContentUse occurrence in which that work participates, when the conditions below hold.

PromisedOutcomeDeliveryRelation : U.Relation
  DeliveryWorkOccurrenceSlot: U.Work, U.EntityRef
  PromisedOutcomeSpecificationSlot: U.Episteme, U.EpistemeRef constrained to A.7 OutcomeSpec

The relation obtains only when one PromiseContentUse occurrence has the delivery work and a promise-content edition as participants, that edition's promisedOutcomeSpecRef resolves to the same OutcomeSpec, and the specification's mode-specific conditions hold. When workSpec is present, selected work facts satisfy workSpec.workPredicateRef. When resultSpec is present, the exact affected referent and post-work state expressed by the selected effect Delta satisfy resultSpec.postConditionRef; any current production, delivery, or acceptance relation remains separately governed. Its occurrence key is <DeliveryWorkOccurrenceSlot, PromisedOutcomeSpecificationSlot>. The readable predicate is deliversPromisedOutcome(W, OS), where OS denotes that resolved OutcomeSpec. An episteme may assert that this relation obtains, and evidence may support that assertion; neither the assertion nor the evidence makes the work facts or post-work state satisfy the specification.

Acceptance evaluation result. A holder system performs evaluation U.Work by the evaluation method described in acceptanceSpec, using the same selected facts about delivery work and post-work states. The actual evaluation-operation application carries exact argument bindings and the verdict value in its declared result binding. When another use needs a durable evaluation-result episteme, C.2.1 governs that episteme, and A.15.PROD governs any current identity-inception claim linking exact work, actual change, and episteme identity. A.10 evidence relations support the relied-on assertions. The promise content does not perform the evaluation or compute the verdict; the operation-result binding, result episteme, and evidence relations support the assertion rather than making the fulfilment relation obtain.

PromiseContentFulfilmentRelation : U.Relation. This derived relation obtains between one delivery-work occurrence and one promise-content edition when the conditions below hold.

PromiseContentFulfilmentRelation : U.Relation
  FulfilmentWorkOccurrenceSlot: U.Work, U.EntityRef
  FulfilledPromiseContentSlot: U.PromiseContent, U.EpistemeRef

The semantic predicate for this relation is satisfied only when PromiseContentUse obtains for the same work and promise-content participants, PromisedOutcomeDeliveryRelation obtains for that work and the OutcomeSpec resolved from that promise content, and the acceptance predicate declared by acceptanceSpec is satisfied for the exact delivery-work facts, affected or delivered entities, post-work state, and any direct delivery or acceptance relation required by the criterion. PromiseContentFulfilmentRelation obtains for the declared participants when that semantic predicate is satisfied. Its occurrence key is <FulfilmentWorkOccurrenceSlot, FulfilledPromiseContentSlot>. The readable predicate is fulfilsPromiseContent(W, SC). A later evaluation may change the supported assertion about whether the relation obtains; it does not change relation identity. When satisfaction of any required predicate is unresolved, no positive fulfilment assertion is available for reliance.

The explicit RelationSignature declarations are warranted only when unitOfDelivery selectors or fulfilment measures refer to relation-occurrence identity. Ordinary prose may stop at the readable predicates when no later relation refers to that occurrence identity.

Invariant: fulfilsPromiseContent(W, SC) implies PromiseContentUse(W, SC, T), deliversPromisedOutcome(W, resolve(SC.promisedOutcomeSpecRef)), and satisfaction of the acceptance criteria declared in SC.acceptanceSpec; an evaluation-result episteme and A.10 evidence relations support the corresponding assertion without becoming relation participants. Invariant: One work occurrence can fulfil several promise contents only when each promise content's counting rule states dedupeKeyRef or refers to a counting-policy episteme under its direct governing pattern; no silent double counting.

#Promise-content delivery measures

Let W(SC, T) be the set of delivery-work occurrences for which PromiseContentUse obtains with SC during interval T. Let W✓(SC, T) be the subset for which PromiseContentFulfilmentRelation obtains with SC.

• Delivered units: delivered(SC, T) is computed from the set W✓(SC, T) using unitOfDelivery’s countingRule (A.7:5.10). Default (when unitOfDelivery is absent): delivered(SC, T) = |W✓(SC, T)| (one unit per accepted delivery work).
• Rejection rate: rejectRate(SC, T) = 1 − |W✓(SC,T)| / |W(SC,T)| (declare handling of partial).
• Lead time: declare the characteristic definition and aggregation separately. The definition may use work duration or request-to-completion delta; the aggregation may use an average or named percentile.
• Availability and uptime claims: select one declared characteristic instead of treating the labels as synonyms. Derive its observed characteristic value from selected work facts and telemetry observations through its C.16 measurement template, Gamma_time policy, and evidence relations; cite a U.MethodDescription when a particular measurement method affects the reading.
• Cost‑to‑serve: sum of Γ_work over W✓ per resource category (A.15.1).

Each resulting U.Measure claim is derived from selected facts about U.Work occurrences through its C.16 measurement template and named A.10 evidence relations; when a particular measurement method matters, its U.MethodDescription is cited. The promise-content episteme is never the bearer of resource or time actuals. Aggregation across time uses the Gamma_time policy referenced by the named C.16 measurement template or acceptance specification; an unqualified KPI label does not select that policy. When a measure needs a B.1.4 temporal-phase aggregation of one carrier, name one ContextTemporalAggregation@Context record and its exact selected policy—for example, union of observed values or their convex hull—together with carrier identity, time window, coverage and non-overlap conditions, and admissible use. If those one-carrier conditions do not hold, return to the direct aggregation owner instead of using this example. Union and convex hull are policy choices, not defaults; Gamma_time does not select either by itself.

#Common misclassification repairs

• A microservice label is being used for the whole service claim. Use A.6.P:4.11a to recover whether the source word denotes service-provision Work, a Method, PromiseContent, provider participation, or an exact deployed process, component, endpoint, application, host, or cluster. Apply A.1/A.1.SCR only when a repaired bearer claim depends on systemhood. Deployment and the label establish neither membership nor a delivery-system/access-point boundary; the consumer-facing outcome and acceptance claims remain in U.PromiseContent.
• An API label is being used for the whole service claim. If the referent is an interface specification, use the exact episteme and U.MethodDescription only when A.3.2 admits it. If it is an addressable endpoint, recover that bearer through A.6.P:4.11a and apply A.1/A.1.SCR only when a current claim depends on systemhood. Neither the API label nor addressability establishes membership, and neither referent is the promise-content episteme.
• A process or procedure label is being used for the whole service claim. Recover the semantic way of doing as U.Method, its description as U.MethodDescription, planned work as U.WorkPlan, and performed occurrences as U.Work. Keep the promised outcome and acceptance claims in U.PromiseContent.
• A ticket or case record is being used for the whole service claim. Recover its claim-bearing content as a ticket or case-description U.Episteme; keep the publication form and U.PresentationCarrier separate. Relate that episteme to the named U.WorkPlan or U.Work occurrence it describes.
• Cost or elapsed time is attached to the promise content. Keep resource and time actuals on the performed U.Work occurrence. Derive a measure over work occurrences participating in PromiseContentUse only through its declared characteristic, C.16 measurement template, named A.10 evidence relations, aggregation rule, and Gamma_time policy; cite a U.MethodDescription when a particular measurement method affects the reading.
• Promise content is placed in a product or system breakdown. Keep the promise content as an episteme. The access and delivery systems may have parts and selected structures under A.22 and C.30; the promise-content episteme is not one of those parts.
• A person or organization name is stored as the provider role. State the U.Role value and role-taxonomy scheme in the promise content. If an actual provider-assignment claim is current, identify the exact person or organization and apply A.1 because A.2.1 requires an admitted holder U.System; otherwise do not create the assignment. Then state the named U.RoleAssignment occurrence and explicit assignment window.

#Existing promise-description repair applications

1. Name the promises. As an informative first pass, list roughly 5–15 consumer-facing promises used by the project; the range is a prompt, not an admission threshold. Represent each as U.PromiseContent with effective reference scheme, promised outcome specification, acceptance specification, and claim scope, plus access specification and unit of delivery when current.
2. Separate provider from promise content. Recover each exact provider, access-point, or delivery bearer through A.6.P:4.11a. Apply A.1/A.1.SCR only where a current provider-assignment, access-point, delivery-system, performer, or other claim depends on systemhood. Then connect a recognized provider holder through a named A.2.1 role assignment only when that participation fact is current.
3. Relate promise content to delivery and evidence. Add PromiseContentUse for every delivery-work occurrence evaluated under the promise. Establish PromisedOutcomeDeliveryRelation only after exact work facts, affected or delivered entities, post-work states, and any direct delivery relation required by the resolved OutcomeSpec satisfy it; establish PromiseContentFulfilmentRelation only after those facts and states satisfy the declared acceptance criteria. Record the actual evaluation-operation result binding, any evaluation-result episteme, the evidence epistemes it cites, and the A.10 evidence relations separately.
4. Define evaluation characteristics. As an informative first pass, select roughly 2–4 characteristics for each promise content; the range is a prompt, not a conformance limit. Use a recognizable §8.2 formula family—availability over a named window, lead time as a declared delta plus aggregation, rejection rate 1 − |W✓| / |W|, or cost-to-serve as summed Work resource use—or state an exact declared alternative. For each characteristic, name its scale, unit when applicable, C.16 measurement template, Gamma_time policy, direct evidence relations, and exact formula; cite a U.MethodDescription when a particular measurement method affects the reading. Do not let a KPI label stand in for this declaration.
5. Bridge domain schemes. If a domain ontology distinguishes business, technical, or internal service kinds and relations, retain its reference scheme and name the exact obtaining F.9 Bridge occurrence for each selected domain sense and FPF counterpart. For the named promise-content use, add the separate current C.2.1 claim that the Bridge is suitable in the required direction under the use-specific rule and loss tolerance. Then follow F.9's exact reliance branch: ordinary below-threshold use with no assurance claim requires the exact A.10 evidence-provenance graph relation and RelianceDisposition=pass for that use; assurance-bearing or threshold use enters B.3's first-claim decision and requires either a positive current assurance claim carrying the same bounded assurance use with its sufficient minimum reliance safety assurance record or an explicit non-positive disposition that stops or narrows the use. Recover PromiseContentUse, work, delivery, fulfilment, result, evidence, assurance, and publication separately under their direct owners; source classes, a profile, or a Bridge Card confer no FPF systemhood and establish none of those objects.
6. Tidy relied-on language. Apply L-SERV and A.6.P:4.11a only when service or access-like wording hides a concrete subject, participant, predicate, kind, permission, Work occurrence, or next route in the current relied-on use. Name that exact choice and its direct owner, or stop the use; use A.1/A.1.SCR only when a recovered bearer claim depends on systemhood. Reserve U.PromiseContent for the consumer-facing promise content, and leave clear, quoted, historical, illustrative, and harmless ordinary wording outside this step.

#Consequences

#Rationale

Everyday "service" language is useful because one label can denote promise content, provider systems, access points, commitments, methods, work occurrences, and evidence epistemes. When those claims guide evaluation or work, FPF distinguishes the referents and states their direct relations. U.PromiseContent gives the promised-outcome side one stable episteme, A.6.P:4.11a recovers the referent intended by the service wording, and each named direct relation remains governed by its direct pattern.

The pattern keeps promise content in the episteme family because it is a clause or description whose outcome and acceptance predicates state conditions on delivery work, affected referents, and post-work states. A fulfilment assertion and the evidence relations supporting it remain distinct from those referents and from the world-side relations whose obtaining the assertion describes. The episteme never becomes an obligation: the referents position of an A.2.8 commitment relation may contain it, an A.2.9 speech-act occurrence may communicate or institute that commitment, and A.6.C may unpack contract or SLA wording carried by a publication, while gate and policy relations remain separate.

#SoTA-Echoing

Service-management, product, utility, platform, and public-service practice all distinguish offers, providers, access channels, service levels, work execution, and evidence of fulfilment, even when everyday language calls all of them "the service". A.2.3 keeps that practical distinction in FPF by giving the consumer-facing promise clause its own episteme value and by returning provider, access, commitment, work, and evidence claims to their governing patterns.

Contract and SLA practice distinguishes promised content from obligation-bearing acts or agreements and from later performance evidence. FPF keeps that separation without importing a domain-specific service taxonomy; the promise-content episteme remains usable across IT, utilities, healthcare, public services, manufacturing support, and other project domains.

#Relations

• Builds on: C.2.1 U.Episteme identity and reference scheme; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; and A.2.6 U.ClaimScope and U.WorkScope. A.1.1 is used only when an independently selected BoundedModelUseStructure changes one named receiving assertion or work use; the structure is not a promise-content constituent or generic relation participant.
• Coordinates with: A.3.1 U.Method; A.3.2 U.MethodDescription; A.15.1 U.Work; A.6.1 for actual operation application and result binding; A.15.PROD for current entity-identity-inception claims; A.15.2 U.WorkPlan; direct affected-subject, delivery, acceptance, and evaluation patterns; A.10 for evidence relations and ordinary bounded reliance; B.3 when assurance is claimed or material reliance triggers it; A.2.8 for commitment; A.2.9 for speech act; A.6.P:4.11a for service-wording restoration; F.9 for exact cross-scheme Bridge occurrences; C.2.1 for the separate bounded-use suitability claim; and A.7 plus the direct publication pattern when specification use or publication is current.
• Constrained by lexical rules: E.10 L‑SERV (service disambiguation); also L‑FUNC, L‑PROC, L‑SCHED, L‑ACT.
• Informs: reporting and assurance patterns for measures over work occurrences participating in PromiseContentUse, plus directly governed catalog entries, exposure relations, charging relations, and entitlement relations when those claims are current.

#Didactic quick distinctions

• Promise content. A consumer-facing episteme stating the promised outcome, any eligibility predicate, effective reference scheme, claim scope, and acceptance specification; its optional accessSpec describes the access method.
• Method and method description. U.Method is the semantic way of doing. U.MethodDescription is an episteme describing that method; neither is delivery work.
• Delivery work, affected subject, and effect Delta. A provider holder system performs U.Work. Exact affected-referent, actual-change, production, delivery, or acceptance claims state what happened under their own governors; the selected effect Delta is a mathematical-lens expression over the affected referent and its pre-work and post-work states.
• Evidence and evaluation. Evidence relations support delivery and satisfaction claims. A separately performed evaluation occurrence has an actual operation application with a declared result binding; any verdict episteme is separately constituted and governed.
• Provider and consumer participation. U.Role values denote participation positions; the role-taxonomy episteme describes their meanings, and the holder-system and assignment-window positions of named U.RoleAssignment occurrences are filled explicitly.
• Measures. U.Measure claims such as availability or lead-time readings derive from selected work facts through named characteristics, C.16 measurement templates, A.10 evidence relations, aggregation rules, and temporal policies; when a particular measurement method matters, its U.MethodDescription is cited.
• Structure boundary. Promise content is not a structural part. The systems that expose access or perform delivery retain their own parts, selected structures, and ArchitectureOf@Context relations.

#A.2.3:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)