#U.Ontic and Ontic Introduction Discipline

E.24 · Stable · Part E FPF authoring discipline pattern · Normative unless a section is explicitly informative · Part E - The FPF Constitution and Authoring Guides

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Part E FPF authoring discipline pattern Status: Stable Normativity: Normative unless a section is explicitly informative

Use this pattern when FPF work appears to need a durable ontic: a connected ontology-architecture unit whose meaning is spread across several typed values, slots, relation positions, pattern nests, and nearby governing patterns.

#Relations

#Content

#Use This When

Use this pattern when FPF work appears to need a durable ontic: a connected ontology-architecture unit whose meaning is spread across several typed values, slots, relation positions, pattern nests, and nearby governing patterns.

Typical moments:

• a repeated local use frame starts behaving like a hidden object;
• a source label or project-side expression keeps pointing to several FPF values at once;
• a draft ToC locus names a calculus or object family, but no current pattern carries its governing meaning;
• a subject pattern begins to carry local slot-relation doctrine that other patterns also need;
• a proposed term would sit across one semanticArea, one ontologicalNeighborhood, and several dependent patterns.

Primary EntityOfConcern. The EntityOfConcern is U.Ontic as a durable action-facing ontology unit, together with the current ontic-introduction decision about whether a candidate becomes a durable ontic, remains a local use frame, is handled by direct governing patterns, or stays quote-only or reduced-use source wording.

Primary working reader. The first reader is an FPF pattern author or reviewer deciding whether several nearby patterns are describing one ontic, several existing governed values, or only a compressed source label. The downstream reader is the practitioner who needs the resulting subject pattern to say what can be done, claimed, relied on, repaired, compared, or stopped.

First useful move. Decide whether the construct is a durable ontic, a direct use of existing governing patterns, a local use frame for one bounded application family, or a source label that must remain quote-only or reduced-use.

What goes wrong if missed. FPF grows shadow ontology. The same project concern becomes a method in one place, a mechanism in another, a record in a third, and a local checklist in a fourth. Later uses then repair visible symptoms instead of settling the underlying kind, slot, and governing-pattern question.

What this buys. A durable ontic gets an explicit slot relation like U.EpistemeSlotRelation, or the construct is explicitly kept as a local use frame with pointers to the typed values and governing patterns that already carry the work.

Main gains:

• it prevents duplicate ontology: one project concern is recovered into typed FPF values and slots instead of becoming a different local object in each nearby pattern;
• it replaces long negative catalogues with positive slot discipline: name the ontic, its slots, and the governing patterns for fillers instead of repeating "not proof, not gate, not work..." across dependent patterns;
• it gives dependent patterns a stable head to rely on without copying the whole slot relation;
• it separates durable ontic introduction from thin relation updates, local use frames, direct governing-pattern use, and quote-only source labels;
• it makes wording follow ontology: after the slot relation and fillers are recovered, local words such as method, mechanism, process, morphism, construction, transformation, work, or change can name the slot or filler they actually refer to.

Not this pattern when.

• If one existing governing pattern already carries the claim, use that pattern directly.
• If the issue is only one wording-use repair row, use E.10 and E.10.ARCH.
• If the issue is only a new or revised mechanism meaning, use E.20.
• If the issue is only durable naming, use F.18.
• If the issue is only a pattern publication-form or section-order matter, use E.8.

#Problem Frame

Some FPF governed objects are small enough to define with one relation or one record. Others require a durable ontic. U.Episteme is the central example: it needs identity criteria, typed slots, slot-filling discipline, filled assignments, card and publication species, description boundary, publication-form boundary, relation to U.Signature, and dependent episteme-morphism and publication patterns. C.2.1 works because it makes the small ontic slot relation explicit.

The same failure recurs elsewhere. A project label such as "algorithm", "process", "model", "architecture", "service", "quality", "time", "rhythm", "change", or "source" can point to several typed FPF values. If FPF answers only by choosing a better word, the old compression returns. If FPF creates a new U.* kind too early, the new kind becomes a duplicate ontology over values that already have governing patterns.

E.24 governs that ontic-introduction decision.

#Problem

Without this discipline:

1. Local use frames become pseudo-kinds. A repeated local table or record starts to look like a new FPF object even though its rows are only links to existing values.
2. Draft-only loci become false authorities. A ToC row such as C.4 Method-CAL is cited as if it already supplied current governing text.
3. Pattern nests are mistaken for semantic units. The placement label becomes the ontic, while semanticArea and ontologicalNeighborhood stay unstated.
4. Slot relations are copied without identity. Several patterns list similar slots but no pattern says what identifies the ontic, which slots are required, and which dependent patterns may rely on them.
5. Existing typed values are duplicated. A new head repeats U.Method, U.Mechanism, U.WorkPlan, U.Work, evidence, gate, source, or result relations under a new name.

#Forces

#Solution

