FPF Reference

Status Families Mapping (Evidence • Standard • Requirement)

Pattern F.10 · Stable Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

“Keep statuses in their native modality; translate between Contexts explicitly.” Status. Architectural pattern. Builds on: E.10.D1 D.CTX (Context ≡ U.BoundedContext); F.1 (Contexts), F.2 (Seeds), F.3 (Local‑Senses → SenseCells), F.4 (Role Description Status templates), F.9 (Bridges). Coordinates with. B.3 Trust & Assurance Calculus (interprets CL penalties); Part C patterns: KD‑CAL (measurement semantics), Norm‑CAL (deontic logic), Method‑CAL (DesignRunTag).

Intent. Provide a simple, Context‑first way to express and compare status meanings across disciplines without collapsing modalities (epistemic vs deontic). We focus on three pervasive status families:

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 onLexical Discipline for “Context” (D.CTX)
F.10builds onDomain‑Family Landscape Survey
F.10builds onTerm Harvesting & Normalisation
F.10builds onIntra‑Context Sense Clustering
F.10builds onRole Description (RCS + RoleStateGraph + Checklists)
F.10builds onConcept‑Set Table Construction
F.10constrainsRole Description (RCS + RoleStateGraph + Checklists)
F.10constrainsMint or Reuse? (U.Type vs Concept-Set vs Role Description vs Alias)
F.10constrainsService Acceptance Binding
F.10constrainsTrust & Assurance Calculus (F–G–R with Congruence)
F.10explicit referenceLexical Discipline for “Context” (D.CTX)
F.10explicit referenceDomain‑Family Landscape Survey
F.10explicit referenceTerm Harvesting & Normalisation
F.10explicit referenceIntra‑Context Sense Clustering
F.10explicit referenceRole Description (RCS + RoleStateGraph + Checklists)
F.10explicit referenceAlignment & Bridge across Contexts
F.10explicit referenceConcept‑Set Table Construction
F.10explicit referenceService Acceptance Binding
F.10explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)

Content

Intent & applicability

Intent. Provide a simple, Context‑first way to express and compare status meanings across disciplines without collapsing modalities (epistemic vs deontic). We focus on three pervasive status families:

  1. EvidenceStatus (what the world shows) — epistemic modality.
  2. StandardStatus (what a canon sanctions) — deontic (curatorial) modality.
  3. RequirementStatus (what an obligation is doing) — deontic (compliance) modality.

Each status meaning is local to a Context (U.BoundedContext). Cross‑context relationships appear only via Bridges (F.9) with a declared kind and CL (congruence level).

Applicability. Whenever models mix observations, standards, and obligations: service acceptance from uptime measurements; safety proofs against normative checklists; ML model “validated” vs “approved for use”.

Non‑goals. No workflows, no tool states, no editorial lifecycles. This pattern defines conceptual meaning and safe reasoning moves, not procedures.

Problem frame

Without a modality‑aware mapping of statuses:

  • Homonym traps. Validated in metrology ≠ validated in software QA; approved in a standard ≠ compliant to a requirement.
  • Design/run bleed. Design‑time “approved method” is used as if it proved run‑time “meets SLO”.
  • False substitution. Observed availability 99.95% is silently treated as SLO satisfied without declaring the translation.
  • Name inflation. New U.Types minted to stabilise drifting status words instead of fixing Contexts and Bridges.

Forces

ForceTension to resolve
Local fidelity vs Cross‑context reuseKeep native Context meanings, yet enable explanation and (sometimes) substitution.
Didactic simplicity vs status varietyMany status schemes exist; we need a small spine that admits Context synonyms.
Design vs runStandards speak design; evidence speaks run; requirements span both; do not swap them.
Safety vs utilitySubstitution is powerful but risky; explanation is safer but weaker. Make the choice explicit.

Core idea (didactic)

Three families, two modalities, one habit. Treat every status word as a SenseCell with a declared StatusModality and inside one Context. When you must relate statuses across Contexts, declare a Bridge (F.9) that says what kind of relation, how strong (CL), which way (if narrower/broader), and what is lost. Prefer explanation Bridges; permit substitution only when kind/CL allow it.

Reading an Episteme. For every U.Episteme, read Object (what it is about), Concept (model/postulates), Symbol (carriers). Statuses classify the Episteme; enactment remains with U.System and U.Work. (Formal identity rules: see KD‑CAL.)

