U.Kind and U.SubkindOf Core
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: Kind identity, subkind relation, and continuity pattern Status: Stable Normativity: Normative unless a section is explicitly informative
Use this pattern when work must recover one reusable kind, decide whether one kind is a subkind of another, or decide whether the same kind continues across a changed KindSignature edition.
Keywords
- kind identity
- membership criterion
- continuity
- U.SubkindOf direct relation
- criterion entailment
- closed finite domain
- preorder
- classification equivalence
- participant-determined occurrence.
Relations
Content
Use This When
Use this pattern when work must recover one reusable kind, decide whether one kind is a subkind of another, or decide whether the same kind continues across a changed KindSignature edition.
What goes wrong if missed. A source or practice label becomes an identity key, U.SubkindOf carries dependency or construction, a finite sample is mistaken for a universal order, mutually classifying kinds are silently merged, or a changed declaration is treated as automatically new or automatically harmless.
What this buys. The user gets an operational kind-continuity test, a replayable subkind test, and a small preorder that remains distinct from declaration identity, current extension, evidence, bridging, and public naming.
Primary EntityOfConcern. One U.Kind individual recovered through its candidate domain, operative membership condition, intended member/non-member distinction, and continuity rule; or one proposed U.SubkindOf relation between exact kind participants within declared applicability.
First useful move. Write the ordinary claim first: CoolingPumpKind is a subkind of PumpKind because every candidate that satisfies the declared cooling-pump condition also satisfies the pump condition. Then name the exact criteria and applicability that make that statement true. Introduce an occurrence designator or formal equivalence grouping only when a receiver uses it.
Not this pattern when. Use C.3.2 for a declaration, admissibility result, candidate classification, or extension; C.3.3 only for a claimed correspondence between independently identified distinct kinds; and E.24.UK when admitting another durable public kind rather than using an already admitted U.Kind individual.
Problem Frame
A practice/source boundary is provenance and a comparison cue. It affects the continuity decision only when comparison exposes a real difference in the candidate domain or membership distinction.
U.SubkindOf is separately admitted by E24UK-AR-USUBKINDOF-R5-01 as a same-individual dependent kind under U.Relation. Its participants are an exact narrower kind and broader kind. An effective reference scheme and aligned KindSignature editions make the criteria interpretable and qualify applicability; they are not relation participants or occurrence-identity discriminators. Candidate state, context slice, declaration edition, kind identity, and one obtaining subkind relation can therefore change for different reasons.
Problem
The sentence cooling pump is a pump is useful only when the membership conditions justify it. A current extension table can hide a bad proposal, and different intensional kinds can happen to classify the same candidates. Conversely, a unit rewrite, source move, or clearer declaration need not create another kind. The core needs an obtaining test for the relation and a before/after test for kind continuity without treating a signature, sample, locality, or extension as the kind.
Forces
Core Objects
Direct U.SubkindOf Relation Boundary
A readable sentence such as CoolingPumpKind is a subkind of PumpKind for this declared plant use states that the direct relation obtains. It needs no occurrence identifier when no receiver distinguishes or refers to the occurrence.
The relation obtains under the criterion-entailment branch when the exact narrower membership condition entails the broader one under the aligned interpretation and applicability. Under the closed-domain branch, it obtains only when the candidate domain is deliberately finite and closed, every candidate's admissibility has been checked, and exhaustive evaluation leaves no narrower true without a broader true. A counterexample refutes either proposal. A missing dependency or unknown judgment cannot establish either branch; a not-applicable request is outside the comparison.
When a receiver needs one occurrence, R_sub is participant-determined by the ordered pair of kind identities. The effective scheme, aligned signatures, and applicability qualify how obtaining is tested and asserted. A scheme-edition change therefore prompts an alignment and renewed test; it does not create another relation occurrence. If the same participants still satisfy the condition, the same relation continues to obtain. If they no longer do, the prior obtaining claim is no longer current; another assertion may record that change without inventing a scheme-keyed occurrence.
Solution
- Recover each kind before comparing it. For each kind, state the candidate domain, membership condition, intended member/non-member contrast, and continuity rule. Use practice/source provenance to locate the declaration, not to decide identity.
- Check admissibility first. Compare only candidates admissible under both aligned declarations and the stated applicability.
not-applicableforms no C.3.2 judgment. - Select one obtaining branch. Use exact criterion entailment when the membership rules can be compared directly. Use exhaustive evaluation only for a deliberately closed finite domain. State which branch and where it applies.
- Keep observations in their proper role. A non-exhaustive sample, test run, or extension can support the subkind assertion and expose a counterexample. It cannot close an open-domain obtaining claim.
- Keep a preorder over obtaining facts. Reflexivity and transitivity apply. Mutual facts between distinct kinds record classification equivalence for that alignment; they do not imply kind identity. Use the equivalence groups only when a receiver needs a partial order.
- Separate relation, predicate, and assertion. Use the readable relation sentence first. Add
R_sub, a C.2.1 assertion, evidence, or publication only when a named receiver consumes that object. - Diagnose counterexamples at the rule. Repair a false relation proposal, incompatible declaration alignment, or missing distinct-kind bridge. Do not edit an extension row to make the order appear true.
- Decide kind continuity independently. Apply the before/after test in section 6 whenever criterion, candidate domain, assumptions, dependencies, effective scheme, or locality changes. Another
KindSignatureedition neither proves nor denies kind continuity. - Keep scope and Work outside the kind. A kind carries no claim scope. An exact
W : U.Workremains a dated work occurrence under its direct pattern; keep it distinct from a plan, log, label, classification record, or episteme about W.
Continuity Decision
Compare the old and proposed declarations in this order:
Preserving change. CoolingPumpSignature-3 replaces litres-per-second with an exactly aligned SI expression, preserves the pump candidate domain, cooling-performance discriminator, intended member and non-member probes, and maintenance use. The same CoolingPumpKind continues; new judgments cite edition 3.
Identity-breaking change. A proposed edition replaces physical cooling performance with the presence of schema label CoolingPump. A physical pump without the row changes from member to non-member and a labelled non-performing row can appear to qualify. The operative distinction and candidate domain changed; identify another kind rather than continuing CoolingPumpKind.
Locality change. Journal and grant teams may reuse one exact ReviewerSystemRole when candidate Systems, required contribution, and acceptance condition remain aligned. If grant review requires a different contribution or admits a materially different candidate boundary, identify another kind. The two labels decide neither case.
Archetypal Grounding
Bias-Annotation
C.3.1 counters hierarchy, sample-as-law, assertion-as-world, locality, and table-repair bias. A stronger-looking edge is not automatically an obtaining relation; a sample does not close an open domain; mutual classification does not identify two intensional kinds; a changed source does not split one; and an extension remains an output representation rather than the place to repair the rule.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
- Encoding dependency, part-whole, slot filling, construction, system-role assignment, or admission as
U.SubkindOf, or treating a predicate expression, assertion, diagram edge, or table row as the obtaining relation occurrence. - Treating a source hierarchy or public-looking spelling as durable FPF ontology.
- Treating
KindSignatureas the kind or its formality as a property of the kind. - Assuming every signature edit makes a new kind, or that no signature edit can make one.
- Comparing extensions across incompatible editions and repairing a counterexample by changing rows.
- Storing claim scope on a kind.
- Treating a work label or record as an individual work occurrence.
Consequences
Benefits. Local typed compatibility remains small while its consequences for actual candidate judgments are testable.
Costs. A declaration change that matters to later classification needs an explicit edition and a separate continuity decision.
Risks avoided. False hierarchy, silent redefinition, retrospective reinterpretation, table-created membership, and kind/individual substitution are blocked.
Rationale
Kind identity, direct U.SubkindOf obtaining, assertion identity, declaration identity, candidate state, and current extension answer different questions and change under different conditions. Their separation lets a kind survive a compatible declaration revision while preventing an assertion or revised criterion from creating an order fact, silently rewriting prior classifications, or hiding a non-obtaining subkind proposal. Keeping the core small also prevents construction, admission, naming, scope, slot discipline, or dependency from being smuggled into one hierarchy relation.
SoTA-Echoing
Type theory, ontology engineering, and versioned schema practice distinguish intensional identity, preorders, equivalence classes, interpretation editions, and extensions. C.3.1 keeps that distinction but gives practitioners two replayable obtaining branches and a before/after continuity test; C.3.2 owns admissibility and judgment, C.3.3 owns distinct-kind correspondence, and E.24.UK owns the exact public admissions.
Relations
- Specializes:
A.6.RELforU.SubkindOf: exact ordered kind participants, criterion-entailment or exhaustive closed-domain obtaining, applicability, lightweight occurrence use, and participant-determined identity; schemes and declaration editions qualify interpretation and assertion rather than occurrence identity. - Builds on:
C.3, A.6.0 declaration identity, C.2.1 episteme and assertion identity, A.2.6/USM context-slice and scope discipline, F-G-R, and C.2.3 formality. - Coordinates with:
C.3.2judgments and extensions,C.3.3correspondence between independently identified distinct kinds,A.2when one local kind is a system-role kind,A.6.5declaration-slot uses that consume an already obtaining subkind relation,C.29representations,E.24.UKdurable U-kind admission, andA.8,A.11,F.8, andF.5when public kind governance is current. - Other governing patterns: Use C.2.1 for subkind-assertion epistemes, whether affirmative, negative, or unresolved; candidate features, classification assertions, kind declarations, context bridges, and public naming decisions retain their own governing patterns.
C.3.1:End
Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)