This pattern selects U.Ontic as the FPF kind for an ontic. U.Ontic is the EntityOfConcern of E.24: a connected ontology fragment whose stable identity, slots, admissible slot values, neighboring ontology units, dependent pattern obligations, and non-use boundary must be held together before FPF can use that fragment safely in action-facing patterns.

Keep three objects distinct:

• the U.Ontic being introduced or rejected;
• the OnticIntroductionCandidate, which is a pattern-set architecture problem: duplicated slots, hidden slot boundaries, hidden relation boundaries, weak identity, scattered invariants, high coupling, low cohesion, or dependent patterns copying the same local ontology;
• the publication that describes the selected ontic, usually one head pattern plus dependent patterns.

The introduction decision is not the publication form. A pattern section, table, source row, or relation list may describe the ontic after the decision, but it is not evidence by itself that the pattern set needs a durable ontic.

Start from the ontic, not from its description or publication. An ontic may then have:

• a description episteme that describes the ontic and its slot relation;
• a publication of that description episteme, often as a head pattern plus dependent patterns;
• publication forms, views, examples, and source rows that help users apply it.

Those are downstream of the EoC distinction. A pattern file, section, table, card, packet, review note, or publication form is not the ontic. It may describe or publish the ontic after the ontic has been selected as the object under concern.

A U.Ontic names the connected set of:

• the semanticArea being settled: the meaning area that lets users recognize the family of claims or uses under concern;
• the onticSlotRelation: the small typed slot relation that gives the ontic its identity, required and optional slots, value kinds, reference kinds, relation set, species or record forms, non-slot components, description boundary, and publication boundary;
• the ontologicalNeighborhood: the current FPF patterns that carry claims about the ontic, its slots, its values, its neighboring EntityOfConcern uses, and its admissible neighboring uses and boundaries;
• the governing head pattern or accepted local frame that describes the ontic when current FPF use needs a citeable description;
• the dependent-pattern obligations that rely on that settlement without copying the whole slot relation.

FPF ontology is therefore not treated here as one flat class list. It is a connected set of ontics. That prevents ontology explosion: FPF can keep a small number of durable ontology units while allowing many project EntityOfConcern values, source labels, project-side identifiers, role assignments, records, methods, mechanisms, work plans, descriptions, publications, and other values to appear as slot fillers inside several ontics. A value filling a slot in one ontic does not thereby become a different entity, a different U.* kind, or a second ontology.

The U.Ontic decision is selected because the repeated semantic-area, ontic-slot-relation, ontological-neighborhood, and dependent-pattern set is now itself a governed object in FPF. Without a named kind, the same architecture unit would be re-described as a semantic area, pattern nest, ontology family, local frame, slot relation, or description and publication arrangement in different places, recreating the duplicate-ontology problem E.24 is meant to prevent. With U.Ontic, DRRs and patterns can cite one kind for the ontology-architecture unit while still keeping each filled value under its own governing pattern.

The cost is kernel growth and metamodel risk. E.24 contains that cost by making U.Ontic narrow. A local use frame, source label, project-side expression, recurring table, pattern nest, or draft ToC row is not a U.Ontic merely because it looks ontology-shaped. It becomes a U.Ontic only when the E.24 decision names stable identity, an ontic slot relation, selected semantic area, selected ontological neighborhood, dependent pattern obligations, existing-pattern reuse, and non-use boundary by value.

Do not count ontics and U-kinds as if they had to be one-to-one. The relation is a governance relation. Every durable U.* name needs one primary E.24-compatible ontic settlement. Every durable ontic settlement needs a named root subject U-kind or an explicit reuse of an existing root subject U-kind; otherwise the candidate remains a local use frame, selected relation structure, expression, record, lens, publication form, or source wording. One settlement may govern a small family of U-kinds when the slot relation is what keeps them together. In that case the head pattern states which U-kind is root for the subject and which U-kinds are dependent durable values inside the same settlement. U.Ontic is the kind of the ontology unit itself; it is not a substitute for naming the subject U-kind governed by that unit.

Slot discipline is the governing protection. A relation-position or use-relation label says which position in a relation or current use relation is being filled. It does not create a new entity kind, and it also does not erase an already governed entity kind. A value can fill a slot in an ontic slot relation or a position in another governed relation while remaining governed by its own pattern.

Use this distinction:

• If the name only identifies a position in the current slot relation, keep it as a SlotKind, relation label, or local field.
• If the name has independent EntityOfConcern identity, stable identity criteria, a governing pattern, admissible use boundaries, and dependent-pattern reliance, it may remain or become a U.* kind after an E.24 decision.
• If both are true, keep both levels explicit: the slot belongs to the ontic slot relation; the filler keeps its governing kind. A methodSlot can be filled by a U.Method; a workOccurrenceSlot can be filled by U.Work; an EntityOfConcernSlot can be filled by a U.Entity. The slot name does not make the filler a different entity, and the filler kind does not make the whole slot relation one super-kind.