Minimal vocabulary (this pattern only)

  • StatusFamily. Sub‑typing inside senseFamily=Status: one of EvidenceStatus, StandardStatus, RequirementStatus.
  • StatusCell. A SenseCell whose meaning is a status with a declared StatusModality ∈ {epistemic, deontic}
  • StatusModality. The mode of a StatusCell: epistemic or deontic. Use this term instead of the bare word modality per E.10 LEX rules.
  • Polarity. The orientation of a status relative to a claim/obligation: Positive (supports/satisfies), Negative (contradicts/violates), Neutral/Undetermined.
  • Window. The applicability span of a status (temporal or conditional), e.g., “Q3‑2025”, “under load ≥ 70%”.
  • Target. What the status is about: a claim (epistemic), an artefact or method (standard), a clause (requirement).
  • Bridge (F.9). The only legal way to relate StatusCells across Contexts; declares kind (≈, ⊑, ⊒, ⋂, ⊥, or an Interpretation arrow), CL, and Loss; substitution is modality‑preserving.

StatusModality guard. EvidenceStatus is epistemic; StandardStatus & RequirementStatus are deontic. Role Description Status templates (F.4) bind to these StatusModalities; no mixing. The bare token modality is against E.10/LEX); this pattern uses StatusModality.

The spine: three local ladders (Context‑native, small and renameable)

The following ladders are didactic spines. Each Context may rename levels or insert thin sub‑levels, but Bridges must state how they align to this spine (kind & CL). Names appear in Tech / Plain register.

  • Episteme‑as‑actor (forbidden). Never attribute Work to an Episteme; only Systems act.

  • Requirement vs Hypothesis. “Desired property/goal” is not Requirement status; use hypothesis/target + evaluation.

  • Mereology ≠ Provenance. Part‑whole edges never justify claims; use EPV‑DAG with carriers.

EvidenceStatus (epistemic statusModality)

Levels (from weaker to stronger):

  1. Observed / Seen once.
  2. Measured / Quantified under a declared procedure.
  3. Corroborated / Seen independently (≥ 2 distinct sources/procedures).
  4. Replicated / Repeated by others under varied conditions.
  5. Refuted (negative polarity) / Counter‑evidence overrides prior levels.
  6. Inconclusive (neutral) / Insufficient signal.

Context alignment examples (illustrative): SOSA/SSN:Observation ↦ Observed/Measured; GxP validation datapack may map to Replicated (if protocol diversity holds) with CL stated.

Invariants (context‑local): Replicated ⇒ Corroborated ⇒ Measured ⇒ Observed. Negative (Refuted) cancels positives within the same Window.

StandardStatus (deontic/curatorial statusModality)

Levels (design‑time stance):

  1. Candidate / Proposed, under review.
  2. Draft / Working text, not normative.
  3. Approved / Normative in this Context/edition.
  4. Deprecated (negative) / Discouraged; may be removed.
  5. Superseded (negative) / Replaced by a newer edition/profile.

Context alignment examples: ISO profile: Published International Standard ↦ Approved; IETF RFC (Proposed Standard) ↦ Draft/Approved depending on local policy; CL must be declared on the Bridge.

Invariants: At most one positive stance at a time per Context & edition; Superseded implies Approved held in a prior Window.

RequirementStatus (deontic/compliance statusModality)

Levels (run‑aware stance toward an obligation):

  1. Applicable / The clause binds in this Window.
  2. Inapplicable / Clause does not bind under stated conditions.
  3. Satisfied (positive) / Met within Window.
  4. Violated (negative) / Not met within Window.
  5. Waived (neutral/administrative) / Binding suspended with justification.
  6. Pending (neutral) / Awaiting evaluation or evidence.

Context alignment examples: ITIL4:SLO achieved ↦ Satisfied; ODRL:Duty fulfilled ↦ Satisfied; ODRL:Prohibition breached ↦ Violated.

Invariants: For the same clause and Window, Satisfied and Violated are mutually exclusive. Applicable is a precondition for either; Waived switches off the precondition temporarily.

Contextual Citation Operators (pointer)

Citation operators (context‑scoped). Authors MAY use the typed edges supports, refutes, dependsOn, supersedes inside a single Context when expressing how an Evidence/Standard status applies. Formal semantics live in B.3.2 (Evidence & Validation Logic). Cross‑Context use requires a declared Bridge (F.9) and carries CL/Loss penalties.

