E.10:6.1 - Tech register ontology guards

Purpose. This section stabilises the Tech register of the kernel lexicon by enforcing head-anchored naming, explicit kind naming, EntityOfConcern and Description-episteme boundaries, specification-use morphology, guarded use of bare role, exact SystemRole compounds, and subject-specific recovery of Domain wording. It aligns with E.10.D1, F.4 SystemRoleKindDescription, A.2.5 SystemRoleAssignmentStateRelation, A.2.7 SystemRoleKindRelationStructure, F.11 Distinguish Method, MethodDescription, Work and Outputs, and F.17 UTS. Scope: Guidance is register-agnostic and applies across the FPF; illustrative examples pass Minimal Generality and Domain Anchoring (MG-DA) and the other rules of E.10.

Onto1 — Head‑anchoring (use Kernel heads + pass LEX.TokenClass, EntityOfConcern and Description-episteme boundary, and specification-use gates)

• Rule: The head noun of a term explicitly signals the kind (System, Holon, Work, Episteme, Characteristic, Method, Profile, Description, Spec, TransformationFlowStructure, Card, Pack, Dashboard, …). SystemRole is allowed only as the common compound inside one concrete local system-role-kind designation such as ReviewerSystemRole; bare role remains a recovery trigger rather than a kind head.
• Figurative heads with obvious overload (“Tradition”, “family”, “process”, “function”) are not admitted in the kernel. Plain twins are admitted only with a one-to-one Tech mapping and declared LEX.TokenClass for the Tech token. They appear in the Plain register as one-to-one mappings to a Tech token, not in the Tech register. Plain language minimizes lexical error from overloaded terms through plain-twin lexical guards.
  • Do: IncidentDashboard, MethodSpec, TraditionProfile, TransformationFlowStructureDescription.
  • Don’t: IncidentBoard, TDD Tradition, Production Process (kernel), Service Function (kernel).

Onto2 — EntityOfConcern and Description-episteme boundary and specification-use morphology (ref. E.10.D2)

