#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, and System-Role Kinds and Assignments

#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 when. Use F.10 when a receiving use depends on a word such as observed, measured, validated, approved, deprecated, satisfied, violated, waived, pending, current, or ready, and the exact status value, governed target, scope, window, source, rule, or use is still implicit.

#Keywords

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

#Relations

#Content

#Problem frame

Use this when. Use F.10 when a receiving use depends on a word such as observed, measured, validated, approved, deprecated, satisfied, violated, waived, pending, current, or ready, and the exact status value, governed target, scope, window, source, rule, or use is still implicit.

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 is cited as requirement satisfaction, a model card says a model is validated, or a requirement register says a clause is waived.

Primary EntityOfConcern. The live object is one exact status-use relation around an already governed bearer or target, one local status value, one ClaimScope/use scope, one validity window, and one intended receiving use. F.10 does not define or create the target and does not turn a display, source, list membership, approval act, evaluation rule, result, or evidence item into the status-use relation.

First useful move. Recover the exact target and its direct domain result first. Then name the status-value SchemeSenseCell and family under the effective ReferenceScheme, status scope/window, exact source and provenance/currentness constraints, intended use, and stronger use not carried. If a rule must be applied, name the dated evaluation work, rule application, and result separately.

What goes wrong if missed. One compact word does the work of domain result, evidence standing, standard approval, requirement satisfaction, gate passage, release readiness, permission, and assurance at once. A dashboard list or traffic-light cell is treated as actual status use. An F.9 Bridge or family edge is treated as the explanation or evaluation rule. Design approval becomes runtime satisfaction.

What this buys. Status words remain local, typed, comparable, and usable without hiding the target or the work that justified the status. Evidence status says only what evidential standing is being asserted for a claim; standard status says only what a named governing source sanctions; requirement status says only what is being asserted about an exact clause after its direct evaluation. Cross-local vocabulary and cross-modality interpretation remain explicit and loss-aware.

Not this pattern when. Use the subject's direct pattern for its target and domain result; A.2.4 for first evidence/status-use classification; A.10/G.6 for source recovery, provenance, and bounded reliance; G.11 for currentness; B.3 for assurance; C.28 for causal use; A.21 for a gate; the direct permission, commitment, requirement, standard, acceptance, release, or decision pattern for those results; E.17/E.24.PUB for publication; and A.15.1/A.6.1 for performed evaluation work and actual bindings.

#Problem

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

1. Modality collapse. Validated is read as evidence standing, standard approval, requirement satisfaction, and release permission at once.
2. Target collapse. The status does not say whether it concerns a claim, quantity, method description, standard edition, clause, system-role assignment, work result, publication, gate record, or another exact target.
3. Result collapse. A measurement, proof, conformance verdict, requirement-evaluation result, or assurance result is renamed as a generic status instead of retained under its direct governor.
4. Window and scheme loss. Status is asserted without the effective ReferenceScheme, ClaimScope, conditions, edition, or relevance window that makes contradiction and freshness checkable.
5. Source and display collapse. A badge, list row, dashboard tile, screenshot, certificate view, or generated summary becomes the status source or status use by visibility.
6. Design-run substitution. Standard approval is read as runtime satisfaction, or runtime evidence as approval, without an exact interpretation relation and evaluation rule.
7. Bridge overread. Shared spelling, a common family label, an F.17 row, an F.18 NameCard, or an F.9 Bridge is treated as the direct explanation, status application, or target result.
8. Episteme use drift. A report, standard, model card, dashboard cell, or requirement document is said to hold an “evidence role”, “status role”, or “standard role” rather than participate in an evidence-use, status-use, source-use, standard-use, or requirement-use relation.

#Forces

#Solution

Recover the governed target and direct result before applying a local status. Treat status value, status-use occurrence, status assertion, source, evaluation, display, and receiving use as distinct.

#Three status families

F.10 supplies a small set of three status families—EvidenceStatus, StandardStatus, and RequirementStatus—for common project use. A family classifies local status values; it is not a universal result kind and does not create its targets.

A project may define local sublevels or labels, but each label resolves under one effective ReferenceScheme to one exact local sense and maps to one of these three families—EvidenceStatus, StandardStatus, or RequirementStatus—or to another status family defined by its own pattern. Adding a family row creates neither a system-role kind nor a global synonym.