Solution — how meanings connect (conceptual, notation‑free)

S‑1. Anchor status meanings per Context. Every status word (validated, approved, compliant) is treated as a StatusCell inside a specific Context. The ladder position is determined locally (e.g., “validated (metrology)” aligns to Replicated with CL stated; “validated (software)” may align to Corroborated).

S‑2. Attach statuses to the right Targets. EvidenceStatus → Claim or Quantity; StandardStatus → Method/Artefact; RequirementStatus → Clause. This prevents swapping “how we measure” with “what we promise”.

S‑3. Translate via Bridges, not by name. Example: Measured availability (SOSA) →ᴍᴇᵃ SLO clause (ITIL) with CL=2, Loss: sampling window & clock skew. This supports explanation; substitution (“Satisfied”) requires same StatusModality, a stricter Bridge kind (F.9) and a declared evaluation rule (from the Service pattern), not from F.10.

S‑4. Keep design/run honest. StandardStatus is design‑stance; EvidenceStatus is run‑signal; RequirementStatus spans both. Use Interpretation Bridges (F.9) for design↔run readings, not equivalence.

S‑5. Prefer explanation over substitution. If a Bridge cannot reach CL≥2 on the same senseFamily, do not substitute. Use Naming‑only rows or explanations; keep Role Descriptions (F.4) out of harm’s way.

Invariants (normative, lightweight)

  1. Modality purity. A StatusCell’s StatusModality is explicit and must not change during reasoning; cross‑modality claims require an Interpretation Bridge (F.9).
  2. Target typing. A status must name its Target kind (claim / artefact / clause). Inferences that ignore the Target kind are invalid.
  3. Window discipline. Every positive/negative status names a Window; contradictions are detected within the same Window only.
  4. Local monotonicity. Within one context, stronger EvidenceStatus implies all weaker positives for the same Target & Window.
  5. Mutual exclusivity (requirement). For a given clause & Window: not (Satisfied ∧ Violated).
  6. No free promotion. StandardStatus (Approved) does not entail RequirementStatus (Applicable or Satisfied).
  7. Bridge gate. Any Cross‑context comparison or reuse of a status must cite a Bridge (kind, CL, Loss); otherwise only context‑local reading is permitted.
  8. Weakest‑link propagation. When multiple Bridges contribute to a Cross‑context interpretation, the effective CL is the minimum (cf. F.7/F.9).
  9. Naming restraint. Status labels used across Contexts without a Bridge are Naming-only and non-operative for Role Assignment & Enactment decisions.

Micro‑illustrations (snapshots, not procedures)

  • Metrology → Service. Observed uptime (SOSA) with Window “July” plus Bridge →ᴍᴇᵃ to SLO clause (ITIL) yields: we can explain why “Satisfied” might hold if the Service pattern’s evaluation rule says so. F.10 itself does not declare “Satisfied”.

  • QA vs GxP “validation”. Validated (software QA Context) aligns to Corroborated (CL=1–2). Validated (GxP Context) aligns to Replicated (CL=2–3) with Loss: environment diversity. Equating them needs ≈ with CL stated or they remain separate.

  • “Approved model” ≠ “Compliant outcome”. StandardStatus: Approved for a MethodDescription does not imply RequirementStatus: Satisfied for a production clause. It only permits use; evidence must still speak.

Anti‑patterns & remedies

