#Service Polysemy Unpacking (RPR-SERV)

Pattern A.6.8 · Stable · Architectural (A) — A.6.P specialisation (RPR) · Normative Part A - Kernel Architecture Cluster

Plain-name. Service situation unpacking. One-liner: “service” ⇒ clause | promised work‑kind | provider principal/system | access point | access spec | commitment | promise act | delivery method/work

Type: Architectural (A) — A.6.P specialisation (RPR) Status: Stable Normativity: Normative Placement: Part A → A.6 (Precision restoration / stack discipline) Builds on: A.6.P (RPR recipe), A.6.5 (slot discipline), A.6.B (routing), A.2.3 (U.PromiseContent), A.2.8 (U.Commitment), A.2.9 (U.SpeechAct), A.15 (U.Work), E.10 (LEX, incl. L‑SERV, LEX‑BUNDLE & PTG stances), F.17 (UTS — Unified Term Sheet), F.18 (Name Cards / NQD‑front; promise ≠ utterance ≠ commitment). Coordinates with: A.6.C (contract bundle unpacking), A.7 (Object≠Description≠Carrier), G.* evidence discipline (EvidenceGraph / SCR), Context/Bridge policy for cross‑Context reuse, F.8 (Mint/Reuse), E.15 (LEX‑AUTH when refactoring existing prose at scale). Delta-Class: Δ‑3 (new normative pattern; corpus‑wide lexical refactor expected when adopted in Core) Impact radius: Any normative prose that uses the “service” cluster (service, service provider, server); LEX rules (L‑SERV / LEX‑BUNDLE); UTS blocks (F.17); contract/boundary patterns that already talk about services (esp. A.6.C); any automated repair/lint pipeline used for bulk refactors (E.15 / LEX‑AUTH). Mint vs reuse: Mints the serviceSituation(…) QRR lens id and the facet headphrase set defined in §4.3. Reuses U.PromiseContent, U.Commitment, U.SpeechAct, U.System, U.Work, U.MethodDescription, and the A.6.P/QRR recipe. DRR pointer: REQUIRED before Core admission. DRR‑SERV‑POLYSEMY‑<id> (TBD in draft; must cite the PQG run + refactor/harness plan).

Intent. Prevent category errors and metonymic drift caused by the borderline word “service” by forcing every normative mention to name the facet (promise content vs promised work‑kind/effect vs accountable principal vs realization system vs access object vs interface vs binding vs act vs run‑time work/evidence) and by providing a stable “service situation” lens that keeps those facets related without collapsing them.

Non‑goal (modularity guard). This pattern does not redefine the semantics or field structure of the promise‑content object (the promise content). That kernel meaning is defined in A.2.3 (U.PromiseContent). A.6.8 is a precision‑restoration + lexicon discipline that (i) forces facet‑typed head phrases and (ii) provides an optional QRR lens to bind already‑defined kinds without collapsing them. Contract‑talk unpacking is handled by A.6.C, which invokes this pattern when contract language contains the service cluster.

In real engineering language, service can denote (and routinely collapses) multiple facets that admit different predicates and different governance rules:

#Keywords

• service polysemy
• facet unpacking
• serviceSituation QRR
• promise content vs access point
• provider principal
• SLA/SLO
• server/service provider rewrite.

#Relations

#Content

#Problem frame

In real engineering language, service can denote (and routinely collapses) multiple facets that admit different predicates and different governance rules:

• a promise content (U.PromiseContent),
• a promised work‑kind / effect‑kind (“what is to be delivered”, as a kind/template),
• a service provider role (role kind in the clause),
• a service provider principal (role‑enactor accountable for delivery and capable of holding commitments),
• a service access point (an addressable system/facility/desk/endpoint host),
• a service access spec (API surface / endpoint set / SOP visible to consumers),
• a service delivery / realization system (the socio‑technical system that actually performs fulfillment work),
• a service delivery method (workflow/runbook/procedure used to fulfill),
• a service commitment (deontic binding, e.g., SLA/SLO as obligation),
• a service promise act (promissory speech act: offer/promise/accept/agree/publish),
• a service delivery work episode (run/incident/fulfillment work + evidence).

FPF’s kernel uses U.PromiseContent as promise content, which is SoTA‑consistent for contracts and decision lanes, but clashes with the everyday addressability-centric use of “service”. This makes “service” a high‑risk metonymy attractor: authors start using the same word for (a) the clause, (b) the provider system, and (c) the delivery work, and readers cannot reliably recover which is meant.