Role participation is the main stress test for this distinction. Do not write that U.Role is a slot, that a slot is a role, or that U.Role is a special case or subtype of SlotKind. U.Role remains a work-facing, context-bound role value under the role-governing patterns. A schema, card, or publication that describes a role is a description or publication of that role value; it is not the role itself.

U.RoleAssignment is a typed assignment relation value, and it is slot-disciplined without becoming a second role ontology. Its core SlotSpecs are work-facing: RoleHolderSlot is filled by a U.System or an acting holon admitted by the governing work or method pattern as a system-like performer; RoleValueSlot is filled by U.Role; BoundedContextSlot is filled by U.BoundedContext; and AssignmentWindowSlot is filled by the temporal-window value current for the assignment claim. Direct work-role patterns may add direct work-role qualifier slots. The filled holder, role, context, and window keep their own governing kinds.

Method, method description, work plan, dated work, evidence-use relation, status-use relation, source-use relation, assurance-use relation, and publication-use relation are neighboring values through their direct patterns. They are not RoleAssignment core slots merely because a local source sentence says "role of the method", "role of the evidence", "standard role", or "status role". An episteme used as evidence, source, standard, requirement, definition, explanation, status bearer, or assurance input is governed by the evidence-use, source-use, publication-use, status-use, or assurance pattern that carries the current claim.

Role participation therefore uses slot discipline without demoting U.Role to a local field and without turning every relation participant into a role. A system acting as an engineer is still the same U.System filling the holder slot in U.RoleAssignment(holderRef=SystemRef, roleRef=EngineerRole@EngineeringContext, boundedContextRef=EngineeringContext, windowRef=WindowRef); the role name does not create a new system kind. A performed U.Work points to that assignment through performedBy -> U.RoleAssignment; method, method-description, work-plan, and dated-work relations remain under A.15 and its neighboring method and work patterns. If a source word such as "engineer", "reviewer", or "operator" is under repair, recover the holder, U.Role, bounded context, assignment relation, temporal window, work, method, method-description, and capability values through A.2, A.2.1, A.2.2, and A.15 rather than minting a participation type.

Specialized participation words still require care. A role-like, method-like, mechanism-like, source-like, temporal, or publication-like word may name either a slot position or a governed filler. E.24 does not settle every subject ontology by itself. It requires the author to keep the slot position and the filled value distinct, then use the governing pattern for the filled value or run a separate E.24 decision when the participation family itself appears to need a durable ontic. Ordinary phrases such as "the television plays the role of transformed object" are not enough to create U.Role: the television fills a transformed-entity or transformed-structure slot in the U.Transformation core; it does not thereby receive a U.Role value or U.RoleAssignment.

When an existing U.* name appears to be only a slot-position label, run the same check explicitly. Retain the U.* name only if its pattern gives a standalone EntityOfConcern, identity criterion, and action-facing gain that cannot be reduced to "value filling this slot." Otherwise demote the use to a slot or relation label and do not keep the U-kind by inertia.

Use the same parsimony test for relation-shaped candidates. A selected relation structure can be a real FPF object without being a U.* kind. Retain or introduce a U.* name only when stable identity, dependent-pattern reliance, and action-facing gain require more than slot and relation combinatorics over existing governed values. If the candidate is adequately carried by existing U.* values, SlotSpecs, relation positions, expressions, facts, records, or mathematical or representation lenses, keep it as a non-U selected structure or local frame and name the governing values explicitly. Context-locality alone does not decide the question: a context-local role or method can still be a durable governed value, while a context-local role-state relation or method-relation structure may remain a non-U selected relation structure.

Use slot-language for ontic slots. The ordinary E.24 names are onticSlotRelation, SlotSpec, SlotKind, ValueKind, RefKind, slot discipline, slot boundary, and relation boundary. Use interface only when the object under concern is actually a boundary, module interface, signature interface, mechanism interface, or architecture interface under its governing pattern. A slot relation does not become an interface because the author wants a shorter or more familiar word.

Use naming patterns for durable names, not for slot relations. F.18 governs name repair when an E.24 decision mints or changes a durable U.* name, reusable SlotKind head, species or record-form name, public id, Core-facing head, or cross-context label. F.17 UTS and Name Card material publish or update that durable name when it becomes public, Core-facing, or cross-context. UTS is not the ontic slot relation: A.6.5 SlotSpec discipline remains the slot discipline for the ontic itself. Do not require UTS for one local use frame or one filled core unless its name becomes reusable beyond that use.

Keep ontic levels separate before dependent patterns rely on the ontic.

An ontic is selected when FPF needs one governed SlotRelation: a typed n-ary relation with SlotSpec discipline that keeps several different typed objects together without fusing them into one umbrella kind. The ontic is the relation architecture: it says which SlotKinds exist, what ValueKinds and RefKinds can fill them, which governing pattern owns each filler, and what claims become admissible or blocked when a filler changes. A filled use is a value assignment over that relation. Under C.29, that filled assignment may be viewed as a tuple for tuple reasoning, or drawn as a graph or hypergraph for dependency reasoning, but tuple, graph, and hypergraph are mathematical-lens views, not alternate ontology heads.