#Anti‑patternSymptomWhy it harms reasoningRemedy (conceptual move)
AP‑1“Validated ⇒ Approved ⇒ Compliant” chainA single word validated is treated as proving approval and compliance.Collapses statusModalities (epistemic → deontic); ignores Targets & Windows.Keep EvidenceStatus about claims, StandardStatus about artefacts/methods, RequirementStatus about clauses. Use two Bridges (evidence→requirement via interpretation + standard→requirement via policy), never one.
AP‑2Run‑time proves design‑timeA month of logs is cited as “therefore the method is approved.”Directional fallacy; design‑time approval is curatorial, not measured.Separate design vs run. Evidence may justify a proposal Bridge to Approved only in Contexts where such promotion exists; otherwise keep explanation‑only.
AP‑3“Approved model” ⇒ “SLO satisfied”Governance stamp is cast as automatic service compliance.StandardStatus does not entail RequirementStatus; the latter needs evidence.Require EvidenceStatus on the clause’s Window, then apply the evaluation rule (Service pattern).
AP‑4Synonym drift of status labelsVerified/validated/approved used interchangeably across Contexts.Homonymy across Contexts; weakens claims.Treat each status word as a StatusCell tied to its Context; relate only via Bridge(kind, CL, Loss).
AP‑5No WindowStatus claimed without time/condition (“Compliant.”).Unfalsifiable; blocks conflict detection.Every positive/negative status names a Window; contradictions checked per Window.
AP‑6Double truthSatisfied and Violated asserted for same clause silently.Violates mutual exclusivity; hides differing Windows.Force Window discipline; if Windows coincide, at least one assertion must retract.
AP‑7Substitute by name“SOSA Observation = ITIL SLO check”.Cross‑context equality without Loss accounting.Prefer explanation Bridges; allow substitution only when same statusModality, kind ∈ {≈,⊑,⊒}, CL≥project threshold, Windows aligned.
AP‑8Evidence escalation without diversityOne lab repeats itself and calls it “replicated”.Confuses repetition with independent replication.In EvidenceStatus, Replicated demands independent settings/sources; else keep at Corroborated.
AP‑9Clause‑less compliance“Compliant” with no clause named.Target missing; cannot evaluate.Every RequirementStatus points to a clause (Target).
AP‑10Negative erased by summaryA later summary lists Satisfied but omits earlier Violated in same Window.Cherry‑picks; breaks auditability.Apply Weakest‑link: within a Window, negative outranks prior positives for the same clause.
AP‑11Bridge‑free roll‑upCross‑context dashboards aggregate statuses as if native.Hidden Cross‑context semantics; CL unknown.Each Cross‑context line must cite Bridges; roll‑up shows the effective CL (min).
AP‑12Status explosionNew bespoke statuses minted to match every tool state.Pollutes lexicon; blurs statusModalities.Map tool states to the nearest ladder level in the local context; keep tool terms as Naming‑only where needed.

Worked examples

Each example names Contexts, shows StatusCells on their native ladders, and draws only the Bridges that F.10 allows.

Service acceptance from run‑time evidence

Contexts. SOSA/SSN (2017) — sensing; ITIL 4 (2020) — services; ODRL 2.2 — deontics (optional).

Local statuses.

  • SOSA:Observation(uptime) → EvidenceStatus: Measured, Window July.
  • ITIL:SLO("99.9% monthly") → RequirementStatus Target = clause SLO‑99.9, Window July.
  • ITIL:Practice("Monitoring pipeline") → StandardStatus: Approved (design‑time).

Bridges.

  • Interpretation: Measured(uptime@July) →ᴍᴇᵃ SLO‑99.9 (kind = ⊑, CL = 2, Loss: sampling bias, clock skew).
  • Evaluation rule (Service pattern, local to ITIL Context): returns Satisfied iff mean uptime ≥ threshold across Window.

Result. We may explain the Satisfied conclusion for SLO‑99.9@July; we do not assert StandardStatus⇒RequirementStatus. If logs later show outages, a Violated@July replaces Satisfied@July (mutual exclusivity + Window discipline).

Safety controller: design approval vs run‑time duty

Contexts. State‑space control texts — design; IEC 61131‑3 — run; Norm‑CAL profile (safety layer) — deontics.

Local statuses.

  • ControllerSpec(v3) — StandardStatus: Approved in the Norm‑CAL Context.
  • PLC:Task(log@Q3) — EvidenceStatus: Corroborated for response time ≤ 50 ms, Window Q3.
  • Duty("Emergency stop ≤ 100 ms") — RequirementStatus clause in Norm‑CAL.

Bridges.

  • Interpretation: Corroborated(response@Q3) → Duty check (kind = ⊑, CL = 2, Loss: sensor latency).

Result. The duty may be Satisfied@Q3 with explanation. Approved spec alone never yields Satisfied; it authorises deployment but does not prove compliance.

ML model: validation vs fairness requirement

Contexts. ML validation canon — design/run hybrid; Policy Context (fairness charter) — deontics; SOSA/metrics — sensing.