In addition, lived “service talk” is rarely isolated to the token service: it co‑moves with server and service provider (and with “API service”, “service desk”, “service team”). Treating only the word service as ambiguous is an underfit to the domain.

Critically, everyday “service” often conflates three different participants that are frequently not identical:

1. the provider principal (accountable role‑enactor: a team/org/vendor),
2. the delivery / realization system (the socio‑technical system that does the work),
3. the access point (the addressable entrypoint/gateway/front desk/endpoint host).

This pattern forces those participants apart, because different predicates and different governance rules apply to each.

This pattern makes “service” an always‑unpack token in normative prose: you may use it only as part of a qualified head phrase that states which facet is meant.

#Problem

Unqualified “service” in normative prose causes referent ambiguity that cannot be repaired by reader intuition, because the ambiguity is structural:

1. Addressability mismatch: you can call/visit an access point, but you cannot call a clause.
2. Type mismatch: work/telemetry/incidents are properties of work + carriers, not of promise content.
3. Deontic mismatch: “must/shall/guarantee” binds actors/roles via commitments, not abstract clauses.
4. Speech‑act mismatch: “promise/offer/accept” are events/acts, not the promise content itself.
5. Evolution mismatch: changing an API endpoint or deployment is not “changing the service” unless you declare which facet changed and narrate that change with stable change classes.

Result: reviewers can’t apply A.6.B routing, and engineers are incentivized to preserve ambiguity (“service” as a convenient metonym) because it avoids committing to a model.

#Forces

#Solution

#A.6.8:4.0 — UTS + LEX preparation (mandatory for authoring/repair)

“Service” is a polysemy cluster, not a single token. Therefore, before applying the rewrite rules below to normative prose, the author/editor SHALL create or update a thread‑local UTS block (F.17) and its paired LEX‑BUNDLE entries (E.10) for the service cluster (Tech/Plain twins and PTG stance).

Required cluster coverage (minimum). The UTS block MUST cover, at minimum, the co‑moving surface forms:

• service / services
• service provider (and the corresponding provider term in the domain: team/shop/department/vendor, etc.)
• server (including “daemon”, “host”, “endpoint host” where those appear)
• microservice / microservices (and spelling variants such as “micro-service”) when they appear in the source prose as a stand‑in for the addressable system facet (“the thing you can call/deploy”) or as a collapsed bundle token
• “API service” / “service interface” / “service access” (when present in the source prose)
• “SLA/SLO/service level” language (when present)

Context selection (universality guard). The UTS block MUST cite ContextName@Edition in each SenseCell (F.17), and the cited contexts SHOULD span at least three distinct “service traditions” reflected in this pattern’s SoTA‑Echoing set (e.g., ITSM/service management, EA/modelling, speech‑act/coordination, microservices/SRE practice). This prevents a “FPF‑only” meaning loop and keeps facet names portable.

Headphrase governance (no ad‑hoc synonyms).

• Each facet head phrase used by this pattern (e.g., “promise content”, “service access point”) SHALL appear as a UTS twin (Tech/Plain) in the local UTS block, not as an author‑invented one‑off.
• Both the Tech and Plain twin for a facet head phrase SHALL carry an explicit head kind word that signals the facet category (clause / role / principal / system / access point / spec / method / commitment / act / work). Plain synonyms are permitted only if they preserve the head kind (e.g., “endpoint” as an access‑point head kind; “API spec” as an access‑spec head kind). This is the readability guard that prevents “mathematician renamings”.
• A conforming normative Tech text SHALL treat the bare word service (unqualified) as PTG=Guarded (E.10): it is allowed only under this pattern’s rewrite rules and only as part of a qualified head phrase.
• If a new facet head phrase must be introduced, it SHALL be treated as a LexicalAct with an explicit Mint/Reuse decision (F.8), and its CandidateSet + rationale SHOULD be recorded via a Name Card (F.18 / NQD‑front) to avoid “clever” but unstable vocabulary.

This preparation step is intentionally “linguistic”: it binds the pattern to how engineers actually write (service/provider/server), rather than to an isolated kernel token.

SoTA binding (informative audit anchor). The major disambiguation rules in §4.4–§4.7 are aligned with the SoTA‑Echoing rows in §11:

• “offering / promise content” vs “delivery operations” split → ITIL 4 + EA modeling,
• “interface/access” vs “realization/implementation” split → ArchiMate + SRE practice,
• “promissory act” vs “promise content” split → ISO 24617‑2 dialogue acts,
• “offering/commitment” vs “delivery event” split → service ontologies (e.g., S‑OPL / UFO),
• “actuals/telemetry” vs “targets/obligations” split → SRE evidence discipline,
• “roles + context” emphasis when discussing “service quality” → service science / service‑dominant logic. (These anchors are informative; they do not assert cross‑Context identity and require Bridges when imported as terms.)

#A.6.8:4.1 — Trigger rule

This pattern applies whenever “service” appears in Tech/normative prose as a head noun (including compounds like “X service”, “the service”, “our service”, “this service”), even when the intended referent is U.PromiseContent.

It also applies to the adjacent cluster terms “service provider” and “server” when they are used as stand‑ins for the same collapsed bundle (clause/access/provider/work). The rewrite outcome for those terms is facet‑typed (see §4.3 and §4.9).

Carve‑out (informative, narrow): quotations of external material may retain “service”, but SHALL be followed immediately by an unpacking rewrite in the surrounding normative text.

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

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:

#A.6.8:4.3 — Facet headwords (mandatory lexical rule)

In normative prose, replace the head word “service” with one of the following facet head phrases:

1. promise content (or service offering clause / service promise clause) — promise content (promiseContentRef : PromiseContentRef, i.e., U.PromiseContent)
2. promised outcome spec (or promised deliverable spec) — what is promised as an outcome template (work‑only / result‑only / composite) (promisedOutcomeSpecRef)
3. service provider role — the provider role kind (providerRoleRef : RoleRef) when the text is about role structure (not about actuals)
4. service provider principal (or service provider (role enactor)) — the accountable provider that can hold commitments (providerAssignmentRef / providerPrincipalRef)
5. service delivery system (or service realization system) — the system that performs/realizes delivery (deliverySystemRef : SystemRef)
6. service access point (or service endpoint) — addressable entrypoint (accessPointRef : SystemRef); this is the “thing you can call/visit”
7. service access spec (or service interface spec) — request‑facing interface/method description (accessSpecRef : MethodDescriptionRef)
8. service delivery method (or service method / service runbook / procedure) — internal procedure for fulfilment (deliveryMethodRef : MethodDescriptionRef)
9. service commitment — deontic binding (commitmentRef : CommitmentRef)
10. service promise act (or promissory speech act) — speech act (promiseActRef : SpeechActRef)
11. service delivery work (or service run / fulfillment work) — execution episode (deliveryWorkRef : WorkRef)

SERV‑LEX‑3 (Family‑name modifier + shorthand, normative). The facet head phrases above are canonical for RPR‑SERV. In normative prose, authors SHALL use these phrases (including the family‑name modifier service) as the primary surface forms for the facets. The modifier service inside these phrases is not an “unqualified service” use and does not itself trigger further unpacking. For readability, a local shorthand MAY be introduced by parenthetical declaration immediately after the canonical phrase, and then used consistently within that declared scope (for example: “service delivery system (delivery system)”). A conforming text SHALL NOT introduce multiple shorthands for the same facet, and SHALL NOT reuse a shorthand for a different facet. In code identifiers, slot names (e.g., deliverySystemRef in serviceSituation(…)), and diagrams/tables, the modifier MAY be omitted without an explicit shorthand declaration, because the surrounding construct already binds the facet.

Cluster note (server/provider) — heuristics (informative).

• If the draft uses server as a synonym for “the service”, it usually denotes the service access point (or host system), unless the domain’s “server” is explicitly a person (e.g., restaurant).
• If the draft uses service provider but then predicates deployment/restart/latency, it usually denotes a service delivery system or service access point, not an accountable principal.
• If the draft uses service provider but then predicates “guarantees / obligated”, it usually denotes the service provider principal plus an explicit service commitment.
• If a passage attributes promissory agency to a machine (“the server promises”), treat the machine as a carrier/witness unless the Context explicitly grants it standing as an agent.

(Normative enforcement is via CC‑A.6.8‑1 and CC‑A.6.8‑8.)

#A.6.8:4.4 — Addressability rule (the “can you call it?” test)