Use the lens that preserves the current question. A tuple view is useful when the question is "which slots and values are present in this assignment?" A graph or hypergraph view is useful when the question is "which values depend on, constrain, or reopen which other values?" Neither view proves that the filled values form one new kind; both must return to the same SlotRelation, SlotSpecs, and governing patterns for fillers.

When several partial ontologies already exist for the same project concern, E.24 does not pick one and delete the others. It selects the head ontic or local frame that can relate them without fusing their kinds: the existing objects become slot fillers, relation positions, graph-valued expressions, descriptions, publications, or neighboring governed values. This prevents duplicate ontology: a U.Method, U.Work, U.Mechanism, a source-local graph-position claim or current TransformationFlowStructure expression, role assignment, and publication can participate in one typed relation without becoming the same kind.

1. Ontic root and identity. Name the durable ontic or accepted local frame under concern and its stable identity criterion.
2. Type-level onticSlotRelation. State the SlotKinds, ValueKinds, RefKinds, relation set, required slots, optional-in-use slots, participation slots and check slots, species or record forms when needed, non-slot components, description boundary, and publication boundary. This is the reusable schema, not one filled use.
3. Filled value assignment or ordinary-use core. Give a compact filled instance or first-use frame only when users need one concrete application shape. It fills the type-level slots; it is not a second ontology and not a competing slot relation. Under C.29, that filled assignment may be viewed as a tuple when tuple reasoning is current.
4. Description episteme and publication. Claims about the ontic, its slots, its slot fillers, or relations among those values use C.2.1; a pattern section, table, diagram, publication, card, or view may describe the ontic, but it is not the ontic.
5. Participation slots, check slots, and relation references. Method, mechanism, work, evidence, source, gate, result, temporal adequacy, math lens, publication, and other typed values may be fixed slot positions in an ontic when claims about the ontic change admissible use, evidence relation, identity, responsibility, enactment, observation, modeling, permission, acceptance, refresh, or dependent-pattern obligations when those fillers change. They are not identity slots unless the ontic identity criterion explicitly depends on them.

Use these criteria when deciding whether a possible slot belongs to the ontic slot relation:

1. Claim-impact. A claim about the ontic becomes stronger, weaker, blocked, differently evidenced, or differently usable when the slot filler changes.
2. Stable participation relation. The filler specifies, constrains, enables, enacts, observes, models, times, evidences, publishes, authorizes, accepts, refreshes, or otherwise participates in the ontic through a stable relation.
3. Duplicate-ontology resistance. Leaving the slot outside would make dependent patterns copy negative catalogues, local tables, or shadow kinds.
4. Kind preservation. Including the slot lets the filler keep its governing pattern instead of fusing several kinds into one umbrella value.
5. First-use cost. Including the slot gives a bounded disposition check; it does not force a full neighboring-pattern application unless the current claim depends on that value.

The ? marker or optional-in-use status does not mean "weakly belongs to the ontic." It means that every use considers the slot and records a disposition, while only some uses recover or assert a filler. Under open-world discipline, an unfilled slot means unknown, not recovered, not asserted, or not current for this claim; it does not assert that no such value exists.

Not every ontic needs every named layer. Add a named signature or kind level only when dependent patterns must rely on slot constraints across species or morphisms. Add a named filled-value assignment only when patterns need a publication-form-agnostic filled value; use C.29 tuple-view language only when tuple reasoning is current. Add named card, view, or publication species only when holonic working forms, views, or publication forms are themselves governed by the ontic. Name attached or non-slot components only when common adjacent structures must stay recoverable while remaining outside the ontic identity.

Keep annotation proportional. E.24 requires source-ontology recovery only for wording that can change the ontic, slot, filled value, governing pattern, admissible use, or dependent-pattern obligation. If a domain sentence already preserves those values, do not replace it with a typed paraphrase merely to show that an ontic exists.

This differs from pure ontology engineering because FPF patterns are action-facing: they help an engineer-manager decide what can be done, claimed, relied on, repaired, compared, or stopped in a problem situation. Ontic settlement supplies the object discipline that makes those actions intelligible. It says which objects and relations the pattern acts with, while the subject pattern still carries the practical move, boundary, evidence, and consequence.

Precision restoration uses the same discipline without turning it into lexical style. First recover the ad hoc ontic implied by the source situation: which meaning area, candidate object of concern, slots, neighboring patterns, and typed values are being compressed by the wording or source-side situation. Then repair toward the normative FPF ontic and linked typed values when such an ontic exists. If no normative ontic exists, use the direct governing patterns, keep the frame local, or open an E.24 ontic-introduction decision.

E.24 is the governing description pattern for U.Ontic. In that sense it is the ontic-of-ontics pattern: it describes the U.Ontic EoC, its slot relation, and its decision discipline. That self-application is allowed only under the same checks it imposes on other ontics; it is not a license for every local ontology-shaped bundle to become a U.* kind.