Local statuses.

  • Model v12: cross‑val AUC=0.92 → EvidenceStatus: Corroborated (Windows: CV folds).
  • Policy: “Demographic parity Δ ≤ 0.1” → RequirementStatus clause.
  • “Validation SOP v5” → StandardStatus: Approved (governance method).

Bridges.

  • Measured(Δ@Aug) →ᴍᴇᵃ Policy clause (⊑, CL = 2, Loss: sampling variance).

Result. Satisfied@Aug (if Δ≤ 0.1 in production Window) is justifiable. Cross‑val AUC does not decide fairness; only production Δ does.

Medical device log: refutation

Contexts. SOSA/clinical observations; Regulatory profile.

Local statuses.

  • Observation: adverse event → EvidenceStatus: Observed@Week 34.
  • Requirement: “No AE in first 30 days” → RequirementStatus clause.

Bridge & outcome.

  • Observation → Interpretation Bridge to clause check (kind: Interpretation, CL=3).
  • Violated@Week 34 overrides any earlier Satisfied@Week 34 (Weakest‑link; same Window).

Reasoning primitives (judgement schemas, notation‑free)

Premises ⊢ conclusion. No side effects. All moves are mental and Context‑aware.

  1. StatusModality classification σ is a StatusCell ⊢ statusModality(σ) ∈ {epistemic, deontic} Reading: Every status sits on exactly one statusModality.

  2. Target typing σ ⊢ targetKind(σ) ∈ {claim, artefact/method, clause} Reading: Evidence→claim; Standard→artefact/method; Requirement→clause.

  3. Window requirement σ has polarity ∈ {positive, negative} ⊢ window(σ) ≠ ∅ Reading: Pos/neg statuses must name a Window.

  4. Local ladder monotonicity (evidence) Replicated(τ,W) ⊢ Corroborated(τ,W) ⊢ Measured(τ,W) ⊢ Observed(τ,W) Reading: Stronger implies weaker within the same Window.

  5. Requirement exclusivity clause κ, window W ⊢ ¬(Satisfied(κ,W) ∧ Violated(κ,W)) Reading: A clause cannot be both satisfied and violated in one Window.

  6. Windowed refutation Refuted(τ,W) ⊢ cancels {Observed,Measured,Corroborated,Replicated}(τ,W) Reading: Negative evidence cancels positives only in the same Window.

  7. Explanation Bridge σ@C, τ@D, Bridge(C,D, kind∈{≈,⊑,⊒,⋂}, CL, Loss), sameStatusModality ⊢ explains(σ ⇒ τ) with ⟨CL,Loss⟩ Reading: Cross‑context explanation is permitted when statusModalities match.

  8. Substitution permission (guarded) explains(σ ⇒ τ) ∧ kind∈{≈,⊑,⊒} ∧ CL≥θ ∧ windowsAligned ⊢ maySubstitute(σ→τ) Reading: Substitution is allowed only above a project‑declared threshold θ (see F.7) and aligned Windows.

  9. Cross‑statusModality embargo statusModality(σ) ≠ statusModality(τ) ⊢ explains(σ ⇒ τ) requires Interpretation kind Reading: Crossing statusModalities is interpretation only; no direct substitution.

  10. Observation→Requirement clause (SOSA, Work outcomes) SOSA:Observation about Work outcomes ⊢ may interpret(RequirementClause κ) via Bridge(kind=Interpretation, CL, Loss); produces Evaluation(κ, Window); substitution forbidden Reading: Observations inform clause evaluation within a Window; they never become RequirementStatus. Use F.12 for the verdict pipeline.

  11. Weakest‑link CL {explains(σᵢ ⇒ τ) with CLᵢ} ⊢ effectiveCL(⋀ᵢ σᵢ ⇒ τ) = minᵢ(CLᵢ) Reading: Multiple Bridges compose by the minimum CL.

  12. Naming‑only safeguard noBridge(C,D) ⊢ crossContextUse(σ@C ⇒ τ@D) = namingOnly Reading: Without a Bridge, only explanatory prose is allowed—no status inferences.

  13. DesignRunTag honesty statusModality=deontic ∧ targetKind=artefact/method ∧ window=W ⊢ doesNotDecide(clause κ @ W) Reading: Approval of a method never decides a clause’s satisfaction for a run‑time Window.

Relations

