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.
Separate provider from promise content. Recover each provider, access point, or delivery bearer through A.6.P:4.11a. Apply A.1 or A.1.SCR only where a provider-assignment, access-point, delivery-system, performer, or other claim depends on systemhood. When an assignment is claimed, name its A.2.1 occurrence and declared species, with the provider System as holder.
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.
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.
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 for each selected sense and FPF counterpart. Add the separate C.2.1 claim that the Bridge suits the named use, then require the A.10 evidence-provenance relation with RelianceDisposition=pass. Use B.3 only for an actual named assurance claim. Keep PromiseContentUse, Work, delivery, fulfilment, result, evidence, assurance, and publication separate.
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. State what the wording denotes and use the pattern that defines or constrains that claim, or stop the use; use A.1 or 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.