A.2.3:8 - 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.

A.2.3:8.1 - 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>.

PromisedOutcomeDeliveryRelation : U.Relation. This derived relation obtains between one delivery-work occurrence and the A.2.3:4.1.1 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.2.3:4.1.1 OutcomeSpec

The relation obtains only when one PromiseContentUse occurrence has the delivery Work and promise-content edition as participants, that edition resolves the same OutcomeSpec, and the mode-specific conditions hold. workSpec tests selected Work facts. resultSpec tests the exact affected referent and selected post-work state; any actual-change, production, delivery, acceptance, receiving-use, or optional Delta-lens claim remains separately governed. Its occurrence key is <DeliveryWorkOccurrenceSlot, PromisedOutcomeSpecificationSlot>. The readable predicate is deliversPromisedOutcome(W, OS). An episteme may assert that this relation obtains and evidence may support the assertion; neither makes the underlying facts satisfy the specification.

Acceptance evaluation result. Follow the §4.3 performer-and-Work route before saying that the evaluation Work enacts the Method selected in acceptanceSpec. Add F.6 only if this result must also state under which assignment the evaluation was performed. A MethodDescription is cited only when its edition-specific claims are used. Keep the operation application, result binding, optional verdict episteme, any identity-inception claim and independently established evidence-use relations separate. A.10’s descriptive evidence-provenance account cites the relevant facts and records reliance for the bounded assertion use; a passing disposition requires the evidence demanded by that claim and its direct acceptance rule. The account and verdict do not make fulfilment 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 exact evaluation-result episteme may support the corresponding assertion through independently established evidence-use relations cited in A.10’s descriptive account; neither that episteme nor the account becomes a fulfilment-relation participant. Counting rule: Separate per-promise counts may each use the default one-unit-per-fulfilment rule. When aggregating counts across promise contents for the same Work occurrence, each applicable counting rule must state its dedupeKeyRef or cite its counting-policy episteme so the resulting quantities are not silently double counted.

A.2.3:8.2 - 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.

Until the membership judgements required by the selected counting rule and reporting window are resolved, withhold an exact delivered count and rejection rate. An unresolved fulfilment judgement is not a rejection.

• Delivered units: delivered(SC, T) is computed from W✓(SC, T) using the A.2.3:4.1.2 counting rule. When unitOfDelivery is absent, delivered(SC, T) = |W✓(SC, T)|, one unit per obtaining fulfilment occurrence.
• Rejection rate: for nonempty W(SC,T), rejectRate(SC, T) = 1 − |W✓(SC,T)| / |W(SC,T)| (declare handling of partial). When W(SC,T) is empty, declare a reporting rule before returning a value; this formula has a zero denominator.
• 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. Resource and time actuals belong to the performed U.Work occurrences. 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, this example is inapplicable; state the aggregation actually required and apply its defining rule. Union and convex hull are policy choices, not defaults; Gamma_time does not select either by itself.