#Status value, use occurrence, assertion, and display

A local status value is designated through an exact F.17 SchemeSenseCell:

<EffectiveReferenceScheme, LocalExpression, LocalSenseClaim>

An F.18 NameCard may govern its selected public designation. An F.17 row may collect one or more cells for a named unification use; one-cell rows are valid. Neither the cell, card, row, spelling, nor family membership applies the value to a target.

One StatusUseRelation candidate names:

StatusUseRelation:
  StatusBearerRef:
  StatusTargetRef:
  DirectTargetAndResultGovernor:
  DirectResultRef:                 # when a domain result is consumed
  StatusValueCellRef:
  StatusFamilyRef:
  EffectiveReferenceScheme:
  StatusScope:
  StatusWindow:
  IntendedStatusUse:
  SourceClaimEpistemeRef:
  SourceRelationOrRegisterRef:
  EvaluationWorkRef:               # when a rule is applied
  EvaluationRuleAndApplicationRef: # when a rule is applied
  EvaluationResultClaimRef:        # when a result is produced
  ProvenancePathRef:
  CurrentnessRef:
  NotCarried:

For an F.10-family status, StatusUseRelation(B,T,V,G,W,U) obtains only when: B and T resolve to admitted governed objects; exact cell V has the required F.10 family/local sense under its effective ReferenceScheme; the family-specific source and any direct result/evaluation basis support applying V to T; G and W bound that application; and U is the named intended use without a stronger inference. Unknown or missing basis yields no positive occurrence and a Pending, Inconclusive, or explicit unresolved disposition only when that value's own rule is satisfied. Absence of evidence is never target falsity.

One F.10 occurrence is identified by the exact ordered tuple <B,T,V,G,W,U>. Repeated evaluations, assertions, displays, rows, records, or citations create no duplicates. A changed bearer, target, value cell, scope, window, or intended use identifies another candidate. A changed source, evidence path, evaluation, or currentness fact can change whether the fixed candidate is warranted or obtains; it is not silently copied into relation identity. A status under another exact predicate keeps its own subject assertion and defining or constraining ClaimGraph instead of inheriting this predicate by family resemblance.

A distinct C.2.1 status-assertion episteme states affirmative or negative polarity for the exact StatusUseRelation. A separate display or publication form may render that assertion. The assertion does not perform evaluation, and the display does not become the assertion, source, or actual receiving use.

#Recover the target and result first

Use this order:

1. name the receiving question and exact target;
2. recover the target's identity and direct governor;
3. recover any measurement, formal, causal, conformance, diagnostic, comparison, acceptance, requirement-evaluation, gate, assurance, permission, or decision result under its own pattern;
4. identify the C.2.1 episteme that states that result;
5. resolve the local status expression to its exact F.17 cell and F.10 family;
6. recover the source, edition, scheme, scope, conditions, window, provenance, and currentness required by this status use;
7. when a rule is needed, identify dated evaluation work, enacted method, exact direct/A.6.1 application, and evaluation-result claim;
8. assert the status-use relation and its C.2.1 status-assertion episteme; then separately recover publication/display and any actual later premise, decision-use, status-use, gate-use, or operation-argument relation.

Status never defines or constitutes the target. A changed status may change a receiving disposition without changing target identity or the earlier domain result. Conversely, a changed target or direct result requires the status application to be re-evaluated; copying the old value is not continuation proof.

#A.2.4 status-use positions

When an A.2.4 first-use classification is current, retain its positions by value:

These are relation positions, not system-role-kind qualifier slots, a record schema that applies status, or a new generic status ontic.

#Family value sets

EvidenceStatus local values:

1. Observed — seen or recorded once under declared observation conditions.
2. Measured — supported by a declared measurement method, model, calibration basis, value, and uncertainty.
3. Corroborated — supported by more than one independent source, procedure, or observation line.
4. Replicated — repeated by independent work or under varied declared conditions.
5. Refuted — counter-evidence defeats positive evidential standing inside the same scope and window.
6. Inconclusive — available input results and evidence-use relations are insufficient or mixed for the target claim.

These values classify evidential standing; they do not replace the observation, measurement, proof, causal, or other direct result, and Inconclusive is not target falsity.

