E.10:6.2 - Twin‑Register Discipline (Tech and Plain)
Plain twin (LEX). A registry entry pairing the authoritative Tech designation with a display-only Plain designation for one named value under one stated local meaning and effective ReferenceScheme: an admitted durable U-kind, C.3 U.Kind, Concept-Set row, imported signature symbol, or another value whose kind and definition are already known. The LEX registry checks the pairing under PTG (Plain Twin Governance) and identifies it by Twin-Map ID (LEX). Create an F.17 SchemeSenseCell only when stable reuse or another named receiver needs an exact address. “Plain twin” ≠ the Plain register (the register is where twins may be used; the twin is the 1:1 mapping).
Convention. In this spec, Plain (capitalized) names the register; plain twin (lowercase) names the 1:1 mapping entry.
Rule R-0 (Registers). Every Kernel and extension-pattern concept has a Tech designation used in testable semantic clauses and may have one Plain designation for a stated didactic use. The Plain designation is admitted only when it names the same value under the stated local meaning and effective scheme; it does not create another value, cell, kind, or relation.
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.
E.10:6.2.2 - Plain Twin Safety constraints (normative)
CC‑TWIN‑1 - One‑to‑one and local. Each Tech designation has at most one plain twin for one stated local meaning and didactic use; that plain twin points to at most one Tech designation in the same use.
CC‑TWIN‑2 - Sense‑equivalence proof.
A plain twin names the same value under the same local meaning claim and effective scheme as its Tech designation. When an F.17 SchemeSenseCell exists for that use, both expressions resolve to that exact cell. The registry notes include at least one counterexample showing how the twin could be misread and why the stated use still passes.
CC‑TWIN‑3 - Head‑term discipline (HND). The plain twin preserves the head term of the Tech name or appends an explicit bracketed head on first use:
- A Plain twin for one exact local system-role kind keeps “(system role)” and names its Tech designation on first use. Bare role is not a Plain twin for a universal kind. When service or access still hides its object or relation, follow L-SERV and A.6.P:4.11a; after recovery, keep that object’s or relation’s head. Methods keep “(method)”,
U.Workas a kind keeps “(work kind)”, one Work individual keeps “(work occurrence)”, a separate episteme about it keeps “(work record)” only when its Tech name denotes that record, and Capability keeps “(capability)”. Examples:TransformerSystemRole→ “Transformer (system role)”,U.PromiseContent→ “post-op monitoring service promise (promise content)”; an exact access relation → “service access (access relation)”,U.Work-> work (work kind);PumpInspection_2026-07-22T0900-> inspection work occurrence;PumpInspectionRecord_2026-07-22-> inspection work record only when that Tech name denotes a separate episteme.
CC‑TWIN‑4 - Kind‑consistent. A plain twin does not map across Kinds (C.3). If its everyday interpretation can denote a different kind—for example, Tradition as organization, corpus, or field—it is admitted only with a bracketed head and a first-use local gloss (see CC-TWIN-7).
CC‑TWIN‑5 - Ambiguity stop‑list. The following base nouns are reserved and are not admitted as unqualified plain twins: Tradition, service, process, function, model, system, method, standard, library, dataset, evidence, activity, task, action. They are allowed only with an explicit head per CC‑TWIN‑3 and a first-use local gloss (CC-TWIN-7). (This list may be extended in the registry.)
CC‑TWIN‑6 - No cross-local relation by label. Plain twins are not portable by spelling. Reuse under another local meaning first recovers that exact value, scheme, expression, and local-sense claim. Cite an F.9 Bridge only when its direct relation between distinct exact cells actually obtains; names alone carry no authority, equivalence, or substitution.
CC‑TWIN‑7 - First‑use gloss.
At first occurrence in a document or screen, show a plain twin as “Plain twin [Tech designation] — local gloss”, for example:
“Transformer (system role) [TransformerSystemRole] — one local kind for systems already admitted under A.1 and eligible for the stated transformer assignments in OR_2025; classification creates neither an assignment nor Work. An assignment claim names both an A.2.1 occurrence and its declared U.SystemRoleAssignment species”.
CC-TWIN-8 - Normative and didactic placement. Use Tech names in Conformance Checklists, predicates, type signatures, and acceptance clauses. Reserve Plain twins for didactic use.
CC‑TWIN‑9 - Twin budget. At most one plain twin per Tech designation for one stated local meaning and didactic use. Synonym piles are non-conformant because they create uncontrolled vocabulary sprawl (see F.14).
CC‑TWIN‑10 - Registry entry and DRR.
Every admitted plain twin has a registry entry recording tech, plain, referenceScheme, localSenseClaim, sourceOrPracticeBoundary, didacticUse, head, SenseFidelity = {3,2,1,0}, ambiguity notes, counterexamples, and DRR id. A change opens a DRR.
CC‑TWIN‑11 - Tests.
Twin entries pass the Twin Harness (see F.15): Head term, Kind consistency, same value and local meaning, Stop-list compliance, and First-use gloss. When a SchemeSenseCell is current, the harness also checks the exact cell.