• Rule: A term for the EntityOfConcern uses the bare head for the FPF kind under concern: Method or Characteristic. A Description episteme appends …Description only under the membership rule of the pattern defining that episteme kind. In particular, a claim-bearing episteme is U.MethodDescription only when its exact EntityOfConcern is one admitted U.Method and it makes at least one substantive claim about that method as a way of doing. Algorithm, code, pseudo-code, recipe, procedure, diagram, or other expression form first remains source wording, a C.29 representation, or a publication expression; none establishes that membership. A qualifying Description episteme appends ...Spec only after a named specification-use gate grants that use. Thus MethodSpec is available only when the same episteme passes both A.3.2 membership and the E.10.D2 specification-use gate; formal language, pseudo-code, or bundled tests alone settle neither condition.
• Formal-description guard: A formal mathematical or physical theorem, including a formal postulate theorem in physics, remains a Description episteme until a bounded use assigns specification use. Its formal language belongs to formality and publication-expression discipline; it becomes a specification only under acceptance criteria, harness checks, normative invariants, measurable anchors, verification use, or another specification-granting condition named by value.
• Extension: Apply the same morphology to non-method EntitiesOfConcern where appropriate: TransformationFlowStructureDescription, TransformationFlowStructureSpec, SystemDescription, and SystemSpec.
• Do: SamplingMethod - SamplingMethodDescription - SamplingMethodSpec.
• Don’t: SamplingAlgorithm (when it is just prose), SamplingProcessSpec (head not signalling kind). Onto3 — System-role kinds, assignments, and carrier-relation separation (ref. E.10.ROLE, A.2, A.2.1, F.4, F.5, C.2.1, C.2.P, E.17, E.24.PUB, A.10, and C.35)
• Positive distinction: A system role is an exact local kind for entities already admitted under A.1 as U.System. C.3 recovers it through the candidate domain, operative work-facing membership condition, intended member/non-member boundary, and continuity rule. A practice or source reference locates the definition or signals a comparison; it does not identify the kind. Its Tech designation ends in ...SystemRole, for example ReviewerSystemRole. The name creates no admission, assignment, agency, capability, or Work.
• Assignment rule: A system-role assignment is an obtaining occurrence of one directly declared species under U.SystemRoleAssignment. The species declaration defines HolderSystemSlot, the exact local system-role-kind domain of AssignedSystemRoleKindSlot, any other participant meanings, its predicate, applicability, and occurrence-identity rule. The occurrence supplies the actual holder System, assigned-kind value, any other participant values, and extent. A source, interpretation, taxonomy, scheme, description, or display is not automatically an assignment participant; name it separately only when the assignment claim actually depends on it.
• Readable example: Under the JournalReview practice, TeamAlpha is classified under ReviewerSystemRole because it can supply the substantive review judgment required by that practice. Add ReviewAssignment-42 only when the assignment itself matters and both its directly declared species and obtaining occurrence are recoverable. If performed Work is current, point first to its independently complete A.15.1 occurrence basis. Add F.6 only for a separately claimed precise assignment-bound attribution. A short attribution sentence may omit only an assignment identifier unused by the receiving claim; it does not omit a performer, Method, time, containing System, assignment occurrence, or F.6 attribution from the recoverable attribution basis.
• Carrier rule: Carrier is not a free holon or system kind. Recover the direct carrier relation: use U.PresentationCarrier only under E.17 and E.24.PUB publication and presentation discipline. If a reusable carrier-relation declaration is separately current, PresentationCarrierSlot remains the declaration-local SlotKind of one A.6.5 SlotSpec and is not the carrier or relation. Other exits are a file, transport, rendering, front-end, or access-carrier relation under E.17; evidence or source-currentness carriage under A.10 or G.11; generated or produced carriage under C.35; or a named episteme-symbol carrier relation independent of any system-role assignment.
• Source-word rule: Job titles such as reviewer, owner, and lead remain Plain or quoted wording until the current claim is recovered. Use E.10.ROLE for an ambiguous claim-bearing role. Use ...SystemRole only for an exact local system-role kind, and preserve owner when an actual architectural, organizational, policy, source, or responsibility ownership relation is what the sentence states.
• Do: ReviewerSystemRole; ReviewAssignment-42 : U.SystemRoleAssignment; LeanTraditionCarrier only when its direct episteme-symbol carrier relation is declared.
• Don’t: Reviewer as a U-kind, ReviewerCarrier for an assigned system, an unqualified ...Role Tech head, or Carrier as an unstated system kind. Onto4 — Recover what domain means in this use (ref. E.10.D1 and F.17)
• Rule: The word domain does not create a kernel kind, catalogue mark, family, bundle, or inheritance relation by spelling. Recover what domain names in the current claim—for example, a DPF subject, discipline, source-defined field, model domain, market, physical region, or policy extent—or keep it as ordinary prose when it carries no FPF-governed use.
• Local-meaning rule. When a durable domain expression carries source-local meaning, identify its exact source edition, effective ReferenceScheme, local expression, local-sense claim, and any obtaining basis relation. Create an F.17 SchemeSenseCell only when a named receiver needs a stable address. Use F.9 only for an independently obtaining Bridge between distinct exact cells; state any proposed use separately.
• Discipline boundary. Use U.Discipline only when the claim satisfies the pattern that defines that kind. A domain label, shared vocabulary, or UTS row does not establish discipline identity.
• DPF boundary. A DPF states its domain subject, intended audience and use, source basis, scope, and qualification window under E.4.DPF; it need not invent DomainFamily, DomainBundle, or a list of Context identifiers.
• Do: “The Clinical Safety DPF addresses adverse-event analysis and device-labelling decisions for the stated audience and scope.”
• Don’t: infer ClinicalSafetyDomain, DomainFamily, or DomainBundle as a kind from that wording.

Onto5 — Always state what the term names

• Rule. The definition or first line of a gloss states the FPF kind or object named by the term—for example, a U.Holon, U.System, U.Episteme, Profile, exact local system-role kind, U.Work as the admitted kind or a Work occurrence admitted under it, Characteristic, or direct carrier relation.
• Do: “Kind named: ReviewerSystemRole — the exact local kind whose admitted-system candidates satisfy the current substantive-review condition. Its member/non-member boundary and continuity rule are recoverable under C.3; the named review practice locates that definition. A concrete assignment names its directly declared species and one separately obtaining occurrence under U.SystemRoleAssignment.”
• Don’t: “Reviewer — a person who …” (blurs the kind named).

Onto6 — Bans and ontology recovery hints (mirror E.10 § 9 L-rules; do not duplicate tables; not a substitution table)