StandardStatus local values:

1. Candidate — proposed and not yet normative for the named scheme/use.
2. Draft — worked text or profile, not yet the governing edition.
3. Approved — sanctioned by the exact governing source for the named scheme, edition, scope, window, and use.
4. Deprecated — discouraged, conditionally allowed, or being phased out.
5. Superseded — replaced by another named edition, profile, or governing source.

Approved does not mean that an approval act occurred unless its direct speech-act/decision relation is separately recovered; it grants no permission and proves no runtime satisfaction.

RequirementStatus local values:

1. Applicable — the exact clause binds under its governed scope, conditions, and window.
2. Inapplicable — the clause does not bind under those conditions.
3. Satisfied — a direct requirement/acceptance evaluation result says the clause is met for the exact target, scope, conditions, and window.
4. Violated — the direct evaluation result says it is not met there.
5. Waived — binding is suspended or excepted by an exact authorized source/relation and window.
6. Pending — the status application awaits a needed source, input result, evaluation, decision, or currentness repair.

Satisfied, Violated, Waived, and Pending do not replace the clause, evaluation work/result, waiver act or permission, gate decision, assurance result, or action.

#Bridge and interpretation discipline

Status meanings do not travel by label. When two local status senses under different ReferenceSchemes must be compared, use the actual F.9 Bridge occurrence between the exact F.17 SchemeSenseCells, with direction, bridge kind, tolerance/loss, and bounded use. Its Card or description is separate and optional; optional F.9 CL remains evidence-strength shorthand, not a use threshold. The Bridge makes no status-use occurrence obtain and produces no target result.

When one status-use occurrence is used to explain or evaluate a status question of another family, scheme, or modality, recover an exact StatusInterpretationRelation:

StatusInterpretationRelation:
  SourceStatusUseOccurrenceRef:
  TargetStatusQuestionRef:
  Direction:
  InterpretationRuleRef:
  EffectiveReferenceScheme:
  ClaimScopeAndWindow:
  BridgeRef:                    # only when local senses cross schemes
  IntendedUse:

It obtains only when the named interpretation rule admits that source occurrence for the exact target question, direction, scope, window, and use. Its occurrence identity is the exact ordered <SourceStatusUseOccurrenceRef, TargetStatusQuestionRef, Direction, InterpretationRuleRef, ClaimScopeAndWindow, IntendedUse> tuple; a Bridge ref is a separate qualifying premise when local senses cross schemes. A family edge, shared word, Bridge, table row, or source order is not this relation. Applying the rule is separate dated evaluation work; its result claim is separate again. Even a positive interpretation relation does not by itself produce RequirementStatus=Satisfied, StandardStatus=Approved, a gate result, permission, assurance, or actual later reliance.

#Design-run discipline

Keep three questions separate:

• What do exact observation, measurement, proof, causal, or other input results warrant as evidence standing for this target claim and window?
• What does an exact governing source sanction for this method description, profile, standard edition, or configuration and use?
• What does direct requirement-evaluation work conclude about this exact clause, target, scope, conditions, and runtime/design window?

A standard-approved method description may be admissible for selection under that profile. It does not show that the method was enacted or that a runtime clause was satisfied. Runtime evidence may become an admitted input to requirement evaluation through an exact evidence-use and status-interpretation relation. It does not approve the method, standard, gate, or release.

#Archetypal grounding

#Service acceptance from runtime evidence

July uptime is first recovered as an exact C.16 measurement result, stated by a distinct C.2.1 episteme. A.2.4 classifies that episteme for the uptime claim, and F.10 may assert EvidenceStatus=Measured for that exact claim, scheme, scope, and July window.

The SLO clause and service target are independently recovered. Dated evaluation work applies the SLO rule to the measurement result through exact bindings and produces a requirement-evaluation result claim. Only that basis can support a separate RequirementStatus=Satisfied occurrence. If monitoring and service-management senses differ, an F.9 Bridge handles the cells and a StatusInterpretationRelation handles the admitted explanatory/evaluation use. The measurement, evidence status, bridge, interpretation, evaluation work/result, requirement status, dashboard display, gate, assurance, and release decision remain distinct.

#Approved method description

