FPF Reference

    EntityOfConcern, Description Episteme, and Specification-Use Discipline

    E.10.D2 · Stable · 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.

    Status: Stable

    Definitional pattern - normative, notation-agnostic

    One-sentence summary. Start from the exact work, decision, or other receiving use; recover the description episteme through C.2.1's exact <ClaimGraph, EntityOfConcern, effective ReferenceScheme> constitution; and add specification, viewpoint, view, model-use, evidence, publication, carrier, or representation machinery only when that receiving use depends on its separately governed relation.

    Status. Definitional pattern. Builds on: A.7 Strict Distinction (Clarity Lattice); C.2.1 Episteme Identity, Constitution, Grounding, and Edition; A.2.6 Claim Scope; A.1.1 Bounded Model-Use Structure; C.29 Mathematical Representation. Coordinates with. E.10 Ontological Precision Restoration; E.17.0 Viewpoint and View Membership; E.17 and E.24.PUB Publication; A.10 and B.3 Evidence and Assurance; G.11 Currentness; A.3.2 Method Description; F.9 Bridge; F.4 Role Description; F.5 Naming Discipline. Non-goals. This pattern introduces no description kind, slot relation, context tuple, card schema, publication kind, or representation kind. It does not decide whether claims are true, current, sufficient, authoritative, or permitted. It routes each live question to the direct owner while keeping the described object and the claim-bearing episteme recoverable.

    Use this pattern when one passage names an exact entity and also speaks of a description, specification, view, diagram, publication, file, dashboard, model, evidence item, assurance result, gate result, or decision around it. The recognizable failure is that the wording makes one of those neighboring objects stand in for the entity, the episteme, or the authority for the next action.

    Keywords

    • EntityOfConcern
    • Description episteme
    • specification use
    • DescriptionContext
    • testable
    • verifiable.

    Relations

    E.10.D2builds onStrict Distinction (Clarity Lattice)
    E.10.D2builds onLexical Discipline for “Context” (D.CTX)
    E.10.D2builds onU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.10.D2builds onUnified Formality Characteristic F
    E.10.D2constrainsRole Description (RCS + RoleStateGraph + Checklists)
    E.10.D2constrainsNaming Discipline for U-kind Names and RoleDescription Labels
    E.10.D2constrainsMint-or-Reuse Decision
    E.10.D2constrainsAlignment and Bridge across Contexts
    E.10.D2constrainsStatic and Regression Conformance Harness for Unification
    E.10.D2builds onUnified Lexical Rules for FPF
    E.10.D2coordinates withU.MultiViewDescribing - Viewpoints, Views & Correspondences
    E.10.D2coordinates withMulti‑View Publication Kit
    E.10.D2coordinates withOntic Description and Publication Discipline
    E.10.D2coordinates withU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.10.D2coordinates withUnified Scope Mechanism (USM): Context Slices & Scopes
    E.10.D2coordinates withBounded Model-Use Structure and DDD Bounded-Context Recovery
    E.10.D2coordinates withEvidence Graph Referring (C-4)
    E.10.D2coordinates withTrust & Assurance Calculus (F–G–R with Congruence)
    E.10.D2coordinates withTelemetry-Driven Refresh & Decay Orchestrator
    E.10.D2coordinates withMathematical Lens Use
    E.10.D2coordinates withU.EffectFreeEpistemicMorphing — Effect‑free morphisms of epistemes
    E.10.D2coordinates withU.EpistemicViewing — EntityOfConcern-preserving morphism
    E.10.D2coordinates withU.EpistemicRetargeting — EntityOfConcern retargeting morphism
    E.10.D2coordinates withAlignment and Bridge across Contexts
    E.10.D2coordinates withU.MethodDescription: Description Episteme for a Way of Doing
    E.10.D2coordinates withRole Description (RCS + RoleStateGraph + Checklists)
    E.10.D2coordinates withNaming Discipline for U-kind Names and RoleDescription Labels
    E.10.D2coordinates withU.Work: Dated Performed Work Occurrence
    E.10.D2outline parentUnified Lexical Rules for FPF
    E.10.D2outline prev siblingLexical Discipline for “Context” (D.CTX)
    E.10.D2explicit referenceU.Episteme: Constitution, Empirical Grounding, and Edition Relations
    E.10.D2explicit referenceStrict Distinction (Clarity Lattice)
    E.10.D2explicit referenceUnified Scope Mechanism (USM): Context Slices & Scopes
    E.10.D2explicit referenceBounded Model-Use Structure and DDD Bounded-Context Recovery
    E.10.D2explicit referenceMathematical Lens Use
    E.10.D2explicit referenceUnified Lexical Rules for FPF
    E.10.D2explicit referenceU.MultiViewDescribing - Viewpoints, Views & Correspondences
    E.10.D2explicit referenceMulti‑View Publication Kit
    E.10.D2explicit referenceOntic Description and Publication Discipline
    E.10.D2explicit referenceEvidence Graph Referring (C-4)
    E.10.D2explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
    E.10.D2explicit referenceTelemetry-Driven Refresh & Decay Orchestrator
    E.10.D2explicit referenceU.MethodDescription: Description Episteme for a Way of Doing
    E.10.D2explicit referenceAlignment and Bridge across Contexts
    E.10.D2explicit referenceRole Description (RCS + RoleStateGraph + Checklists)
    E.10.D2explicit referenceNaming Discipline for U-kind Names and RoleDescription Labels
    E.10.D2explicit referenceU.EpistemicViewing — EntityOfConcern-preserving morphism
    E.10.D2explicit referenceUnified Term Sheet
    E.10.D2explicit referenceU.EffectFreeEpistemicMorphing — Effect‑free morphisms of epistemes
    E.10.D2explicit referenceU.EpistemicRetargeting — EntityOfConcern retargeting morphism

    Content

    Problem frame

    Use this pattern when one passage names an exact entity and also speaks of a description, specification, view, diagram, publication, file, dashboard, model, evidence item, assurance result, gate result, or decision around it. The recognizable failure is that the wording makes one of those neighboring objects stand in for the entity, the episteme, or the authority for the next action.

    Begin with the receiving use:

    1. What exact work, decision, comparison, inquiry, preservation, teaching, publication, or other use needs the description?
    2. What is the next unresolved question or choice for that use? Do not invent one for a use that has none.
    3. What exact claim content is being used?
    4. What exact U.Entity is the EntityOfConcern of that claim-bearing whole?
    5. Which effective U.ReferenceScheme supplies the designation and interpretation rules that make those claims readable about that entity?

    The last three answers recover the C.2.1 EpistemeConstitutionRelation. If identity is all the receiving use needs, stop there. Otherwise open only the neighboring object or relation needed for the next visible sentence or action.

    Not this pattern when the live question is already an exact evidence path, assurance claim, work occurrence, gate decision, commitment, Bridge, publication occurrence, representation correspondence, or state fact. Use its direct governor. Return here only if the wording also obscures which entity is being described or which episteme carries the claims.

    The working distinctions are:

    • the EntityOfConcern is the independently identified entity about which the selected claim-bearing whole makes its claims;
    • a description episteme is an ordinary U.Episteme used to carry descriptive claims about that EntityOfConcern;
    • description use selects a separately governed DescriptionContext for one concern-bearing use without changing episteme identity;
    • specification use is a checkable use of a description episteme, not a third peer ontology class;
    • viewpoint, view, claim scope, model-use structure, grounding, evidence, edition, publication, carrier, and representation remain neighboring objects and relations.

    This buys a small practical result: the reader can say what is described, which claim-bearing episteme is being used, what the receiving use needs next, and where any additional claim is governed. A formal-looking file, card, suffix, approval, or diagram gains no ontological or practical authority by appearance.

    Problem

    1. Entity-description collapse. The EntityOfConcern is identified with the episteme, diagram, card, file, dashboard, or work record that says something about it.
    2. Record-shaped constitution. A local tuple, filled card, context record, or field list is treated as what makes the episteme exist.
    3. Specification inflation. Detailed or official-looking prose is called a ...Spec although no checkable claims and no exact harness or validation relation are present.
    4. Neighbor collapse. Viewpoint, view, claim scope, model-use structure, grounding, evidence, edition, publication, carrier, and representation become fields of one omnibus description object.
    5. Use-free qualification. Context, scope, structure, currentness, or publication machinery is required without naming the receiving use that needs it.
    6. Agency and authority leakage. A description, standard, card, approval label, or publication is said to perform work, authorize action, or establish a world-side fact without its direct relation.

    Forces

    ForcePressure
    Short practitioner move vs recoverable ontologyReaders need a concise first move, while a load-bearing claim must still recover the exact C.2.1 constitution and any live neighboring relation.
    Stable episteme identity vs changing usesOne episteme can be viewed, checked, published, represented, or used differently without acquiring another identity.
    Checkability vs official appearanceA document can be detailed, approved, or schema-backed without satisfying specification-use conditions.
    Useful qualification vs mandatory context recordA receiving use may need viewpoint, scope, model-use, or publication qualification; imposing all of them on every description recreates an omnibus record.
    Recursive description vs a meta-ontologyAn episteme can itself be described, but that case should use ordinary C.2.1 recursion rather than another description layer.

    Solution

    For the current passage or artifact:

    1. Name the receiving use. State the exact work, decision, inquiry, comparison, preservation, teaching, publication, or other use and what it needs next.
    2. Recover the episteme constitution. Identify the exact U.ClaimGraph, exact EntityOfConcern, and effective U.ReferenceScheme; test whether EpistemeConstitutionRelation obtains under C.2.1.
    3. Classify the expression or use. Decide whether the current object is the claim-bearing description episteme, a specification use of it, an assertion about another object, a publication form, a carrier, or a representation. Do not infer the answer from a suffix or medium.
    4. Open only a needed neighbor. Add empirical grounding, viewpoint, view, claim scope, model-use structure, evidence, edition, specification evaluation, publication, form, carrier, currentness, or representation only when the named receiving use depends on its direct relation.
    5. Stop at the smallest sufficient result. Do not produce a universal description card. A readable sentence naming the receiving use, the recovered episteme, its EntityOfConcern, and the one needed neighboring relation is normally enough.

    The ordinary minimum is prose, not a mandatory record:

    For <receiving use>, episteme <E> carries claims <G> about exact EntityOfConcern <T> under effective scheme <R>. <One named neighboring relation> is additionally current because <the next action depends on it>.

    If no neighboring relation is needed, omit the second sentence. If the C.2.1 triple or the required direct governor cannot be recovered, return that exact blocker instead of filling a generic context field.

    Core recovery discipline

    EntityOfConcern

    EntityOfConcern is the one exact independently identified U.Entity about which the selected claim-bearing whole makes its claims. It may be a system, work occurrence, method, episteme, direct relation occurrence, characteristic, structure, pattern, or another admitted entity. It is neither a universal object bucket nor the authoring target merely because the author is editing it.

    A ClaimGraph may designate several other entities as participants in relational, comparative, negative, counterfactual, or modal claims. Those designations do not by themselves create a joint EntityOfConcern. Select a relation occurrence, collection, or structured whole only after its direct pattern independently identifies that entity.

    Description episteme

    A description episteme is an ordinary U.Episteme whose exact U.ClaimGraph contains descriptive claims about its exact EntityOfConcern under its effective U.ReferenceScheme. Its identity is the C.2.1 constitution triple; E.10.D2 adds no subjectRef, description slot, isDescriptionOf relation, context constituent, or peer description ontology.

    Its ClaimGraph may contain labels, characterizations, criteria, structural or behavioral claims, diagrams interpreted under a scheme, or other claim-bearing content. Those claims and representations do not become parts or properties of the EntityOfConcern unless the corresponding direct subject pattern establishes them.

    For one describing use, the E.17.0-owned DescriptionContext selects the exact viewpoint from which this episteme is read. That use qualification is not an episteme identity discriminator, does not establish viewpoint conformance or U.View membership, and is not locally redefined here.

    Specification-use admission

    Use a ...Spec name only when the receiving use depends on specification force and all applicable conditions are recoverable:

    1. the exact description episteme and its C.2.1 constitution;
    2. checkable claims, invariants, criteria, or acceptance conditions in its ClaimGraph;
    3. a named harness, validation, conformance, measurement, or evaluation relation capable of checking those claims for the stated use;
    4. a preserved or explicitly updated E.17.0 DescriptionContext for that describing use.

    Declared formality, notation discipline, comparators, tolerances, and measurement rules are named when the claims depend on them. They do not substitute for the checkable claims or the harness. If the conditions are absent, call the episteme a description and present proposed criteria as proposals; a Spec suffix, schema, signature, approval, or publication does not supply specification force.

    Specification use does not create another episteme identity. A revision that changes ClaimGraph, EntityOfConcern, or effective ReferenceScheme identifies another episteme under C.2.1; a changed harness, evaluation result, publication, or relying use changes its own neighboring object or relation.

    Model-use structure

    A BoundedModelUseStructure is selected only when the receiving assertion, calculation, interpretation, comparison, or other use depends on the organization of admitted model-applicability, model-use, and coherence relations governed by A.1.1. The receiving use designates that exact structure through its direct relation. The structure is never a constituent of description-episteme identity merely because the episteme is used inside it.

    If a proposed dependent relation species genuinely requires one exact model-use structure as an identity-bearing participant, its own pattern must declare that participant and its obtaining and identity rules. E.10.D2 supplies no generic context relation as a shortcut.

    Episteme about an episteme

    When an episteme is being described, use ordinary recursion: the earlier episteme is the exact EntityOfConcern of the description episteme; the latter has its own ClaimGraph and effective ReferenceScheme. A publication, rendering, or representation of either remains separate. No mandatory context recursion, meta-description kind, or second episteme ontology is needed.

    Naming discipline

    Default suffix. Use ...Description when naming a description episteme for a practitioner-facing use.

    Reserved suffix. Use ...Spec only when the specification-use conditions above obtain. Do not use it as a synonym for detailed, official, approved, formal-looking, or stored in a schema.

    Entity names. Name the EntityOfConcern by its independently governed kind and identity: Role, Method, System, Architecture, Characteristic, PromiseContent, Work, Episteme, or another exact kind. Append Description, Spec, View, Publication, Form, Carrier, or Representation only when that neighboring object is what the name actually designates.

    Relation language. Prefer the direct governing verb: a description carries claims about an entity; a publication occurrence makes an edition available; a carrier bears a form; a representation corresponds under a scheme; evidence supports an assertion; an admitted system performs work. Do not turn those verbs into one generic description link.

    Role language. When source wording says that a description, source, standard, requirement, evidence item, publication, dashboard, or view “has a role,” recover its exact evidence-use, source-use, standard-use, requirement-use, publication-use, assurance-use, or gate-use relation. For a claimed Work use, name the exact premise, governed reference, decision-use relation, or A.6.1 operation-argument binding and its actual participants. If the claimed use needs another relation and no direct governor supplies its predicate and participants, return the exact missing-governor result rather than inferring a universal description-to-Work or episteme-to-Work relation. Open U.RoleAssignment only when an independently admitted U.System holds a work-facing role in bounded work; an acting holon is eligible only after that exact entity has independently passed U.System admission for this claim.

    Invariants

    D2-1 (Direct constitution). Every description episteme is identified through the exact C.2.1 <ClaimGraph, EntityOfConcern, effective ReferenceScheme> constitution; no local record or tuple replaces it.

    D2-2 (Entity-description distinction). The EntityOfConcern and a description episteme about it are distinct, including when the EntityOfConcern is itself an episteme.

    D2-3 (Specification is a use). Specification force is admitted by checkable claims, preserved or updated DescriptionContext, and a named harness or validation relation; it is not a peer class or label effect.

    D2-4 (Conditional neighbors). Grounding, viewpoint, view, claim scope, model-use structure, evidence, edition, publication, carrier, currentness, and representation enter only through their direct owners when the receiving use depends on them.

    D2-5 (Stable identity across use). Changed description use, viewpoint selection, harness, evidence, publication, form, carrier, rendering, or representation does not by itself change episteme identity.

    D2-6 (Work and authority separation). An episteme, plan, checklist, specification, standard, file, or dashboard performs no work and grants no permission, acceptance, assurance, or world-side truth without the exact direct relation.

    D2-7 (No label-only sameness). Identical labels across schemes, scopes, viewpoints, model-use structures, or contexts establish neither the same EntityOfConcern nor the same episteme. Use the governing identity and Bridge rules.

    D2-8 (Representation separation). A tuple, card, graph node, schema field, notation token, file, or UI element may participate in a representation or publication of a recovered object; it is not that object by position or appearance.

    D2-9 (No generic context relation). E.10.D2 defines no U.EpistemeSlotRelation, DescriptionContext tuple, BoundedContextRef constituent, mandatory context recursion, or universal description relation.

    Recovery decisions

    Current needRecoverDo not infer
    Identify or cite the claim-bearing descriptionExact ClaimGraph, exact EntityOfConcern, effective ReferenceScheme, and obtaining C.2.1 constitutionIdentity from title, file, card, context field, or publication
    Read one episteme for a concern-bearing describing useOne exact E.17.0 DescriptionContext selecting one exact viewpointViewpoint conformance, U.View membership, or another episteme identity
    Rely on description as a specificationCheckable claims, preserved or updated DescriptionContext, and exact checking harness or validation relationSpecification force from suffix, formality, approval, or storage format
    Use a selected organization of model useExact A.1.1 BoundedModelUseStructure designated by the receiving useStructure as an episteme constituent or generic context
    Describe an epistemeA new C.2.1 episteme whose EntityOfConcern is the earlier epistemeMandatory meta-description layer or context recursion
    Use unchanged content differentlyThe same episteme when all three identity discriminators remain fixed, plus the changed neighboring use relationA new episteme merely from changed viewpoint selection, evidence, publication, carrier, or representation
    Use a changed ClaimGraph, EntityOfConcern, or effective schemeAnother episteme under C.2.1Continuity from a retained label or file path

    Neighboring use routing

    Open a neighboring object only after naming the receiving use and recovering the description episteme. The same episteme can participate in several of the uses below; each use retains its own direct owner, participants, obtaining condition, and identity.

    Describing use, viewpoint, and view

    For one describing use, an E.17.0 DescriptionContext selects one exact U.Viewpoint episteme through its viewpointRef. It says from which concern-bearing viewpoint the already identified episteme is being read for that use.

    That selection:

    • does not enter C.2.1 episteme identity;
    • does not establish EpistemeViewpointConformanceRelation;
    • does not admit or remove same-individual U.View membership;
    • selects no receiving view and performs no A.6.3 viewing construction;
    • may change between two describing uses while the episteme remains unchanged.

    Call the same episteme a U.View only when it conforms to at least one exact U.Viewpoint episteme under E.17.0's fixed membership rule. Direct authoring and A.6.3 source-to-receiving construction can produce an episteme but grant no view membership. A rendering, publication form, or carrier-borne display is not a view by appearance. If one use must select several viewpoints, first identify their exact C.13 collection and any organization the use actually needs; do not overload one context qualification.

    Scope, model use, grounding, evidence, and currentness

    Use A.2.6 when the receiving use depends on the exact claim scope and its context-slice membership. Use A.1.1 when the receiving use depends on one exact BoundedModelUseStructure. Neither scope nor structure becomes a description constituent merely because a table displays it.

    Open C.2.1 empirical grounding only when claims must be mapped to exact observation, intervention, measurement, or test relations involving one grounding holon. Open A.10 when the use relies on an exact evidence-provenance path; open B.3 when an assurance claim is made or its material-reliance threshold is met. Evidence, assurance, or an evaluation result can support an assertion about a description or its specification use; none makes the subject-side claim true, changes the EntityOfConcern, or mutates the description episteme. State the exact validity or reliance window when that receiving use depends on one.

    Use G.11 when currentness of the description edition, evidence path, harness, viewpoint, publication, or another neighbor matters to the receiving use. A currentness judgment applies to that exact object or relation; it is not a generic status field of the EntityOfConcern.

    Where claims cross reference schemes, first recover the exact F.17 source and receiving senses and the obtaining F.9 Bridge needed by the direct use. A separate current C.2.1 claim states whether that Bridge is suitable for the named bounded use, direction, correspondence rule, and loss tolerance; A.10 or B.3 separately governs reliance. A Bridge, profile, card, or shared spelling is neither a licence nor proof that comparison, translation, or work occurred.

    Edition, publication, form, and carrier

    Changed ClaimGraph, EntityOfConcern, or effective ReferenceScheme identifies another episteme under C.2.1. When the receiving use also claims continuity between two epistemes, use the exact C.2.1 edition relation. A version label, file history, publication order, shared name, or collection membership establishes neither another episteme nor edition continuity.

    Use E.24.PUB to distinguish these actual publication-side objects and relations:

    Current object or relationWhat it doesWhat it does not establish
    selected episteme editioncarries the claim content made availablepublication occurrence, form, carrier, audience access, or reliance
    audience-declaration epistemestates the audience criterionthat a concrete receiver obtained, read, understood, or relied on the edition
    bounded-use-declaration epistemestates supported operations or decisions, conditions, and excluded stronger usespermission, acceptance, assurance, or actual work by itself
    publication formexpresses the selected edition for the declared publication useepisteme identity or a durable public form kind by position
    U.PresentationCarrierphysically or digitally bears the publication formthe episteme, the form, or the EntityOfConcern
    publication occurrencemakes the selected edition available to the declared audience for the declared bounded useexpression, bearing, access work, reading, or reliance

    The direct owner keeps the verbs exact: PublicationFormExpressionRelation relates edition, form, and bounded-use declaration; PublicationFormBearingRelation relates form and carrier; EpistemePublicationRelation governs bounded availability of the selected edition through that form and carrier. Rendering, printing, uploading, indexing, or access-control work remains dated U.Work performed by systems. Plain “published episteme” names contingent participation in a publication occurrence, not a durable U.EpistemePublication kind.

    One encountered thing can enter several relations without their objects collapsing. A completed inspection card may be a claim-bearing episteme; its reusable layout may be a publication form; a sheet or file may be a carrier; and a publication occurrence may make the selected card-episteme edition available to a maintenance team for one bounded use. Each claim is recovered independently.

    Representation

    Use C.29 when notation elements, diagram elements, tuple positions, graph nodes, table cells, schemas, or tool structures stand in an explicit representation correspondence to independently recovered objects for a declared modeling or reasoning use. A representation can change what users can inspect or calculate without becoming the represented entity, episteme, direct relation occurrence, or proof that the represented predicate obtains.

    A diagram therefore has distinct branches:

    • if its exact ClaimGraph, EntityOfConcern, and effective ReferenceScheme satisfy C.2.1, the selected claim-bearing whole is an episteme;
    • if that same episteme conforms to an exact viewpoint, E.17.0 may admit it as a U.View;
    • its graphical arrangement may separately be a publication form or a C.29 representation according to the receiving use;
    • a screen, sheet, or file may bear the form as a carrier;
    • a publication occurrence may make one selected episteme edition available.

    No branch follows from visual appearance, generation history, a heading, or a repository path.

    Work, status, and authority

    Only admitted systems perform authoring, evaluation, revision, publication, viewing, query, rendering, and use work under the corresponding work relations. The resulting episteme, publication, carrier, trace, or evaluation result does not perform that work.

    Epistemic and deontic statuses over epistemes are not role states, system states, or runtime facts about the EntityOfConcern. A gate verdict, permission, commitment, acceptance, requirement use, standard use, source use, or work authorization needs its exact direct governor. Neither a description nor its publication grants those effects by label, approval mark, or availability.

    Archetypal grounding and bias annotation

    System case. A service-interface description carries claims about one exact system interface under its effective scheme. The interface is the EntityOfConcern. A selected viewpoint for a safety review, a conformance harness, a publication to operators, and a deployment gate are four separate uses; none belongs in episteme identity.

    Episteme case. A DRR, pattern, safety case, source set, or model episteme can itself be the EntityOfConcern of another episteme. A review note about it uses ordinary C.2.1 recursion. Its dashboard, PDF, publication, evidence path, and review work remain separate regardless of which one the reader first encounters.

    Card and diagram case. A filled card or diagram can be a claim-bearing episteme when its C.2.1 constitution is recoverable. Its layout can separately be a publication form or representation, and its file can be a carrier. Filling or displaying it makes no subject relation obtain.

    The dominant bias is substitution by the most visible object: a reader sees a file, diagram, dashboard, card, label, or status and lets it replace the independently governed entity, episteme, relation occurrence, or authority needed for the decision. The corrective move is not lexical replacement. Recover the exact object and direct relation for the named receiving use.

    Anti-patterns and repairs

    Anti-patternSymptomRepair
    Entity-description collapse“The method is the document”; “the architecture is the diagram”; “the role contains the checklist.”Recover the exact EntityOfConcern and C.2.1 description episteme; route every subject-side claim to its direct owner.
    Filled-card ontologyA completed tuple, record, table, or schema is treated as what makes the episteme or relation exist.Recover the governed object and obtaining relation first; treat the record as an episteme, form, carrier, or representation only when its own recognition conditions hold.
    Spec by nameAny detailed, approved, or formal-looking write-up is called ...Spec.Use ...Description until checkable claims, the describing-use qualification, and an exact harness or validation relation are all recoverable.
    Context as identityA project, viewpoint selection, or model-use setting is copied into episteme identity.Keep the C.2.1 identity triple fixed; state only the exact use qualification or neighboring relation the receiver needs.
    Describing-use erasureA description is read as globally viewpoint-free, or a prior use's selected viewpoint is silently reused.Name the current receiving use and its exact E.17.0 DescriptionContext; changing that selection does not by itself reidentify the episteme.
    View by appearance or constructionA generated table, diagram, query result, or published face is called a U.View.Apply E.17.0 conformance for view membership; use A.6.3 only for actual source-to-receiving construction and E.24.PUB/C.29 for form or representation uses.
    Publication as authorityAvailability, an approval mark, card, dashboard, or file is treated as permission, evidence, assurance, gate result, decision, or work.Recover the exact publication occurrence, then apply the direct governor for the stronger claim.
    Carrier identityA file path, screen, sheet, or repository entry is treated as the episteme or EntityOfConcern.Identify the exact carrier and bearing relation while keeping form, publication occurrence, episteme, and EntityOfConcern separate.
    Status-state leakageEvidence, requirement, approval, or standard status becomes a role-state or runtime value.Keep status claims on their exact epistemic or deontic subject; use the direct state or attestation pattern for system-side facts.
    Episteme-role shortcut“The standard plays the compliance role”; “the evidence has the approval role”; “the source authorizes work.”Recover the exact standard-use, evidence-use, source-use, assurance-use, gate-use, or publication-use relation. For a claimed Work use, name the exact premise, governed reference, decision-use relation, or A.6.1 operation-argument binding and its actual participants; if no direct governor supplies the needed predicate and participants, return the exact missing-governor result. Reserve U.RoleAssignment for work-facing holder-role claims.

    Worked examples

    Each example begins with a receiving use and stops after the smallest sufficient recovery. It adds no generic description record.

    Bare role description

    A method author needs readers to recognize work-facing ChangeAuthorityRole before checking any assignment. ChangeAuthorityRoleDescription is a C.2.1 episteme whose exact EntityOfConcern is that independently admitted U.Role, whose ClaimGraph describes its work-facing sense, and whose effective scheme is the selected role-taxonomy scheme.

    For an operations-review use, one E.17.0 DescriptionContext selects the exact operations viewpoint. The ClaimGraph may cite credential criteria, a mandate window, separation-of-duty constraints, capability expectations, and a direct role-state relation when those neighbors are current. The role does not contain the description, checklist, graph, criteria, or relation occurrence. The description admits no holder and creates no U.RoleAssignment.

    The receiving use needs recognizability, not specification force, so the practitioner stops with the description. A specification use opens only if exact checkable role claims and their checking harness are named.

    Method description

    A team wants to teach BacklogRefinement, an independently admitted U.Method. BacklogRefinementMethodDescription is one C.2.1 episteme about that exact method. A.3.2 admits the same episteme as U.MethodDescription only when its claims make a substantive statement about the method as a way of doing—for example its applicability, preconditions, effects, bounds, enactment concern, or internal composition.

    A practice card's claim-bearing content may be that episteme; its reusable layout may be a publication form or C.29 representation, and its sheet or file may be a carrier. Classify a calendar session, chat thread, or ticket update from its actual facts as a Work occurrence, assertion or record, publication-side object, or another directly governed object; medium and label do not decide. An assertion or work record whose claim depends on the exact method-description edition may cite that edition through the exact premise, governed reference, or A.6.1 operation-argument binding required by the receiving claim. Separately, an actual dated Work occurrence enacts the admitted U.Method through A.15.1 enactsMethod(W, M); the method-description episteme is not a participant of that relation. Bibliographic metadata, approval, or a method label alone grants neither method-description membership nor specification force.

    Architecture description and view

    An architecture review asks how one exact ArchitectureOf@Context(PaymentService) addresses the operations concern. An architecture-description episteme carries claims about that architecture under its effective scheme. One DescriptionContext selects the exact operations viewpoint for this review.

    The episteme is a U.View only if the E.17.0 conformance relation to an exact viewpoint obtains. A structural graph can be part of its interpreted claim content, a C.29 representation, or a publication form according to the named use; no visual branch makes the graph the architecture. An ADR or dashboard creates no permission, assurance, or work relevance without the corresponding direct claim. If work uses the description, state the exact premise, reference, decision-use, or operation-argument relation through which the performed work actually consumes it.

    Specification use

    An integration team needs to decide whether a service-interface description is fit to drive a conformance test. The exact interface is the EntityOfConcern of PaymentInterfaceDescription; its ClaimGraph states message, ordering, error, and tolerance claims under the effective interface scheme. The current describing use selects one exact integration viewpoint.

    The team may call the episteme PaymentInterfaceSpec for this use only after the relevant claims are checkable, the DescriptionContext is preserved or explicitly updated, and the exact conformance harness or validation relation is named. A formal notation or approval signature can help interpret or govern a neighboring claim, but neither substitutes for those three conditions. A changed test result changes the result or reliance claim; it does not reidentify the interface or the episteme.

    Publication form and carrier

    A completed pump-inspection card is a claim-bearing episteme when its exact ClaimGraph, inspected pump as EntityOfConcern, and effective maintenance scheme satisfy C.2.1. The reusable card layout may fill the publication-form participant meaning for a maintenance use; one tablet file may be a U.PresentationCarrier; and an E.24.PUB publication occurrence may make the selected card-episteme edition available to a declared maintenance audience.

    The card episteme, layout, file, and availability occurrence retain different identities. Filling, uploading, or opening the card is dated work. Availability establishes neither that a technician read it nor that its claims are true or relied upon.

    Episteme about an episteme

    A reviewer writes an assessment of one exact DRR edition. The DRR episteme is the EntityOfConcern of the assessment episteme; the assessment has its own ClaimGraph and effective scheme. A PDF of either may be a carrier, a publication occurrence may make an edition available, and an evidence path may support the review assertion. None of those neighbors requires a meta-description kind or context recursion.

    Same content, different use

    One unchanged equipment-description episteme is first read under a maintenance viewpoint and later under a training viewpoint. Its ClaimGraph, EntityOfConcern, and effective scheme remain fixed, so C.2.1 identifies the same episteme. Two describing uses select different DescriptionContext qualifications. The second selection neither creates another episteme nor proves conformance to either viewpoint.

    If the training use adds another publication occurrence with another form or carrier, or relies on another evidence path, only those neighboring objects and relations change. If the training edition changes a claim or its effective interpretation scheme, C.2.1 instead identifies another episteme; retained wording or a shared file does not preserve identity.

    Minimal dashboard repair

    A project note says, “The architecture dashboard approves the deployment role.” The immediate receiving use is an operations discussion of the release candidate. Recover the smallest truthful result:

    • PaymentServiceArchitectureDescription is the C.2.1 episteme about exact ArchitectureOf@Context(PaymentService);
    • one describing-use qualification selects the exact operations viewpoint;
    • the dashboard may be a publication form, carrier, representation, or view only under the recognition rule for that exact use;
    • no checkable-claims-plus-harness basis has been named, so specification force is not admitted;
    • no gate verdict, permission relation, acting system, work-facing role assignment, or performed deployment work has been established.

    If the exact E.24.PUB objects are recoverable, the admissible next sentence is that one publication occurrence makes the selected architecture-description edition available for operations discussion through a dashboard publication form borne by an exact display or file carrier. “Approves” and “deployment role” remain non-assertable until their direct governors and case facts are named. The practitioner stops there instead of replacing the original sentence with another overloaded noun.

    Consequences

    ConsequenceCost or boundary
    Description and specification wording becomes safer across FPF.Authors must recover one C.2.1 constitution and the receiving use instead of relying on a suffix, title, or filled context record.
    One episteme can remain stable across changed viewpoint selections, harnesses, evidence, publications, carriers, and representations.Each changed neighboring use needs its own direct owner when it matters to the next action.
    Publication, evidence, assurance, gate, work, state, and role claims remain independently testable.Prose can become slightly longer when a source phrase compressed several non-substitutable relations.
    The ordinary move stays small because optional neighbors are opened conditionally.A genuinely load-bearing neighbor cannot be hidden merely to keep the sentence short.
    A local application can return an exact blocker.Reopen when the receiving use, C.2.1 discriminator, required direct governor, or checkability basis cannot be recovered from current facts.

    Rationale

    The durable core is a two-object distinction: one independently identified EntityOfConcern and one C.2.1 episteme carrying claims about it. Specification is a checkable use of that episteme. Viewpoint selection, view membership, scope, model-use structure, grounding, evidence, assurance, edition, publication, carrier, representation, and work have different reasons to obtain and different identity rules.

    Making those neighbors fields of a description tuple would erase those rules and make formality, publication, approval, or a shared context label look constitutive. Requiring all of them for every description would also make ordinary use needlessly heavy. Receiving-use-first routing preserves both reliability and economy: recover the exact constitution, add the one neighbor needed for the next action, then stop.

    SoTA-echoing and source use

    Source or practice lineFPF useBoundary
    ISO/IEC/IEEE 42010 architecture-description practice, retained as established-practice lineagePreserve the useful separation among described architecture, concern-bearing viewpoint, view, correspondence, and publication when testing architecture cases.It is neither FPF ontology nor a claim about the current best architecting method; it grants no evidence, assurance, gate, decision, or work authority.
    ISO/IEC/IEEE 29148:2018 requirements-engineering practice, retained as established specification lineageStress that specification use depends on checkable requirements, verification or validation, and a named life-cycle use rather than official appearance.The standard does not supply C.2.1 identity, E.17.0 DescriptionContext, or the direct FPF checking relation; detailed prose is not a specification by name.
    Current FPF C.2.1, E.17.0, E.24.PUB, A.1.1, A.2.6, A.10/B.3, G.11, and C.29 interfacesSupply the authoritative local identities and direct-use boundaries for episteme, viewpoint/view, publication, model use, scope, reliance, currentness, and representation.E.10.D2 consumes those interfaces; it does not mint a rival description ontology or copy every neighbor into one pattern.
    Rodin's constructive identity and near-sameness line, used as conceptual lineageKeep same-label and different-presentation cases answerable by explicit identity discriminators and evidence-backed comparison.Similar wording or a shared formal substrate does not establish the same EntityOfConcern, same episteme, an obtaining Bridge, or admissible substitution.

    Reopen this source-use synthesis when a cited standard changes the practical distinction, or when the current FPF constitution, viewpoint, publication, specification-use, Bridge, or representation interface changes enough that one of the routed decisions above would be stated differently. A newer source matters only when it changes the working decision, not merely because it is newer.

    Relations

    Builds on:

    • A.7 - Strict Distinction. Supplies the general discipline for keeping an independently governed entity distinct from epistemic and presentation-side objects around it.
    • C.2.1 - Episteme Identity, Constitution, Grounding, and Edition. Supplies the exact ClaimGraph, EntityOfConcern, effective ReferenceScheme constitution and the neighboring grounding and edition relations.
    • E.10 - Ontological Precision Restoration. Supplies subject-first recovery and the rule that a word, field, position, or representation does not create the governed object.

    Coordinates with:

    • E.17.0, E.17, and E.24.PUB. Govern DescriptionContext selection, viewpoint/view membership, publication occurrence, publication form, and carrier bearing without changing C.2.1 identity.
    • A.2.6 and A.1.1. Govern claim scope and bounded model-use structure only when the receiving use depends on them.
    • A.10, B.3, and G.11. Govern evidence provenance, assurance reliance, and currentness for exact objects and relations.
    • C.29, A.6.2, A.6.3, A.6.4, and F.9. Govern representation, episteme morphing, source-to-receiving construction, retargeting, and cross-scheme Bridge semantics without label-only sameness.
    • A.3.2, F.4, and F.5. Govern method-description membership, role-description content, and naming after the exact object and local sense are recovered.
    • A.15.1 and direct receiving-use patterns. Govern performed work and the exact premise, reference, decision-use, or operation-argument relations through which work actually uses an episteme.

    Repair moves

    Use these repairs on live prose; retain old spellings only as quoted source-side trigger wording:

    1. Start with the exact receiving work, decision, comparison, inquiry, preservation, teaching, or publication use and its next unresolved question or action.
    2. Replace DescribedEntity*, EntityOfInterest, EoI, EoIClass, and generic “object under description” wording with the exact EntityOfConcern and its independently governed identity.
    3. Replace local episteme-slot, subject-field, tuple, card, or context-record constitution with the exact C.2.1 ClaimGraph, EntityOfConcern, and effective ReferenceScheme test.
    4. Replace peer-layer I-D-S wording with EntityOfConcern, description episteme, and admitted specification use; specification is not a third peer kind.
    5. Route one current DescriptionContext to E.17.0 as a describing-use qualification selecting one viewpoint. Do not make it an episteme constituent, conformance fact, view-membership fact, or locally defined tuple.
    6. Replace “the role contains a characteristic space, state relation, or checklist” with a precise claim: the role-description episteme characterizes the exact role using claims that cite those independently governed objects or relations.
    7. Replace carrier identity with the exact publication form, U.PresentationCarrier, bearing relation, and publication occurrence required by the current use.
    8. Replace ...Spec names lacking checkable claims, preserved or updated DescriptionContext, and a named harness or validation relation with ...Description.
    9. Route permission, evidence, assurance, gate, decision, promise, commitment, work, publication, view, Bridge, retargeting, currentness, and representation claims to their exact direct governors.
    10. Replace “role of this description, source, standard, evidence, or publication” with the exact typed use relation. Use U.RoleAssignment only for a work-facing role held by an independently admitted U.System; an acting holon is eligible only after that exact entity has independently passed U.System admission for the claim.
    11. Delete mandatory context recursion for descriptions of epistemes; use ordinary C.2.1 recursion with the earlier episteme as EntityOfConcern.
    12. Stop when the recovered constitution and one needed neighboring relation make the next action clear; do not complete a universal description card.

    Conformance checklist

    IDCheck
    CC-D2-1Is the exact receiving use and its next question or action named before optional qualification machinery is opened?
    CC-D2-2Does every description episteme recover the exact C.2.1 ClaimGraph, EntityOfConcern, and effective ReferenceScheme, without a local slot relation or record-shaped constitution?
    CC-D2-3Is the EntityOfConcern independently identified and kept distinct from the description episteme, including in episteme-about-episteme cases?
    CC-D2-4For one describing use, does any DescriptionContext select exactly one current viewpoint without entering identity, conformance, or U.View membership?
    CC-D2-5Does every ...Spec use have checkable claims, a preserved or updated DescriptionContext, and an exact harness or validation relation?
    CC-D2-6Are grounding, view, scope, model-use structure, evidence, assurance, edition, currentness, publication, carrier, and representation opened only when the receiving use depends on their direct relation?
    CC-D2-7Are publication occurrence, form, carrier, view, representation, file, dashboard, and work record kept distinct from the EntityOfConcern and episteme?
    CC-D2-8Is current prose free of peer-layer I-D-S vocabulary, intensional object, DescribedEntity*, EntityOfInterest, EoI, EoIClass, mandatory context recursion, and a local DescriptionContext tuple?
    CC-D2-9Is the word plane absent for this distinction, with ReferencePlane reserved for a governing pattern such as CHR that actually defines it?
    CC-D2-10Is wording about the “role” of a description, source, standard, requirement, evidence item, publication, dashboard, or view resolved to its exact typed use rather than a spurious U.RoleAssignment?
    CC-D2-11Do systems perform work while epistemes carry claims, and are statuses, gate verdicts, permission, acceptance, assurance, and runtime state kept under their direct owners?
    CC-D2-12Does the application stop at the smallest sufficient result or return one exact missing-fact or missing-governor blocker?

    Phrasebook

    AvoidUse
    “The role contains the state graph.”“The role-description episteme carries claims that characterize the exact role and cite the separately governed role-state relation; the graph is a representation only when that use is current.”
    “The diagram is the architecture.”“Recover the architecture-description episteme first; then classify the diagram as claim content, U.View, publication form borne by a carrier, or C.29 representation only under the rule for the named use.”
    “MethodSpec draft.”“MethodDescription draft; specification use is not admitted until checkable claims, DescriptionContext, and the exact harness are present.”
    “The PDF is the method.”“The method-description episteme concerns the exact method; the PDF carrier bears a publication form that expresses a selected episteme edition.”
    “Same label, same thing.”“Compare ClaimGraph, EntityOfConcern, and effective scheme; when schemes differ, recover the exact senses, obtaining Bridge, and bounded-use reliance claim.”
    “Evidence status is a role state.”“The status claim concerns its exact epistemic or deontic subject; use the governing role-state or system-state relation for runtime facts.”
    “The source has the approval role.”“State the exact source-use, evidence-use, assurance-use, gate-use, or publication-use relation. For a claimed Work use, name the exact premise, governed reference, decision-use relation, or A.6.1 operation-argument binding and its actual participants; otherwise return the exact missing-governor result. None is a work-facing role assignment by wording.”
    “Fill the description context tuple.”“Name the receiving use and let one E.17.0 DescriptionContext select the exact viewpoint only when that describing use needs it.”
    “The dashboard approves deployment.”“An exact publication occurrence may make the architecture-description edition available through a dashboard form borne by a carrier; an exact gate verdict or permission relation is separately required for approval.”

    Didactic memory

    Use the short memory use, claims, entity, scheme, one needed neighbor:

    1. Use. What exact work, decision, inquiry, comparison, preservation, teaching, or publication use needs the description?
    2. Claims. What exact ClaimGraph is being used?
    3. Entity. What exact independently identified EntityOfConcern are those claims about?
    4. Scheme. What effective ReferenceScheme makes the claims readable about that entity?
    5. One needed neighbor. Does the next action actually need DescriptionContext, specification checking, grounding, scope, model-use structure, evidence, edition, currentness, publication, carrier, representation, Bridge, or work use?
    6. Stop. Add only that direct relation, or stop after constitution if none is needed.

    The older memory “entity, description, admitted specification use” remains a useful three-word reminder, but it is not a three-kind ontology. Entity names the independently governed concern; description names the C.2.1 claim-bearing episteme used descriptively; specification names a checkable use admitted for one receiving purpose.

    E.10.D2:End

    Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)