E.24 is compatible with modular ontology and ontology-design-pattern practice: modular ontology libraries and ontology design patterns show why reusable small ontology structures matter, and recent process-modeling work shows that implicit process patterns must be made explicit for reuse. E.24 is narrower and more FPF-specific: it selects when FPF should introduce a durable action-facing ontic, rather than importing an external microtheory or treating every reusable repair table as ontology.

If the choice between "write an ontic" and "keep the existing pattern constellation" needs reusable scoring, build a separate evaluation CharacteristicSpace through A.19.ECS. The evaluated object is then the FPF pattern-set architecture alternative, not the ontic itself: current constellation, local frame, or durable ontic. Candidate architecture characteristics include cross-pattern coupling, subject cohesion, explicit onticSlotRelation and SlotSpec discipline, invariant recoverability, duplicate-ontology resistance, dependent-pattern thinness, change-impact locality, first-use cost, and FPF ecology fit. E.24 uses these as diagnostic pressure for the introduction decision; it does not itself become the full architecture-characteristic evaluation pattern.

Do not grow E.24 by adding full publication-section rules, adequacy scales, wording-use restoration rules, or a general architecture-characteristic theory. E.24 keeps only the object split and the ontic-introduction decision needed before dependent patterns rely on a durable ontic.

Use the current split this way:

• use E.24 for U.Ontic identity, type-level onticSlotRelation, semantic area, ontological neighborhood, dependent-pattern obligations, and non-use boundary;
• use E.24.CD when the current problem is detection of an ontic candidate, hidden-form classification, or sufficiency rationale for deciding whether a recurring construct is a durable ontic, a local use frame, direct governing-pattern use, or source wording only;
• use E.24.PUB when the current problem is the distinction among the ontic, the ontic-description episteme, the publication of that description, and publication forms such as cards, records, tables, schemas, diagrams, views, or source packets;
• use A.19.ECS only when the contested question is how to construct an evaluation CharacteristicSpace for comparing pattern-set architecture alternatives, such as current constellation, local frame, or durable ontic.

This split keeps E.24 ontic-first. Candidate detection, publication discipline, and contested evaluation remain neighboring governed objects rather than sections that make E.24 a general discovery, documentation, or scoring pattern.

Introduce or rely on a durable FPF ontic only after the ontic-introduction decision satisfies four checks.

#Check 1: Existing Governing Pattern Check

Name the current claim under decision and ask whether an existing pattern already carries it.

Use direct governing patterns first. If the case is method semantics, use A.3.1; if it is method description, use A.3.2; if it is mechanism meaning, use A.6.1 and E.20; if it is work planning or dated work, use A.15.2 or A.15.1; if it is evidence, gate, source, assurance, decision, release, or publication use, use that governing pattern.

Do not introduce a durable ontic only because several patterns are near each other or because one source word appears often.

#Check 2: Stable Identity Test

A durable ontic must have stable identity beyond one repair pass.

Ask:

1. What is the primary EntityOfConcern?
2. What changes the identity of this ontic?
3. What does not change identity, even if the publication form, notation, view, or local record changes?
4. Which bounded context is required for identity?
5. Which dependent patterns may rely on that identity?

If those questions cannot be answered, keep the construct as a local use frame or direct governing-pattern use.

#Check 3: Typed Slot Relation Test

A durable ontic must publish a small typed slot relation.

The ontic-introduction decision states:

One-screen first-use card:

OnticIntroductionDecisionCard:
  concern: a recurring FPF subject looks spread across several typed values or patterns.
  decision: durable ontic | local use frame | direct governing-pattern use | source label only.
  onticRootIfSelected: the EntityOfConcern and stable identity criterion.
  typeLevelSlotRelation: required slots, optional-in-use slots, ValueKinds, RefKinds, and governing patterns for fillers.
  filledAssignmentExample: one concrete assignment over the slot relation, not a second ontology.
  publicationBoundary: pattern text, table, card, or diagram may describe the ontic; it is not the ontic.
  blockedLocalOverread: one tempting shadow kind, duplicate ontology, or publication-as-object error.

Filled replay slice:

OnticIntroductionDecisionCard:
  concern: bounded change talk compresses method, work, mechanism, timing, evidence, result, and flow-structure claims.
  decision: durable ontic selected.
  onticRootIfSelected: `U.Transformation`, identified by transformed entity or structure, bounded context, pre-state and post-state or delta, transformation relation, and boundary condition.
  typeLevelSlotRelation: `TransformationCore` plus linked participation slots for method, method description, mechanism, work plan, work occurrence, evidence relation, result relation, temporal aspect, and flow-structure relation; fillers keep their own governing patterns.
  filledAssignmentExample: pump-station backup architecture change, with `A.3.4` transformation core, `A.15` method and work chain, `C.27.TA` two-release-cycle recovery timing, and evidence references plus result references only where those claims are being made.
  publicationBoundary: `A.3.4` describes the ontic and its slot relation; a table, card, diagram, or transformation-flow view may publish that description but is not the transformation.
  blockedLocalOverread: one "transformation" label does not make method, mechanism, work plan, performed work, evidence, and result the same typed value.