One exact safety-controller MethodDescription is StandardStatus=Approved only under the named standard/profile edition, source relation, scheme, scope, window, and selection use. That status neither creates the MethodDescription nor proves an approval speech act, permission, method enactment, or response-time satisfaction.

A particular controller run is separate U.Work. Its response-time measurement result and evidence-use relation can enter direct clause-evaluation work. A separate requirement status may follow from that evaluation; it does not inherit Approved by label or family edge.

#Model card and fairness requirement

A model card reports high cross-validation AUC. Recover the exact predictive-performance result and claim episteme first; the card is a publication/display. F.10 may assert an EvidenceStatus for that predictive claim under its validation scheme and window. It cannot decide the different policy clause “demographic parity delta ≤ 0.1”. That branch needs production-window fairness measurement, its result episteme/evidence use, the policy clause, dated evaluation work, the exact policy rule application, and its own requirement-status assertion.

#Status display cue

A release dashboard cell shows Ready. The cell is only a cue until exact source assertion, target, value cell, scheme, scope, window, provenance/currentness, and intended use are recoverable. Display or list membership does not establish a status-use occurrence or actual reliance. If the status is consumed for a gate, release, assurance, admission, permission, or decision, the subject pattern must admit the separate use and result.

#Bias-Annotation

F.10 blocks five recurring biases:

• label-authority bias: familiar wording is treated as source authority;
• target-by-status bias: assigning a value is treated as defining or creating its target;
• display/list bias: visibility, row membership, or dashboard aggregation is treated as application or actual use;
• family/bridge explanation bias: a family edge, shared spelling, row, Card, or Bridge replaces the exact interpretation relation and rule; and
• system-role drift: an evidence, status, standard, or requirement use is treated as proof that its bearer is a U.System, has a local system-role classification, or holds a system-role assignment.

The repair is to recover target and direct result first, then the exact local value, relation occurrence, assertion, evaluation basis, display, and receiving use. None of those use facts establishes System admission, a local system-role classification, or an assignment. The same bearer may have those neighbouring facts only when it independently passes System admission and is the holder of an assignment occurrence whose declared species is known.

#Conformance checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

F.10 adds a small amount of relation recovery before status can be relied on. The user names exact target/result, local value, scheme, scope, window, source, rule, and use instead of letting a word decide everything.

The payoff is practical: teams can compare statuses across disciplines, explain why a status was asserted or rejected, locate bridge/interpretation loss, and stop a display from becoming target truth, permission, assurance, gate passage, or work evidence.

The cost is that F.10 cannot decide neighboring results. It does not perform measurement or evaluation, compute assurance, approve a standard by speech act, satisfy a clause, pass a gate, authorize work, prove causal effect, decide currentness, or establish actual downstream use.

#Rationale

Status words sit at the meeting point of evidence, norms, and action, so they are tempting shortcuts. The shortcut remains safe only when target, direct result, local sense, scope/window, source, evaluation rule, and intended/actual use stay visible.

The small set of three status families—EvidenceStatus, StandardStatus, and RequirementStatus—supports quick recognition without becoming a common result algebra. F.17/F.18 govern local sense and designation; F.9 governs cross-local sense bridges; F.10 governs the status-use and interpretation questions; direct subject, evidence, work, result, assurance, gate, permission, and decision patterns retain their own objects.

#SoTA-Echoing

#Relations

Builds on: F.17 for exact SchemeSenseCells and local-sense rows; F.18 for designation NameCards; F.9 for actual cross-local Bridge occurrences; A.2.4 for first status-use positions; C.2.1 for target-result and status-assertion epistemes; A.15.1/A.6.1 for evaluation work and applications; and the exact subject pattern of every target/result used.

Coordinates with: A.10/G.6 for provenance and bounded reliance; G.11 for currentness; B.3 for assurance-result claims; C.28 for causal use; E.17/E.24.PUB and C.29 for publication/representation; and the direct standard, requirement, acceptance, gate, permission, commitment, release, and decision patterns for their own results and uses.

Precision-restoration exit. When wording such as status role, approved role, validated means compliant, green means ready, or a family arrow hides target, result, value, scheme, window, source, interpretation rule, or actual use, recover those exact objects here and apply the pattern that defines each neighboring claim. Do not repair the phrase by minting a generic status, evidence, or result relation.

#F.10:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)