FPF Reference

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

Preface node heading:a-6-8-4-0-uts-lex-preparation-mandatory-for-authoring-repair:14418

Content

“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.)