The full replay form is heavier:

For ordinary first use, stop at the one-screen card unless dependent patterns will rely on the proposed ontic, the current claim changes admissible use, or a reviewer needs replayable evidence for why a local frame was not enough.

OnticIntroductionDecision:
  ProposedOnticName:
  ProposedConceptHead:
  OnticAsEntityOfConcern:
  BoundedContext:
  StableIdentityCriterion:
  UKindDecision:
    verdict: selected U-kind, no U-kind, or blocked
    selectedUKindName:
    gain:
    cost:
    duplicateOntologyRisk:
    repairObligation:
  SemanticAreaBaseConcept:
  SemanticArea:
  SemanticAreaSenseFamily:
  OnticSlotRelation:
    RequiredSlotKinds:
    OptionalSlotKinds:
    ValueKinds:
    RefKinds:
    RelationSet:
    SpeciesOrRecordForms:
    NonSlotComponents:
    DescriptionEpistemeBoundary:
    PublicationBoundary:
  OntologicalNeighborhood:
    HeadPattern:
    DependentPatterns:
    NeighboringGoverningPatterns:
    DirectUsePatternsBeforeNewConcept:
  ExistingGoverningPatternsReused:
  DependentPatternObligations:
  SlotPositionLabelsThatAreNotNewKinds:
  NonUseBoundary:

For E.24 itself, this record is already decided: ProposedOnticName = Ontic, OnticAsEntityOfConcern = connected ontology fragment under FPF settlement, and UKindDecision.verdict = selected U-kind with selectedUKindName = U.Ontic. Other proposed ontics must still fill the record by value; they do not inherit the U.* decision from E.24.

The slot relation must use [A.6.5](/generated/patterns/A.6.5) slot discipline and must not define a second slot discipline. A role-like, method-like, mechanism-like, source-like, publication-like, temporal, or architecture-like slot-position label is not a kind decision. It becomes a kind decision only when the governing pattern names that filled value by value and admits that kind.

#Check 4: Placement and Dependent-Pattern Obligation

Declare:

• semanticAreaBaseConcept, semanticArea, and semanticAreaSenseFamily;
• selected ontologicalNeighborhood;
• pattern nest and why that placement follows the primary EntityOfConcern, relation, or claim;
• first subject pattern to write;
• dependent patterns that may rely on the slot relation;
• draft-only or missing loci that cannot yet govern current claims;
• names that pass F.18;
• evaluation pattern for the resulting pattern or DRR, usually E.21 for a pattern and E.9.DA for the DRR.

If the decision selects a durable ontic, write the governing head pattern before dependent patterns rely on it. If only a bounded local frame exists, name it as non-governing and state the claims it carries and does not carry by value. If no governing head pattern is written, do not cite the proposed ontic as governing current FPF use.

#Local Use Frame Decision

Use a local use frame when a recurring construct is useful for one bounded application family and its filled positions are already governed elsewhere.

A local use frame:

• names the concern, use, or relation being handled in that bounded application family;
• links separately governed typed values without turning the link into a new U.* kind;
• points each value to its governing pattern;
• blocks one overread or shadow-kind temptation;
• does not mint a U.* kind;
• does not become a project record, evidence record, gate record, method, mechanism, work plan, or work occurrence.

Precision restoration may use a local use frame in one of its slots, but the frame is not defined by repair. P2W, work planning, evidence use, gate use, architecture use, or publication use may use the same subject ontology in different slots for different practical purposes.

#Archetypal Grounding

Use these slices as archetypes for the ontic-introduction decision. They are not a recommended progression. Each slice shows which object is being governed, which ontic or local use shape is selected, and which tempting overread is blocked.

#Episteme as Durable Ontic

U.Episteme passes E.24. It has stable identity, a normative U.EpistemeSlotRelation, required slots, optional slots, filled assignments, card and publication species, a description boundary, a publication-form boundary, and dependent patterns in C.2, A.6.2-A.6.4, and E.17. C.2.1 is therefore the right form: a subject pattern with a small typed ontic slot relation and dependent-pattern obligations.

#Multi-Pattern Subject Matter as an Ontic-Candidate Archetype

A project phrase such as "algorithm", "process", "solver", "workflow", "system", "quality", "time", "source", or "architecture" can point to one recognizable subject that is spread across several FPF values and patterns. The point of this archetype is not that all such subjects are one kind. The point is that E.24 must decide the status of the cross-pattern subject before patterns rely on it.

In this archetype, "process" and "workflow" are source-side labels until recovered. They may point to method, method description, work plan, dated work, transformation-flow structure, evidence relation, source relation, gate relation, result relation, publication relation, or another governed value. They become durable FPF ontology only through the same E.24 decision as any other proposed ontic; otherwise keep them quote-only, reduced-use, or resolved under the governing patterns that already carry the claim.

