#A.6.8:4.2 — Stable lens: the Service Situation Bundle

Preface node heading:a-6-8-4-2-stable-lens-the-service-situation-bundle:14459

#Content

Define a stable, kind‑labelled qualified record (hyperedge lens) that makes the bundle explicit without introducing a new core entity kind. This record binds already‑defined referents so prose can talk about multiple facets without collapsing them:

serviceSituation(…) — Qualified Relation Record (QRR) lens id

Participant slots (principal facets). The slot names are intentionally prose-facing (engineer-readable): they are meant to make it hard to “silently collapse” clause/principal/system/access/work.

• promiseContentRef : PromiseContentRef Promise content — the U.PromiseContent referent (A.2.3). Plain head: promise content / service offering clause / service promise clause.

• promisedOutcomeSpecRef? : OutcomeSpecRef The promised outcome template described by the clause (U.OutcomeSpec, A.7:5.10). It may constrain:

  • delivery work (work‑only: “do X for ≥5 minutes”),
  • delivered state / artifact (result‑only: “a hole of depth ≥1 m exists”),
  • or both (composite). This is not a concrete U.Work run and not the delivered world object; it is the spec used to judge delivery work and evidence. Invariant: SERV‑INV‑1 (OutcomeSpecness). promisedOutcomeSpecRef MUST denote a U.OutcomeSpec (kind‑labelled episteme), not a U.Work episode and not an extensional result object.

• providerRoleRef : RoleRef The provider role kind named by the clause (typically clauseRef.providerRole).

• providerAssignmentRef? : RoleAssignmentRef The concrete role enactor assignment that holds providerRoleRef in the relevant Context/window (E.10 / A.2.1). This is what everyday talk calls “the service provider” (team/shop/vendor/system).

• providerPrincipalRef? : EntityRef Convenience alias: the accountable principal extracted from providerAssignmentRef (when you need to name the accountable party explicitly).

  • Normative default: commitments attach here (or to the relevant role assignment), not to the access point.

• consumerRoleRef? : RoleRef The consumer role kind named by the clause (typically clauseRef.consumerRole, if present).

• consumerAssignmentRef? : RoleAssignmentRef The concrete role enactor of consumerRoleRef (when needed for accountability/evidence narratives).

• accessSpecRef? : MethodDescriptionRef The service access spec / request‑facing interface description (API signature, OpenAPI, endpoint contract, intake SOP, desk procedure). This is typically promiseContentRef.accessSpec (A.2.3) and is a U.MethodDescription.

• accessPointRef? : SystemRef The service access point — an addressable system/facility/desk/endpoint host through which requests arrive. In lived language this is often called “the service” or “the server”.

• deliverySystemRef? : SystemRef The service delivery / realization system that actually performs the delivery work. In software, this is usually the deployed application + dependencies (and may be behind gateways); in human services, this is the socio‑technical organisation + tooling that does the work.

• deliveryMethodRef? : MethodDescriptionRef The service delivery method / internal procedure/runbook/workflow used to fulfil the clause. This is distinct from accessSpecRef (request‑facing access).

• commitmentRef? : CommitmentRef Deontic binding to deliver the clause (required when the prose uses must/shall/guarantee/SLA force).

• promiseActRef? : SpeechActRef The instituting/promissory act (offer/promise/accept/agree/publish) when relevant.

  Invariant: SERV‑INV‑2 (Responsibility alignment). When the surrounding passage is normative about responsibility (D‑quadrant language), the promissory actor/authorizer of promiseActRef aligns with providerPrincipalRef (or the corresponding providerAssignmentRef), rather than being silently shifted to accessPointRef.

• deliveryWorkRef? : WorkRef The delivery / fulfillment work episode(s) (including incidents, runs, requests) when relevant.

  Invariant: SERV‑INV‑3 (Outcome anchoring). If both deliveryWorkRef and promisedOutcomeSpecRef are present, then the cited Work instance(s) either: (i) explicitly assert deliversPromisedOutcome(deliveryWorkRef, promisedOutcomeSpecRef) (A.2.3:8.1), or (ii) provide sufficient I/O/Δ evidence anchors for that relation to be derived in the Context.

  Invariant: SERV‑INV‑4 (Unit-of-delivery measurability). If promiseContentRef.unitOfDelivery is present, then its countingRule is stated (per A.7:5.10.3, with defaults allowed) and the cited Work carries the measurements required by that rule (duration, quantity, cases, kWh, etc).

• adjudication? : AdjudicationHooks Evidence anchors (e.g., evidenceRefs, carrierRefs) used for acceptance/breach evaluation when the passage asserts actuals.

Qualifier slots (as needed per A.6.P/A.6.B):

• scope? : ClaimScope
• Γ_time? (explicit Γ_time selector per A.2.6; time windows are explicit when the surrounding passage is time‑sensitive)
• viewpoint? : ViewpointRef
• referenceScheme? / representationScheme? (only when needed)

Guidance (didactic). In normative prose, prefer facet‑explicit predicates: if a predicate targets a specific facet (addressability, deontic force, actuals, mechanism), apply it to the corresponding slot rather than to an untyped “service” noun phrase. (Enforced by CC‑A.6.8‑3/4/6/9.)

Agency + grounding clarifications (normative).

• The promise content (promiseContentRef) is promise content; it does not act, deploy, crash, or guarantee. It can be published (via a carrier) and used as payload of a commitment.
• The promisor / commitment‑holder is the provider principal (or its role assignment) unless the Context explicitly models a system as an agent with standing. (See CC‑A.6.8‑8.)
• The access point and delivery system are typically instruments/realizers. The linkage to the accountable principal is expressed via an explicit relation kind (e.g., operated‑by / owned‑by / authorized‑by / fronts / routes‑to). (See SERV‑WF‑1.)

Well‑formedness constraint: SERV‑WF‑1 (Explicit relation typing in bundles). When a serviceSituation(…) binds a principal/role assignment to systems (access point / delivery system), the relation kinds are explicit (prefer A.6.6 base relations when available). Implicit “system implies provider” readings are invalid.

• Mechanism/process claims target deliverySystemRef and/or deliveryMethodRef (and sometimes accessSpecRef if the claim is strictly about interface signature), not promiseContentRef. (See CC‑A.6.8‑9.)

Well‑formedness constraint: SERV‑WF‑2 (Accountable subject present when binding is asserted). If serviceSituation(…) includes commitmentRef and/or promiseActRef, then it also includes an accountable subject slot: (commitmentRef ∨ promiseActRef) ⇒ (providerAssignmentRef ∨ providerPrincipalRef). This prevents “floating” commitments/acts that can’t be routed to a holder/authorizer.

Facet→Kind map (didactic, normative). The bundle exists precisely because these facets are different kinds and therefore admit different predicates: