FPF Reference

    Status Families Mapping (Evidence • Standard • Requirement)

    F.10 · Stable · Boundary and relation-use pattern · Normative · Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

    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: Boundary and relation-use pattern Status: Stable Normativity: Normative

    Use this pattern when a project uses status words such as "observed", "measured", "validated", "approved", "deprecated", "satisfied", "violated", "waived", "pending", "current", or "ready" and needs to know what kind of status is being claimed, what it qualifies, and whether it can be compared or reused in another bounded context.

    Keywords

    • status
    • evidence
    • standard
    • requirement
    • polarity
    • applicability windows.

    Relations

    F.10builds onAlignment & Bridge across Contexts
    F.10builds onTrust & Assurance Calculus (F–G–R with Congruence)
    F.10builds onU.EvidenceRole: The Evidential Stance
    F.10builds onDomain‑Family Landscape Survey
    F.10builds onIntra‑Context Sense Clustering
    F.10builds onLocal-First Unification Naming Protocol
    F.10coordinates withEvidence Graph Referring (C-4)
    F.10coordinates withTrust & Assurance Calculus (F–G–R with Congruence)
    F.10coordinates withU.Episteme - Epistemes and their slot relation
    F.10coordinates withCausalUse-CAL: Causal-Use Questions, Causality-Ladder Rungs, Identification and Realizability
    F.10coordinates withMulti-View Publication Kit
    F.10coordinates withU.MultiViewDescribing - Viewpoints, Views & Correspondences
    F.10coordinates withTEVB - Typical Engineering Viewpoints Bundle
    F.10coordinates withExplanationFaithfulnessProfile — explanation-use discipline over existing MVPK faces
    F.10coordinates withEntityOfConcern, Description Episteme, and Specification-Use Discipline
    F.10coordinates withRole Taxonomy
    F.10coordinates withU.RoleAssignment: Contextual Role Assignment
    F.10coordinates withRole-Method-Work Alignment (Contextual Enactment)
    F.10coordinates withRelation, Signature, Interface, Role, and Slot Precision Restoration
    F.10coordinates withWording-Use Ontological Precision Restoration Architecture
    F.10explicit referenceMulti-View Publication Kit
    F.10explicit referenceU.MultiViewDescribing - Viewpoints, Views & Correspondences
    F.10explicit referenceTEVB - Typical Engineering Viewpoints Bundle
    F.10explicit referenceExplanationFaithfulnessProfile — explanation-use discipline over existing MVPK faces
    F.10explicit referenceEntityOfConcern, Description Episteme, and Specification-Use Discipline
    F.10explicit referenceRole Taxonomy
    F.10explicit referenceU.RoleAssignment: Contextual Role Assignment
    F.10explicit referenceEvidence Graph Referring (C-4)
    F.10explicit referenceAlignment & Bridge across Contexts
    F.10explicit referenceU.EvidenceRole: The Evidential Stance
    F.10explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
    F.10explicit referenceCausalUse-CAL: Causal-Use Questions, Causality-Ladder Rungs, Identification and Realizability
    F.10explicit referenceRole-Method-Work Alignment (Contextual Enactment)
    F.10explicit referenceDomain‑Family Landscape Survey
    F.10explicit referenceIntra‑Context Sense Clustering
    F.10explicit referenceLocal-First Unification Naming Protocol
    F.10explicit referenceRelation, Signature, Interface, Role, and Slot Precision Restoration
    F.10explicit referenceWording-Use Ontological Precision Restoration Architecture

    Content

    Problem frame

    Use this pattern when a project uses status words such as "observed", "measured", "validated", "approved", "deprecated", "satisfied", "violated", "waived", "pending", "current", or "ready" and needs to know what kind of status is being claimed, what it qualifies, and whether it can be compared or reused in another bounded context.

    Use it especially when evidence, standards, and requirements are being mixed: a dashboard says a service is ready, a standard says a method is approved, a measurement says a requirement is satisfied, a model card says a model is validated, or a requirement register says a clause is waived.

    Primary EntityOfConcern. The primary EntityOfConcern is the status-use statement and the status-family mapping that make one status value usable in one bounded context. The pattern governs the relation among status cell, target, target kind, scope, window, source or provenance constraint, and intended status use. It does not make an episteme hold a role and does not treat a visible status display as gate passage, permission, assurance, evidence, or performed work by itself.

    First useful move. Write the smallest status-use statement: status family, bounded context, status value, target, target kind, scope, window when current, source or provenance constraint, intended use, and stronger use not carried by this relation.

    What goes wrong if missed. A single word such as "validated" starts doing the work of evidence, standard approval, requirement satisfaction, gate passage, release readiness, and assurance at once. Cross-context dashboards compare labels without bridge loss. A report or standard is treated as if it had a status role. A design-time approval is read as run-time compliance.

    What this buys. Status words stay local, typed, and comparable. Evidence status says what has evidential standing for a claim. Standard status says what a canon or standard-governed context sanctions. Requirement status says what is happening to an obligation or clause. Cross-context movement becomes an explicit bridge claim instead of a synonym guess.

    Not this pattern when. If the current claim is full evidence provenance, use A.10. If the current claim is only an episteme being used as evidence or status before full status-family mapping is needed, use A.2.4. If the current claim is assurance, use B.3. If the current claim is causal use, use C.28. If the current claim is a source, publication face, view, explanation, or specification-use question, use E.17, E.17.0, E.17.2, E.17.EFP, E.10.D2, or the direct publication-use pattern. If the current claim is a system or acting holon holding a work-facing role, use A.2 and A.2.1. If the current claim is performed work, use A.15.1.

    Problem

    Status vocabulary is useful because it is compact. It is dangerous because the same compact label often hides several different claims.

    The common failures are:

    1. Modality collapse. "Validated" is read as evidence, standard approval, requirement satisfaction, and release permission at once.
    2. Target collapse. A status is asserted without saying whether it qualifies a claim, quantity, method description, standard text, requirement clause, work result, role assignment, publication, gate record, or another exact target.
    3. Window loss. Positive or negative status is asserted without the time, edition, condition, or relevance window that makes contradiction and freshness checkable.
    4. Context leakage. A status word from one context is reused in another as if the label itself carried equivalence.
    5. Episteme role drift. A report, standard, dashboard cell, model card, or requirement document is described as having an "evidence role", "status role", or "standard role" instead of being used in an evidence-use, status-use, source-use, standard-use, or requirement-use relation.
    6. Design-run substitution. A design-time standard approval is read as run-time evidence, or run-time evidence is read as standard approval, without an interpretation bridge and an evaluation rule.
    7. Display overread. A badge, traffic-light cell, dashboard tile, register excerpt, screenshot, certificate view, or generated summary is treated as the status source, gate decision, or assurance result without recoverable source relation.

    Forces

    ForceTension this pattern resolves
    Local fidelity versus reuseEvery status value belongs to one bounded context, but projects need to compare and reuse statuses across contexts.
    Compact label versus typed relationStatus labels must stay quick to read, while the target, scope, window, source, and intended use must remain recoverable when reliance depends on them.
    Evidence versus standard versus requirementEvidence status is epistemic; standard and requirement statuses are deontic in different ways. Treating them as synonyms breaks reasoning.
    Design-time stance versus run-time standingStandards usually govern design or method choice; evidence usually comes from observed or measured work; requirements span both.
    Display cue versus source relationStatus displays help humans find a source, but the display is not automatically the source, decision, permission, or assurance.
    Ordinary speech versus FPF kind disciplinePeople say "the role of this status" or "the standard's role"; FPF recovers status-use, standard-use, requirement-use, or evidence-use relations instead of making epistemes role holders.

    Solution

    Treat a status claim as a context-local status-use statement, not as a free-floating adjective and not as a role assignment.

    Three Status Families

    F.10 uses three status families as a small spine for common project work:

    Status familyStatus modalityTypical target kindWhat it says
    EvidenceStatusepistemicclaim, quantity, observation-backed claim, effect claim, model-result claimWhat the available evidence says for or against a target claim in the current context and window.
    StandardStatusdeontic, curatorialmethod description, standard text, profile, governed product configuration, standard-governed project entityWhat a canon, standard, profile, or governing register sanctions, discourages, or supersedes in the current context and edition.
    RequirementStatusdeontic, compliance-facingrequirement clause, duty clause, constraint clause, acceptance criterion, obligation claimWhether a clause applies, is satisfied, is violated, is waived, is pending, or does not bind under stated conditions.

    A project may add local sublevels or local labels, but the local label must map to one of these families or to another direct status pattern named by value. Do not create a new role kind merely because a status word is local.

    StatusCell and StatusUseStatement

    A StatusCell is a context-local sense cell for a status value. It has a status family, status modality, typical target kind, polarity, and window discipline. A StatusCell is a meaning cell, not a work performer and not a gate decision.

    A StatusUseStatement applies one status cell or local status value to a target in a bounded context:

    StatusUseStatement:
  BoundedContext:
  StatusFamily:
  StatusCellOrLocalValue:
  StatusModality:
  StatusTarget:
  StatusTargetKind:
  StatusScope:
  StatusPolarity:
  StatusWindow:
  StatusSourceOrProvenanceConstraint:
  StatusUse:
  BridgeRef:
  NotCarried:

    StatusTargetKind decides relation identity. A status that qualifies a method description is not the same status-use statement as a status that qualifies a requirement clause, even when the visible label is the same. NotCarried names the stronger use that this status statement does not carry, such as gate passage, release permission, assurance, performed work, causal identification, global truth, or cross-context substitution.

    Relation Slots for Status Use

    Use the A.2.4 status-use slots when a status statement must be precise enough for reliance:

    SlotKindValueKindCurrentness discipline
    StatusBearerSlotepisteme, claim, method description, publication, role assignment, work occurrence, clause, gate record, or another bearer admitted by the direct patternNames the value whose status is being asserted or read. It does not make the bearer a role holder.
    StatusTargetSlotclaim, method, episteme, publication, work result, clause, bearer, or another governed targetRequired when the status is not simply about the bearer itself.
    StatusScopeSlotbounded-context scope, claim scope, admission scope, requirement scope, or use scopeCurrentness-required when scope changes the status assertion.
    StatusValueSlotstatus value governed by F.10 or a direct status patternRequired for any status assertion.
    StatusWindowSlottemporal validity window, freshness policy, edition window, status-currentness relation, or source-currentness relationCurrentness-required for time-sensitive or edition-sensitive status.
    StatusUseSlotgate use, assurance use, admission use, source-currentness use, work-plan readiness use, requirement evaluation use, standard-use, or another direct useRequired when the status is consumed for that use.
    StatusProvenanceConstraintSlotsource order, authority source, publication, proof, verification, register, or provenance constraintCurrentness-required when provenance decides status use.

    These SlotKinds are relation positions. They are not U.Role names, not work-role qualifier slots, and not a new generic status ontic by themselves.

    Family Spines

    The following spines are deliberately small. They help contexts map local status words without pretending that every domain has the same status vocabulary.

    EvidenceStatus values:

    1. Observed - seen or recorded once under declared observation conditions.
    2. Measured - quantified under a declared measurement procedure.
    3. Corroborated - backed by more than one independent source, procedure, or observation line.
    4. Replicated - repeated by others or under varied declared conditions.
    5. Refuted - counter-evidence defeats the positive standing inside the same window.
    6. Inconclusive - the available evidence is insufficient or mixed for the target claim.

    StandardStatus values:

    1. Candidate - proposed and not yet normative in the context.
    2. Draft - worked text or profile, not yet the governing edition.
    3. Approved - normative in this context and edition.
    4. Deprecated - discouraged, allowed only under stated conditions, or being phased out.
    5. Superseded - replaced by a newer edition, profile, or governing source.

    RequirementStatus values:

    1. Applicable - the clause binds in the stated context and window.
    2. Inapplicable - the clause does not bind under stated conditions.
    3. Satisfied - met within the stated context and window.
    4. Violated - not met within the stated context and window.
    5. Waived - binding is suspended or exceptioned by a named source and window.
    6. Pending - awaiting evidence, evaluation, decision, or source-currentness repair.

    Bridge Discipline

    Status meanings do not travel by label. A cross-context comparison, explanation, or substitution uses an F.9 bridge with direction, bridge kind, congruence level, and loss notes.

    Explanation is the ordinary cross-context use. Substitution is admitted only when the bridge kind, congruence level, window alignment, target kind, and local evaluation rule all admit the substitution. Cross-modality movement, such as evidence status being used to evaluate requirement status, is an interpretation relation; it is not equivalence.

    Design-Run Discipline

    Keep three questions separate:

    • What does the evidence show about a claim or measured quantity in this window?
    • What does the standard or canon sanction for a method description, profile, or governed project entity in this edition?
    • What is the requirement clause doing in this context and window?

    A standard-approved method description can be a source for method selection or a condition for allowed use. It does not by itself show that a run-time clause is satisfied. Run-time evidence can help evaluate a requirement clause. It does not by itself approve the method or standard profile unless a governing context has a rule for that promotion.

    Archetypal Grounding

    Service Acceptance from Run-Time Evidence

    A service dashboard reports uptime for July. In the monitoring context, the measurement episteme gives EvidenceStatus = Measured for the claim "uptime was 99.95 percent in July." In the service-management context, the SLO clause has RequirementStatus = Satisfied only if the service pattern's evaluation rule says that the measured uptime meets the clause.

    F.10 records two status-use statements and an interpretation bridge. It does not infer requirement satisfaction from the word "measured" alone.

    Approved Method Description

    A safety controller method description is StandardStatus = Approved in one standard profile and edition. That approval makes the method description admissible under that profile. It does not prove that a particular controller run met response-time obligations. A run-time log can be assigned EvidenceStatus = Corroborated for a response-time claim; a separate requirement-use statement can then evaluate the duty clause.

    Model Card and Fairness Requirement

    A model card says a model is "validated" because cross-validation AUC is high. In F.10 this becomes an EvidenceStatus statement for a predictive-performance claim inside the validation context. It does not decide the policy requirement "demographic parity delta <= 0.1" unless production-window fairness evidence and the policy evaluation rule are present.

    Status Display Cue

    A release dashboard cell shows Ready. The cell is a cue. A status-use statement is available only when the source, target, value, scope, window, and provenance constraint are recoverable. If the status is consumed for a gate, release, assurance, or admission use, the direct governing pattern for that use must also admit it.

    Bias-Annotation

    F.10 is vulnerable to three recurring biases.

    • Label authority bias. A familiar status word is treated as source authority. Repair by recovering status target, source, window, and intended use.
    • Semio-bias. A visible display, publication face, badge, or label becomes the center of the pattern. Repair by making the status-use relation the EntityOfConcern; display and publication questions go to E.17, A.10, or E.10.D2.
    • Role drift. A standard, report, dashboard, or requirement is described as having a role. Repair by using status-use, standard-use, requirement-use, evidence-use, or source-use relations; reserve U.Role and U.RoleAssignment for work-facing holders.

    Conformance Checklist

    CheckQuestion
    CC-F10-01 Status familyIs the status value mapped to EvidenceStatus, StandardStatus, RequirementStatus, or another direct status pattern named by value?
    CC-F10-02 ContextIs the bounded context or edition that gives the status value meaning named?
    CC-F10-03 Target kindDoes the statement name the exact target kind: claim, quantity, method description, standard-governed entity, requirement clause, gate record, role assignment, work result, publication, or another direct-pattern target?
    CC-F10-04 WindowDoes every positive or negative status name the window, edition, condition, freshness policy, or source-currentness relation that bounds it when current?
    CC-F10-05 Source and provenanceIs the status source, governing register, publication source, proof, measurement, verification, or provenance constraint recoverable when the use depends on it?
    CC-F10-06 ModalityIs epistemic status kept distinct from deontic standard or requirement status?
    CC-F10-07 BridgeDoes any cross-context comparison, explanation, or substitution cite an F.9 bridge with kind, direction, congruence level, and loss?
    CC-F10-08 SubstitutionIf one status is substituted for another, do bridge kind, congruence level, window alignment, target kind, and local evaluation rule admit that substitution?
    CC-F10-09 No role ontology driftIs there no claim that an episteme holds an evidence role, status role, standard role, or requirement role merely because it is used?
    CC-F10-10 Direct-pattern boundaryAre evidence provenance, assurance, causal use, source use, publication use, gate passage, permission, performed work, and work-role assignment sent to their direct governing patterns when those claims are current?

    Common Anti-Patterns and How to Avoid Them

    Anti-patternFailureRepair
    Validated -> approved -> compliantOne label carries evidence, standard, and requirement status at once.Split into evidence, standard, and requirement status-use statements; add bridge and evaluation rule only where admitted.
    Approved method means SLO satisfiedDesign-time standard status is used as run-time requirement status.Keep method-description approval separate from run-time evidence and clause evaluation.
    Status badge as gate passageA display cue is treated as source, decision, and permission.Recover source relation, target, window, and direct gate or release pattern.
    Clause-less compliance"Compliant" is asserted without a requirement clause.Name the clause or acceptance criterion and the window.
    Bridge-free roll-upCross-context dashboard aggregates labels as if meanings were native.Add F.9 bridges with loss notes or downgrade to local explanation.
    Evidence escalation without independenceOne repeated lab result is called replicated.Keep it measured or corroborated unless independent replication conditions are named.
    Status role for epistemeA report, standard, or requirement is said to hold a role.Use A.2.4 status-use or evidence-use relation slots and F.10 status-family mapping.
    Tool-state explosionEvery local tool state becomes a new status kind.Map local labels to the nearest context-local status cell; keep tool labels as local names when no durable family is needed.

    Consequences

    F.10 adds a small amount of relation work before a status claim can be relied on. That cost is intentional: the user names context, target kind, window, source, and use instead of letting one status word decide everything.

    The payoff is practical. Teams can compare statuses across disciplines, explain why a status was accepted or rejected, see where bridge loss enters, and stop a status display from becoming permission, assurance, or performed-work evidence by accident.

    The main limitation is that F.10 does not decide the downstream claim. It does not compute assurance, pass a gate, authorize work, prove causal effect, perform source-currentness repair, or evaluate a requirement clause by itself. It supplies the status-family and status-use relation that the direct pattern may consume.

    Open the direct governing pattern when the attempted use depends on evidence provenance, assurance level, gate decision, permission, performed work, causal identification, source freshness, publication interpretation, standard authority, requirement evaluation, or contested source order.

    Rationale

    Status words sit at the meeting point of evidence, norms, and action. That makes them tempting shortcuts. A shortcut is safe only when the status target and intended use remain visible.

    F.10 keeps the shortcut by using a small family spine, but it prevents ontology drift by making the status-use statement explicit. A status value is not a role. A status display is not the status source by itself. A standard approval is not run-time satisfaction. Evidence status can explain requirement status only through an interpretation relation and an evaluation rule.

    This keeps Part F naming and bridge machinery useful while letting A.10, B.3, C.28, E.17, A.2, A.15, and gate or requirement patterns govern their own stronger claims.

    SoTA-Echoing

    Practice pressureF.10 adoptionPractical implication
    Requirements engineering and compliance practice separates clauses, applicability, satisfaction, waiver, and evidence of satisfaction.RequirementStatus targets clauses or obligation claims, with window and source discipline."Compliant" without a clause and window is not a usable requirement status.
    Standards and profile governance separates candidate, draft, approved, deprecated, and superseded editions.StandardStatus is edition- and context-bound.An approved method description or standard profile does not by itself prove a run-time claim.
    Evidence and provenance practice separates observation, measurement, corroboration, replication, refutation, source, and confidence.EvidenceStatus qualifies target claims and remains consumable by A.10 and B.3.A badge, citation, metric, or dashboard tile must expose source relation before stronger reliance.
    Cross-context terminology practice uses bridges rather than global synonyms.F.9 bridge kind, direction, congruence level, and loss govern cross-context status comparison.Cross-context dashboards can explain status differences without silently equating labels.
    Digital credential, register, and dashboard practice separates visible status views from issuer, verifier, subject binding, revocation, currentness, and relying context.Status display is a cue; status-use statement needs source and provenance constraints when relied on.A green cell or credential view is not gate passage, role assignment, permission, or assurance by itself.

    Relations

    Builds on: A.2.4 for evidence-use and status-use relation slots; F.1 through F.3 for context, seed, and local-sense discipline; F.9 for bridges across contexts; F.18 for local-first naming discipline.

    Coordinates with:

    • A.10 when a status claim depends on evidence provenance, evidence source, source-currentness, or evidence-producing work.
    • B.3 when a status is consumed as assurance input.
    • C.2.1 when the identity of the episteme, claim graph, reference scheme, or grounding holon matters.
    • C.28 when the status is causal, counterfactual, intervention-facing, or simulation-output-facing.
    • E.17, E.17.0, E.17.2, E.17.EFP, and E.10.D2 when a publication face, view, explanation, source, description, or specification-use question is current.
    • A.2, A.2.1, and A.15 when a system or acting holon holds a work-facing role or performs work.
    • Gate, release, standard-use, requirement-use, decision, and source-currentness patterns when status is consumed for those stronger uses.

    Feeds: A.6.RSIR and E.10.ARCH as the repair destination when source wording says "status role", "approved role", "standard role", "validated means compliant", "green means ready", or another status-shaped phrase hides target kind, status family, window, bridge, source, or direct-pattern use.

    F.10:End

    Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)