The E.24 move is:

1. name the candidate subject under concern;
2. list the typed values, relation positions, and governing patterns that currently carry pieces of it;
3. decide whether those pieces already close under direct governing patterns, whether a bounded local use frame is enough, whether a durable ontic with a head pattern and slot relation is required, or whether the apparent subject is only a source label or wording compression;
4. if a durable ontic is selected, write or cite the governing head pattern before dependent patterns rely on it.

Method, work, and change are one current stress case for this archetype. A project concern about changing, producing, selecting, deriving, controlling, maintaining, planning, performing, measuring, or carrying a result may involve U.Method, U.MethodDescription, U.Mechanism, formal-substrate declaration, mathematical-lens use, U.WorkPlan, dated U.Work, source-local process labels or workflow labels, transformation-flow representation, evidence relation, source relation, gate relation, result relation, publication relation, and temporal relation. That spread is an E.24 applicability signal. It does not by itself prove either "make one new ontic" or "existing constellation is enough".

The same decision applies to other broad heads. A proposed system, relation, role-participation, role-assignment, slot-discipline, characteristic space, temporal dynamics, or architecture ontic must pass the same decision. E.24 supplies the decision form; the governing subject pattern supplies the subject ontology and source set by value.

Dependent subject patterns may keep a thin cue: when one recognizable concern spans several typed values, name the current relation being made and use that relation's governing pattern. They must not copy a full negative formula, must not call a local constellation a durable ontic before the E.24 decision, and must not assign one typed value to two kinds unless a governing pattern explicitly admits that dual typing. Slot-position labels do not create alternate ontology.

#Draft Locus as False Authority

A draft ToC row or older source label may name a calculus, family, or object before current FPF has a governing pattern for it. Such a label can guide investigation, but it cannot govern current use.

Example: C.4 Method-CAL may appear in a ToC row or older source wording. If no current pattern text carries it, it is not a governing pattern for current FPF use. Use the current patterns that govern the filled values. A Method-CAL pattern can govern other patterns only after it has its own E.24-style ontic decision, stable identity, slot relation, and dependent-pattern declaration.

The same test applies to any draft-only locus. If the label has no current governing text, do not cite it as ontology. Either cite current governing patterns, keep the label as investigation context, or open an E.24 ontic-introduction decision.

#System-Like Head Concepts

system, episteme, architecture, method, mechanism, temporal claim, dynamics, and change can each appear as a broad head for many dependent FPF patterns. That breadth is not itself enough to create a durable FPF ontic. Apply E.24 before treating a broad head as current governing ontology: name the primary EntityOfConcern, stable identity, onticSlotRelation, selected semanticArea, selected ontologicalNeighborhood, dependent patterns, description boundary, and publication boundary. If those rows are missing, use the current governing patterns that already carry the claim and do not cite the broad head as if it supplied current slot discipline.

#Mature Comparator Discharge

E.24 is mature only when its selected mature-pattern ingredients are present in the body, not only in a separate planning or evaluation note.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto and Epist, Prag, Did. Scope: the authoring decision for a durable ontic, direct governing-pattern use, or local use frame, not the subject matter governed by the resulting pattern.

This pattern intentionally biases toward explicit identity, typed slots, and governing-pattern reuse. It resists five recurring distortions:

• shadow-kind bias: repetition of a local use frame is mistaken for a new object;
• placement bias: a pattern nest or draft ToC row is mistaken for semanticArea or governing text;
• name bias: a cleaner term hides unresolved kinds, slots, and relations;
• semio-bias: discussion of descriptions, publications, or review evidence displaces the ontic or subject matter being introduced;
• process-bias: development-state, publication-state, evaluation-state, or process-proof status is copied into ontic or subject-matter content.

The mitigation is the same in each case: recover the primary EntityOfConcern, stable identity, typed slot relation, selected semanticArea, selected ontologicalNeighborhood, and governing-pattern reuse before naming, placement, dependent pattern reliance, or publication form starts governing the decision.

#Rationale

FPF needs a pattern for ontic introduction because many important FPF ontology units are not one term, one field, one taxonomy branch, or one U-kind. They are small typed slot relations with identity criteria, slots, admissible values, record or publication species, dependent patterns, and action-facing use boundaries.

The compactness gain is the central reason for U.Ontic. A taxonomy-heavy design tends to create a new type for each contextual position: reviewer, evidence reviewer, architecture reviewer, work reviewer, mechanism reviewer; method, mechanism, procedure, process, algorithm; record, evidence record, gate record, authority record. An ontic design instead keeps a small number of governed ontology units and lets many objects fill typed relation slots. A relation slot works like a parameter position in a relation-function: the value is typed and constrained by the slot, but it does not become a new kind merely because it fills that position.