If the draft sentence implies addressability (verbs like call/invoke/request/visit/go to/connect to/route to/deploy/restart/scale), then the referent MUST be a service access point (accessPointRef : SystemRef) or a work episode (deliveryWorkRef), never the promise content.

#A.6.8:4.4b — Method/mechanism rule (the “how does it work?” test)

If the draft sentence asserts or explains how the service works (verbs like implement/realize/work by/uses/consists of/pipeline/algorithm/workflow/runbook/process steps) then the referent MUST be a service delivery system (deliverySystemRef) and/or a service delivery method (deliveryMethodRef).

If the draft uses service as the name of a promised work method (common in plain language: “cleaning”, “repair”, “haircutting”), treat that as part of the promise by constraining the U.OutcomeSpec.workSpec.methodConstraintRef (what is promised). Keep deliveryMethodRef for the provider‑internal runbook/procedure that realizes the promise (how it is executed).

If the draft sentence is specifically about the externally visible signature/shape (endpoints, request/response schema, SOP steps visible to consumers), route it to service access spec (accessSpecRef).

A conforming text SHALL NOT attach mechanism/process predicates to the promise content; the clause may constrain outcomes or acceptance criteria, but mechanism claims belong to design/method artefacts. (See CC‑A.6.8‑9.)

#A.6.8:4.5 — Deontic rule (the “must/shall” test)

If the sentence contains deontic force (must/shall/guarantee/obligated/SLA), the referent MUST include a service commitment slot, and the deontic language MUST attach to the commitment/holder, not to the clause or to the access point.

When the prose needs a subject, prefer: “the service provider principal SHALL … under commitment C” rather than “the service SHALL …”.

No hidden agency rule (normative): A conforming text SHALL NOT use an access object (e.g., endpoint/access point) as the grammatical subject of an RFC‑keyword sentence. It SHALL use the accountable principal (or role assignment) as subject and then state the operational condition on the access point as a predicate/evidence claim. (See CC‑A.6.8‑4 and CC‑A.6.8‑8.)

#A.6.8:4.6 — Speech‑act rule (the performative verb test)

If the sentence uses performatives (promise/offer/accept/agree/commit/announce/publish), the referent MUST include a service promise act (promiseActRef) and must not collapse the act into the clause.

If a server/webpage/API response is involved, a conforming text SHALL treat it as a carrier/witness of the promise act unless the Context explicitly grants it standing as an agent. A conforming text SHALL keep the promissory actor/authorizer aligned with the provider principal.

#A.6.8:4.7 — Runtime/telemetry rule (the “actuals” test)

If the sentence asserts actuals (down/slow/99.9% last week/latency is X/incident occurred), the claim MUST be routed to work + carriers/evidence (deliveryWorkRef + witnesses), not to the clause.

If an actual is used in a conformance block, KPI, or acceptance argument, it MUST cite the underlying U.Characteristic and measurement procedure/evidence carrier (C.16/C.25), with pinned {UnitType, ScaleKind, ReferencePlane, EditionId}; otherwise it is prose only and MUST NOT be treated as a verified SLO/SLA measurement.

When needed, also name whether the actual is about the access point (entrypoint symptoms) or the delivery system (realizer symptoms). “Down” can be about the gateway even when the backend is fine; the pattern forbids collapsing those.

#A.6.8:4.8 — Change‑class lexicon (service‑specific narrations)

When the draft describes “service changes”, narrate changes using stable change classes (A.6.P), specialized to the serviceSituation lens:

• declareRelation(serviceSituation(…)) (introduce the bundle)
• withdrawRelation(serviceSituation@ed=k) (retire the bundle)
• retargetParticipant(accessPointRef := …) (move the access point / endpoint host)
• retargetParticipant(deliverySystemRef := …) (change the realizing delivery system; e.g., re‑platforming)
• retargetParticipant(providerAssignmentRef := …) (change provider role‑enactor; outsourcing / org change)
• reviseByValue(accessSpecRef := …) (edit interface description content)
• reviseByValue(deliveryMethodRef := …) (edit runbook/workflow/procedure)
• reviseByValue(promiseContentRef := …) (edit promise content; typically new edition)
• changeRelationKind is not applicable here unless splitting the family (rare)
• rescope, retime(Γ_time), refreshWitnesses(witnesses := …) as required

#A.6.8:4.9 — Disambiguation guide (rewrite/selection)

If the draft says:

