E.10:6.2.1 - Allowed pairs (normative table; examples)
| Tech (authoritative) | Plain (didactic) | Notes and guards |
|---|---|---|
U.System | system, machine, team | Bare “service” is never a safe Plain twin for U.System. Apply L-SERV only when a relied-on use hides the concrete subject or next route, then use A.6.P:4.11a; quoted, historical, illustrative, and harmless ordinary wording stays outside. Avoid “service-instance”; after recovery use “system instance”, “service access point”, “service offering”, or another head phrase supplied by the pattern for the recovered claim. |
U.Episteme | body of knowledge, document, dataset, model | The pair preserves the Carrier and Content distinction (A.7). |
U.Method | how‑to, procedure (abstract) | Do not call this “process” (L‑PROC). |
U.MethodDescription | account of how one identified method is done | recipe, SOP, playbook, code, and spec-text are recognition cues, not automatic twins. Use this pair only after the claim-bearing episteme has one admitted U.Method as its exact EntityOfConcern and passes A.3.2’s substantive-description threshold; call out Spec separately only after the E.10.D2 gate. |
U.Work | work (work kind) | This plain twin names the admitted kind only. A run, execution, activity, job, or case can name one Work individual only after A.15.1 grounds that occurrence; show an explicit occurrence name and the head work occurrence rather than reusing the kind twin. |
one exact local ...SystemRole kind | reviewer (system role), maintainer (system role) | Local kind for entities independently admitted as U.System. On first use, say which systems can count, what work-facing condition separates members from relevant non-members, and what changes preserve that distinction. A practice or source reference may help readers find or compare the definition; it does not identify the kind. The Plain wording creates no system admission or assignment. |
U.PromiseContent | promise, offering, service offering | Never equate to provider system or API (L‑SERV). |
| Holder capability (A.2.2) | ability, capacity (within bounds) | The System’s actual ability under stated work conditions and attained bounds. An account has that holder as its subject and states the ability proposition in its content. The assertion, its support and demand-fit remain separate; no additional capability kind is admitted. |
U.Dynamics | law of change, model of evolution | Not a capability or a method. |
R‑1 (Plain first-use). At first use in a section, show the Tech label and, optionally, the Plain twin after its governing claim condition is established; for a kind label, establish membership first: “…one U.Method (the how-to); and, when a separately identified claim-bearing episteme has that method as its exact EntityOfConcern and passes A.3.2, one U.MethodDescription (an account of that how-to, sometimes called a recipe)…”
R-2 (No unpaired Plain in CC). Conformance Checklists use Tech labels only.
A source or practice may use local aliases in its glossary. Each alias points to one Tech designation under an effective scheme and an explicit local meaning claim. Create a SchemeSenseCell only when a named receiver needs a stable address; use F.9 only when an actual relation between distinct exact cells is current.
Make “plain twins” (reader-friendly labels) safe by construction, not just style. The plain twin preserves the named value, local meaning, scope, and reader expectations of the Tech designation; it is display-only and local to the stated source, practice, scheme, and use.
- Tech name (tech) — the canonical, kernel-conformant label used in normative clauses (for example
U.SystemRoleAssignment,TransformerSystemRole). - Plain twin (plain) — a didactic display alias permitted in expository prose and UI display only for the stated local meaning and use.
Principle: The Tech designation names the value; a Plain twin may not change that value or its stated local meaning. Locality comes from the named source, practice, effective scheme, and use. A Bridge is added only when its own F.9 predicate obtains.