U.Episteme is the proof case inside FPF. C.2.1 does not define epistemes by a long taxonomy of descriptions. It defines stable identity and a small slot relation: EntityOfConcernSlot, claim graph, viewpoint, reference scheme, grounding, publication-form and source boundaries, and dependent episteme patterns plus publication patterns. The same small slot relation can hold many claim kinds, descriptions, views, publications, and project cases without minting a new episteme kind for each one.

Role participation is the second proof case. It is not the claim that roles are slots, slots are roles, or role is a special case of slot. U.Role remains useful because holons participate in contexts under context-bound role values, and U.RoleAssignment remains useful because the assignment binds holder, role, context, and window before work can be enacted through that assignment. The compactness gain comes from representing U.RoleAssignment as a typed relation with slot positions while preserving the governing kinds of the filled holon, role, context, window, method, plan, and work values.

This prevents a separate ontology for every participation name while preserving the real action-facing gain of the role patterns. "Engineer", "reviewer", "evidence reviewer", and "operator" do not become new system kinds merely because they appear in project language. They are recovered, when the case requires it, as role values and assignment relations under A.2, A.2.1, and A.15. Conversely, arbitrary relation participants such as a transformed television, an evidence target, an input, an output, a base, or a dependent are slot fillers or relation participants under their governing patterns, not U.Role values merely because ordinary language can say they "play a role."

Without E.24, FPF ontology development oscillates between two bad moves. One move invents a new umbrella name and leaves the mixed ontology intact. The other refuses the new name but still leaves several patterns carrying duplicated local slot doctrine. E.24 gives a bounded authoring decision: use an existing governing pattern, introduce a durable ontic, keep a local use frame local, or keep the source label quote-only or reduced-use.

The pattern is deliberately about the introduction decision. It does not define every ontic and does not become a registry of system, episteme, method, mechanism, architecture, source, quality, temporal, dynamics, or change objects. Each accepted subject matter still needs its own governing pattern or accepted local frame.

#SoTA-Echoing and Currentness

E.24 does not claim to replace ontology engineering, OWL-style formal ontology, or UFO-style foundational ontology. Its governing reason is the current FPF need for action-facing ontology compactness, plus a narrow SoTA echo:

This SoTA echo justifies a bounded conclusion: ontic-based FPF ontology architecture gives compactness and structure compared with a taxonomy-only design when the governed subject depends on identity, relation slots, dependent patterns, and action-facing use. It does not make every modular ontology pattern an FPF ontic. External sources govern the decision only when the DRR selects their payload for the specific ontic or subject matter under decision.

Use external sources when one ontic or subject matter itself depends on a source tradition. Put that source decision in the DRR and in the governing pattern for that subject matter. Do not make E.24 carry a borrowed external theory of every durable ontic.

#Currentness and Lowering Logic

Treat E.24 as current for ontic-introduction decisions only while the current FPF slot, precision-restoration, naming, and pattern-quality apparatus remain the governing source set. Lower E.24's current authority for a case when one of these changes governs that case:

• a new accepted FPF pattern changes slot discipline, EntityOfConcern discipline, or durable-name discipline;
• a local use frame begins to be reused as if it were a durable ontic;
• a draft locus becomes a current pattern and changes the ontic-introduction decision;
• dependent patterns start copying a slot relation instead of relying on the governing head pattern;
• external source work governs the introduction method itself rather than one selected ontic or subject matter.

Lower the decision before use when E.24 cannot decide among durable ontic, local use frame, existing governing-pattern use, quote-only source label, or reduced-use source label. A failed decision is not repaired by adding more fields; it is repaired by returning to E.24:4.1 and settling which object, slot relation, semantic area, ontological neighborhood, and governing patterns actually govern the decision.

#Conformance Checklist

#Common Anti-Patterns

#Relations

• Builds on: E.8, E.9, E.9.DA, E.10, E.10.ARCH, E.20, E.21, F.18, A.6.5, C.2.1, E.24.CD, and E.24.PUB.
• Coordinates with: governing patterns that describe durable ontics or their filled values, especially C.2.1 for epistemes; A.2, A.2.1, A.2.2, and A.15 for role participation, role assignment, capability, and role-method-work alignment; A.6.1 and E.20 for mechanisms; A.3.1 and A.3.2 for method and method description; A.3.4, E.18, and C.27.TA for transformation, transformation-flow, and temporal-aspect examples; and precision-restoration patterns such as C.2.P, C.2.P.DR, and C.30.STRAT.
• Used by: DRRs and pattern authors when repeated slot-relation-shaped material is being considered as either a durable ontic or a local use frame.

#Consequences

• FPF can introduce rich ontology units without letting every local use frame become a new ontology.
• Draft-only loci stop acting like current governing patterns.
• Dependent patterns get a stable slot relation when a durable ontic is selected.
• The cost is a short ontic-introduction decision before writing or relying on a durable ontic.

#E.24:End

Last Updated: 2026-06-11 — this section last modified in upstream FPF commit 20c8a0a5 (github.com/ailev/FPF)