Builds on: E.10.D1 D.CTX (Context discipline); F.1 (Contexts in view); F.2–F.3 (Seeds→Local‑Senses→SenseCells); F.4 (Role Description Status template with statusModality/target/window slots); F.7 (Bridge taxonomy & CL semantics); F.9 (Bridge artefact).

Constrains:

  • F.4 (Role Description Status): a Role Description Status must select a StatusFamily, StatusModality, target kind, and Window.
  • F.8 (Naming): status labels reused across Contexts must be marked as Context‑scoped; global synonyms forbidden.
  • Part C patterns: KD‑CAL provides measurement semantics for EvidenceStatus; Norm‑CAL provides clause logic for RequirementStatus; Method‑CAL frames DesignRunTag for StandardStatus.

Used by. Service Acceptance (F.12), Assurance roll‑ups (B.3), any cross‑domain conformance narrative.

Migration notes (conceptual)

  1. New status word appears. Treat it as a StatusCell in its Context; place it on the local ladder; only then consider Bridges.
  2. Edition changes. If a Context redefines a status, fork the StatusCell (new SenseCell) and relate old↔new via a Bridge (often ⊑/⊒ with Loss).
  3. Threshold tuning. The project sets θ (minimum CL for substitution). Lowering θ widens reuse but increases risk; document the choice in F.7 terms.
  4. Clause redesign. If a requirement clause changes, keep old Windows intact; new clause starts a new Target; do not rewrite history.
  5. Explode→compress. When many bespoke tool statuses pile up, map them to the nearest ladder level in their Contexts; keep tool labels as Naming‑only.
  6. Bridge hardening. If explanation Bridges are used frequently, reconsider experiments that could raise CL enough to permit substitution—or accept explanation as sufficient and stop short of substitution.

Acceptance tests (SCR/RSCR — concept‑level)

Static conformance (SCR)

  • SCR‑F10‑S01 (Modality & Target). Every StatusCell declares StatusModality and target kind; none cross modalities.
  • SCR‑F10‑S02 (Windowed polarity). Every positive/negative StatusCell instance bears a Window.
  • SCR‑F10‑S03 (Local order). EvidenceStatus instances satisfy monotonicity; RequirementStatus enforces mutual exclusivity per clause+Window.
  • SCR‑F10‑S04 (Bridge citation). Any Cross‑context comparison cites a Bridge(kind, CL, Loss); absent that, mark as naming‑only.
  • SCR‑F10‑S05 (Substitution guard). Any substitution claim checks same StatusModality, kind ∈ {≈,⊑,⊒}, CL≥θ, Windows aligned.
  • SCR‑F10‑S06 (Weakest‑link). Where multiple Bridges feed one conclusion, the displayed effective CL is the minimum.

Regression (RSCR)

  • RSCR‑F10‑E01 (Edition churn). Adding a new edition of a Context does not retro‑change past status conclusions; only new Windows see new meanings.
  • RSCR‑F10‑E02 (Threshold change). If θ changes, re‑evaluate only substitution conclusions; explanations remain valid.
  • RSCR‑F10‑E03 (Bridge drift). When a Bridge’s CL/Loss changes, recompute affected effective CL; substitution conclusions below θ revert to explanation.
  • RSCR‑F10‑E04 (Contradiction catch). Adding a negative status within a Window cancels prior positives for the same clause (or raises a flagged contradiction if both persist).

Didactic distillation (90‑second script)

Three families, two modalities. Evidence tells us what the world shows (Observed→Measured→Corroborated→Replicated; Refuted cancels) — epistemic; Standard tells us what a canon sanctions (Candidate→Draft→Approved→Deprecated→Superseded) — deontic; Requirement tells us what an obligation is doing (Applicable/Inapplicable; Satisfied/Violated; Waived/Pending) — deontic. Every status is a StatusCell inside one Context with exactly one StatusModality, a Target, and a Window. When you must relate status meanings across Contexts, draw a Bridge that states the kind (≈, ⊑/⊒, ⋂, ⊥ or Interpretation), the CL (strength), and the Loss (what you ignore). Prefer explanation; allow substitution only when statusModalities match, kind permits, CL≥θ, and Windows align. Keep design vs run stance honest: approval is design‑time, evidence is run‑time, requirements span both. With this habit, “validated”, “approved” and “compliant” stop being a muddle of synonyms and become precise, local meanings you can compare safely and audibly.

F.10:End