• “the service is deployed/restarted/scaled/called” → rewrite as service access point (system) or service delivery work (deployment work), and (optionally) attach it to a serviceSituation.
• “the service promises/guarantees X” → rewrite as promise content (promise content), and if “guarantees” is deontic, also introduce service commitment held by the service provider principal.
• “the service is down/slow/has 5xx” → rewrite as service access point (down) and/or service delivery work (incident/run), with evidence.
• “we promised the service” / “we agreed the service” → rewrite as service promise act + promise content (+ commitment if binding).
• “the service provider guarantees X” → rewrite as service provider (role enactor) + service commitment (+ promise content as payload).
• “the server is down / slow / restarted” → rewrite as service access point (server/host system) and/or delivery work, not as clause.
• “the service is implemented by / realized by / works by doing Y” → rewrite as service delivery system and/or service delivery method (and keep the clause separate as the outcome constraint).
• “the service API signature / endpoint schema / request format is …” → rewrite as service access spec.
• “the service ticket / service request” → rewrite as ticket / request work item; “service” is adjectival legacy and must be eliminated or mapped via LEX.

#Archetypal grounding

Tell. A “service” is not a single thing. In normative prose you MUST name which facet you mean, and (when needed) tie facets together via a serviceSituation(…) record so readers can follow accountability, access, deontics, and evidence without guessing.

#Show 1 — System archetype (microservices + SRE)

Draft (ambiguous): “Payments service is down; the service guarantees 99.9% uptime; we will restart the service.”

Unpacked (facet‑explicit):

• “The Payments service access point (the Payments API ingress/endpoint host) is down.”
• “The Payments service delivery system (the Payments backend realizer) is degraded (symptom attribution is explicit).”
• “The Payments service access spec (e.g., OpenAPI/endpoint contract) defines the request/response interface.”
• “The Payments promise content states target availability SLO=99.9% over Γ_time=30d (promise content).”
• “The service commitment held by the service provider principal binds them to that clause.”
• “The service delivery work Incident#2025‑… records outage evidence and the restart action; the runbook used is the service delivery method.”

Optional serviceSituation bundle (sketch):