• process, procedure, workflow, function, or activity -> first recover the wording family: change-situation wording applies A.3.4.P; function-like wording applies A.6.F. Possible recovered values include U.Method, U.MethodDescription, U.WorkPlan, one dated Work occurrence admitted under U.Work, a separate episteme about it, U.Transformation, and TransformationFlowStructure. Choose among them only after naming the object, any obtaining method-side or other relation and its participants, the relevant declaration or representation use, or the claim kind and the pattern that defines it.
• tradition or lineage -> recover the exact historical-continuation, source-use, method, edition, derivation or provenance claim under its subject pattern. Under C.20 these may remain ordinary auxiliary values or C.3 project-local kinds; the label alone admits no public U-kind or Tech designation.
• domain -> apply Onto4: name the actual domain subject, source or practice boundary, effective scheme, discipline claim, DPF scope, or ordinary use that matters here. Do not infer DomainFamily, DomainBundle, ContextId, or a UTS row from the word.
• …CarrierRole used for an assigned System -> start with E.10.ROLE; recover the holder System, local ...SystemRole kind, A.2.1 assignment occurrence, and its declared species only when the passage asserts those facts. Recover carrier, source relation or source-local meaning, interpretation, publication, evidence-use, and Work claims through their own relations.
• ambiguous owner wording -> recover the precise relation or other claim being made—for example, an architectural, organizational, policy, source-maintenance, responsibility, authority, commitment, or work-facing claim. Keep owner when that precise ownership relation is current; use a ...SystemRole designation only when the recovered object is an exact local system-role kind.
• job titles (owner, lead, champion) in the Kernel -> keep them in Plain or quoted wording until the claim is recovered; use exact ...SystemRole designations only for admitted local system-role kinds.
• Do: ReturnsTransformationFlowStructureDescription; LedgerTeam is classified under LedgerCustodianSystemRole, with any exact assignment, responsibility, authority, source-maintenance, or interpretation relation stated separately when current.
• Don’t: Returns Process, TDD Tradition (kernel), Ledger Owner (underspecified).

Worked mini-examples across arenas. These names illustrate morphology only. Every ...MethodDescription presupposes one claim-bearing episteme whose exact EntityOfConcern is one independently admitted U.Method and whose claims pass A.3.2; every ...Spec also presupposes its subject-specific specification-use gate. The label establishes neither condition.

The Onto3 block above is the one bounded distinction and assignment example. The twelve rows below are morphology cues, not classification or assignment assertions. Read each candidate System label and candidate local system-role-kind label separately. Before asserting classification, pass C.3 and A.2; before saying an assignment obtains, admit the holder System and establish both the A.2.1 occurrence and its declared species. A schedule, place, office, desk, title, source or practice cue, taxonomy, scheme, or interpretation episteme supplies none of those facts by wording.

Checklist before minting a KernelToken

• Head noun signals kind (Onto1).
• EntityOfConcern and Description-episteme boundary and specification-use morphology correct (Onto2).
• If system-role-related or carrier-related: local system-role kind, direct assignment species, and carrier relation remain separate; holder-system admission is explicit and the direct carrier-relation pattern is named (Onto3).
• Any action-changing Domain wording recovers its subject, use, and applicable pattern; a durable local expression uses F.17 only when its source-local meaning or public term row is current (Onto4, Onto6).
• Object‑of‑talk declared (Onto5).
• SCR-LEX rewrites checked for current system-role-kind, direct assignment-species, and carrier-relation separation (Onto6).

Note on registers. A technical designation first names a value admitted under its own subject pattern. A Plain twin then names that same value under §6.2. Tradition or lineage wording follows C.20’s exact-subject and relation recovery; the words alone identify neither an episteme about epistemes nor a public kind.

• Onto‑Deon — Deontic lexicon guard (Core register) Rule. In the Conceptual Core, avoid using “Standard” as the head noun of an EntityOfConcern name unless the object is an explicit deontic speech-act under the Gov lens (cf. E.3).

For interface and boundary invariants concerning things such as holons, interfaces, and ports, name the exact invariant, compatibility condition, compliance profile, acceptance specification, or interoperability profile by value—for example InterfaceCompatibilityCondition, ComplianceProfile, AcceptanceSpec, or InteropProfile. State any promise or commitment separately; naming does not make it a property of the thing.

Use the word standard for a publication of a Description episteme, possibly admitted for specification use, that is intended to be complied with and has explicit compliance checks.

If an EntityOfConcern-side item is currently named … Standard, rename it to a proper EntityOfConcern-side name, and (optionally) add a separate publication of the relevant Description episteme under the needed compliance or specification use that contains the standard text and the intended compliance checks. Rewrite hints (Tech → Tech). publication Standard → publication standard; frame Standard → frame standard; measurement Standard → measurement standard; Method Interface Standard (MIC) → Method Interface Standard (MIS); Boundary-Inheritance Standard (BIC) → Boundary-Inheritance Standard (BIS). Rationale. Keeps Core prose centred on EntitiesOfConcern and their boundary invariants; reserves deontic obligations for governance contexts and U.PromiseContent‑like promises. Do not misuse “plane”: deontic speech‑acts are analysed via the Gov lens, while ReferencePlane remains {world | concept | episteme}.