• serviceSituation( promiseContentRef=PaymentsAvailabilityClause, providerRoleRef=PaymentsPlatform#ServiceProviderRole, providerPrincipalRef=PaymentsPlatformTeam, accessSpecRef=PaymentsAPIv2, accessPointRef=PaymentsAPIIngressProd, deliverySystemRef=PaymentsBackendProd, deliveryMethodRef=PaymentsIncidentRunbook@ed=…, commitmentRef=AvailabilityCommitment@ed=…, deliveryWorkRef=Incident#…, Γ_time=Rolling30d, witnesses={SLOReport#…, IncidentLog#…} )

#Show 2 — Episteme archetype (physical/human service)

Draft (ambiguous): “The auto service accepts walk‑ins and promises repair in 2 days.”

Unpacked (facet‑explicit):

• “The service access point is the Auto Repair Shop front desk (an addressable facility).”
• “The service access spec is the intake procedure (how to request/submit a car).”
• “The promise content promises ‘repair completed within 2 business days’ given stated preconditions.”
• “The service delivery method is the shop workflow (inspection → parts ordering → repair → QA → handover).”
• “The service provider principal is the shop entity that can hold a commitment (not the front desk as an access point).”
• “If advertised as binding, introduce a service commitment held by the shop’s provider role.”
• “Each repair job is service delivery work with evidence (work order, timestamps, acceptance sign‑off).”

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did.

• Gov bias: favors explicit accountability (provider role + commitment) and audit surfaces (witnesses); increases enforceability but raises authoring burden.
• Arch bias: encourages bundle/record lenses and explicit interfaces; may feel heavyweight for informal notes.
• Onto/Epist bias: strongly separates clause vs system vs work vs deontic; prevents category errors but reduces metaphor-friendly storytelling.
• Prag bias: optimizes for cross-team readability and reduced rework; may require refactoring existing prose at scale.
• Did bias: enforces teachable tests (“can you call it?”, “is it deontic?”, “is it actuals?”); can appear prescriptive but improves onboarding.

#Conformance Checklist (CC‑A.6.8)

0. CC‑A.6.8‑0 — UTS/LEX block exists for the service cluster. Any document that applies this pattern (or that introduces normative “service” language) SHALL publish: (a) a local UTS block (F.17), and (b) paired LEX‑BUNDLE entries (E.10) for the Tech/Plain twins and PTG stances used here.

   • Minimum cluster coverage SHALL include: service/services, service provider, server, microservice/microservices when present in the source prose, plus the chosen facet head phrases. If the document uses “API service / service interface / service access” or SLA/SLO/service‑level language, the local UTS/LEX block SHALL include those surface forms as well. Each SenseCell SHALL cite ContextName@Edition; cited contexts SHOULD not be “FPF only”. Any newly introduced facet head phrase SHALL have an explicit Mint/Reuse decision (F.8) and SHOULD have a Name Card rationale (F.18).

1. CC‑A.6.8‑1 — Unqualified “service” (and cluster stand‑ins) is forbidden in normative prose. A conforming boundary/spec text SHALL NOT use service as an unqualified head noun, and SHALL NOT use server or bare service provider as untyped stand‑ins for the same collapsed bundle. Every such occurrence SHALL be rewritten to a facet head phrase (promise content / promised work‑kind / service provider role or principal / service delivery system / service access point / service access spec / service commitment / service promise act / service delivery work) or replaced with the correct underlying FPF object (team, ticket, workflow, system, etc.). The facet head phrases in §4.3 are canonical; using service as the family‑name modifier inside those phrases is permitted and does not itself trigger further unpacking. Any local shorthand that drops the modifier is allowed only under SERV‑LEX‑3. Exception: direct quotations may retain the original surface form, but the surrounding normative prose SHALL immediately provide an unpacking rewrite.

2. CC‑A.6.8‑2 — U.PromiseContent is referred to as a “promise content” in prose. When the intended referent is U.PromiseContent, authors SHALL use “promise content” (or “service promise clause”) as the head phrase and SHALL NOT rely on the bare word “service”.

3. CC‑A.6.8‑3 — Addressability implies accessPointRef (system), not clause. Any statement implying invocation/connection/deployment/restart SHALL target a service access point (SystemRef) and/or delivery work, never a promise content (U.PromiseContent).

4. CC‑A.6.8‑4 — Deontic language requires a commitment. Any normative “must/shall/guarantee/SLA” statement about service delivery SHALL introduce (or reference) a U.Commitment and attach the deontic force to that commitment/holder. In addition, a conforming text SHALL NOT use a service access point / server as the grammatical subject of an RFC‑keyword sentence; the subject is the accountable provider principal (or role assignment), with access‑point conditions stated as predicates/evidence.

5. CC‑A.6.8‑5 — Performative verbs require a speech act. Any statement using “promise/offer/accept/agree/announce/publish” about the service SHALL reference a U.SpeechAct (promise act) and SHALL NOT collapse it into the clause.

6. CC‑A.6.8‑6 — Actuals require work + evidence. Any claim about runtime state/telemetry/incidents SHALL be routed to U.Work plus carrier/evidence references; it SHALL NOT be stated as a property of the promise content.

7. CC‑A.6.8‑7 — Bundle lens is used when multiple facets are in play. When a passage simultaneously discusses two or more facets (e.g., clause + endpoint + SLA + incident), the author SHOULD provide a serviceSituation(…) record (or equivalent explicit slot binding) so readers can track the linkage without guesswork. When a serviceSituation(…) record is provided, it SHALL satisfy SERV‑INV‑1, SERV‑INV‑2, and SERV‑WF‑1 from §4.2. When a serviceSituation(…) record is provided and it includes commitmentRef and/or promiseActRef, it SHALL also satisfy SERV‑WF‑2.

8. CC‑A.6.8‑8 — Commitments and promises have an accountable principal. Any statement that introduces a service commitment or service promise act SHALL name (directly or via role assignment) the service provider principal who is the holder/authorizer. A conforming text SHALL NOT attribute commitments/promises to a bare access point/server unless the Context explicitly models it as an agent with standing (and that modelling is declared).

9. CC‑A.6.8‑9 — “How it works” claims route to method/system, not to the clause. Any statement about implementation, mechanism, workflow, runbook, or process SHALL target service delivery system and/or service delivery method (or access spec if it is strictly interface‑signature). It SHALL NOT be stated as a property of the promise content.

#Common Anti-Patterns and How to Avoid Them

• Anti‑pattern: “The service is deployed on Kubernetes.” Fix: “The service access point (deployment) is deployed on Kubernetes.”

• Anti‑pattern: “The service guarantees X.” Fix: “The promise content states target X; the service commitment guarantees X.”

• Anti‑pattern: “The service provider guarantees X.” Fix: “The service provider (role enactor) holds a service commitment that guarantees X; the promise content is the promise content.”

• Anti‑pattern: “The server provides the service (as if server=promise).” Fix: “The service access point (server/host system) provides access; the promise content is promise content; any ‘must/shall’ binds via service commitment.”

• Anti‑pattern: “The service works by doing Y / is implemented with Z.” Fix: “The service delivery system works by doing Y / is implemented with Z; the service delivery method (runbook/workflow) is …; the promise content constrains outcomes/acceptance.”

• Anti‑pattern: “We promised the service.” Fix: “We performed a service promise act that published the promise content (and instituted a commitment if binding).”

• Anti‑pattern: “Service is down (therefore contract violated).” Fix: “The service access point is down (actual). Contract breach evaluation is a separate claim comparing actuals (work/evidence) to the clause + commitment.”

• Anti‑pattern: “Service and API are used interchangeably.” Fix: Use service access spec for the API description; use service access point for the addressable system; use promise content for promise content.

#Consequences

• Pros:

  • Removes the incentive to keep “service” conveniently vague.
  • Enables A.6.B routing: clause (L), commitment (D), acts/work/evidence (E), mechanisms/interfaces (A/L depending on placement).
  • Makes incident/SLO/SLA discourse structurally sound and reviewable.

• Cons:

  • Increases verbosity and requires refactoring existing prose.
  • Requires authors to learn (and consistently apply) facet headwords.

Adoption test (1 minute). After refactoring any normative section that contains ≥ 10 occurrences of the “service” cluster, you can answer “yes” to all of:

1. Unqualified head‑noun “service” occurrences in normative prose are 0 (CC‑A.6.8‑1).
2. Every deontic (“must/shall/guarantee/SLA”) sentence about service delivery references a service commitment / U.Commitment (CC‑A.6.8‑4).
3. Every runtime/telemetry “service is down/slow/…” claim is routed to work + evidence and, when relevant, distinguishes access‑point symptoms from delivery‑system symptoms (CC‑A.6.8‑6 + §4.7).

#Rationale

The ambiguity here is not a simple synonym problem; it is a bundle‑collapse problem. “Service” routinely stands in for different ontological categories (episteme content, system, event, deontic binding). Since the word is too entrenched to ban entirely, the least‑surprising stable repair is:

• keep “service” only as a family name in informal discussion, but
• in normative prose always name the facet and, when needed, explicitly bind facets via a stable bundle lens.

This aligns with A.6.P’s requirement to replace umbrella tokens with explicit kind+slots forms and to provide rewrite guides and guardrails.

#SoTA-Echoing

Informative. Alignment notes; not normative requirements. This section is written to satisfy the SoTA‑Echo obligations for Architectural patterns (post‑2015, multi‑Tradition; adopt/adapt/reject with reasons).

Bridge hygiene note. This section makes no cross‑Context identity claims (no implicit “same thing across traditions”). If a later edit wants cross‑Context reuse of terms or structures from external traditions, it must be mediated by explicit Bridges with declared CL (and plane policy where relevant), per the general SoTA/Bridge discipline.

Pack binding (status). No dedicated SoTA Synthesis Pack is cited here yet for the “service polysemy” cluster; if/when such a pack is published, this section SHOULD be updated to cite the relevant ClaimSheet IDs / CorpusLedger entries (and Bridge ids where reuse is asserted) as the auditable anchors for the alignment statements above.

#Relations

• Specialises: A.6.P (RPR) for the lexical/semantic ambiguity cluster around “service”.
• Operationalises + extends: the lexical disambiguation intent of L‑SERV by making “service” always‑unpack in normative prose (and by expanding the cluster to include service provider and server as co‑moving stand‑ins).
• Requires (authoring discipline): a local UTS block (F.17) and published Tech/Plain twins (E.10) for the service/provider/server cluster; this is the “anti‑FPF‑only loop” guard.
• Coordinates with: A.6.C (contract bundle unpacking). When contract-language includes service tokens, apply RPR‑SERV first to select promise content vs commitment vs access point/system vs work/evidence, then route the resulting atomic statements through A.6.C → A.6.B (L/A/D/E).

#A.6.8:End