#State-Family Precision Restoration

A.19.SPR · Stable · State-family precision-restoration pattern · Normative unless explicitly marked informative · Part A - Kernel Architecture Cluster

#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: State-family precision-restoration pattern Status: Stable Normativity: Normative unless explicitly marked informative

Plain-name. State-wording repair.

Use this pattern when a phrase such as “the system is ready”, “the source is current”, or “the evidence status is incomplete” matters to an FPF claim but does not yet say which item the sentence is about, what is true of it, or which rule makes that statement meaningful.

#Relations

#Content

#Use this when

Use this pattern when a phrase such as “the system is ready”, “the source is current”, or “the evidence status is incomplete” matters to an FPF claim but does not yet say which item the sentence is about, what is true of it, or which rule makes that statement meaningful.

What goes wrong if missed. A short status word starts carrying several claims at once. A source label becomes evidence, a readiness label becomes gate passage, or a project-side status leaks into pattern guidance.

First question. Ask:

What exact item is this sentence about, what does it say about that item, and which rule or criterion gives the statement its meaning?

Cheap direct repair. Write the answer as one ordinary technical sentence. Name the item, the actual value, relation, result, or claim, and the rule or criterion only when the reader needs it to understand or act. If that sentence is clear and safe for the intended use, stop. Do not create a repair note or list every claim the sentence does not make.

What this buys. A reader can understand the statement and its next practical use without learning a hidden status vocabulary.

Typical triggers include state, status, posture, stance, currentness, validity, stable, accepted, blocked, candidate, degraded, readiness, ready, and similar compounds. A precise-looking field such as LensUseBoundaryValue or dynClaimPosture is also a trigger when its object, possible values, or rule cannot be recovered.

Not this pattern when.

• If the exact item, claim or value, and applicable rule are already clear, use that rule directly.
• If readiness or ready still hides whether the sentence concerns a subject state, assignment condition, work entry, gate decision, publication use, permission, or performed Work, use E.10.MOVE first.
• If the wording is ordinary prose and carries no FPF-governed claim, keep it ordinary.
• If one Characteristic, Scale, Coordinate, score, or measurement construction is hidden, use C.16.P first.
• If a source expression, publication, carrier, or source-use relation is hidden, use C.2.P first and return here only if a state-wording problem remains.
• For relation, architecture, quality, function, or naming problems, use A.6.P, C.30.P, C.16.Q, A.6.F, or F.18 as selected by E.10.

#Problem frame

FPF needs compact state words. Engineers reasonably say that a pump is stable, a source is current, an evidence path is incomplete, an assurance claim has expired, or an intended performance is ready for work entry.

The words work when the reader can recover the item, the actual claim or value, and the rule behind it. Trouble begins when the word replaces those facts. “Ready” may mean a patient condition, an assignment satisfying a condition, an A.15.5 work-entry result, an A.21 gate decision, or merely a green display. Those are different claims.

A repaired sentence may therefore name an ordinary domain condition, an obtaining relation, an assertion episteme, an evaluation result, a decision result, or a project-side record field. It introduces a predicate only when the rule for that claim defines or needs one.

#Problem

How can FPF keep useful words such as state, status, and ready without:

• creating one general Posture or readiness kind;
• replacing one broad status word with another;
• treating every state statement as a CharacteristicSpace position or predicate;
• merging source use, evidence, assurance, publication, assignment state, work entry, gate decisions, performed Work, and project records;
• copying the same wording-repair procedure into every pattern; or
• deleting a useful local finite field whose object, values, rule, and practical use are already clear?

#Forces

#Solution

Start with the direct sentence:

1. name the exact item;
2. say what value, relation, result, or claim is current; and
3. name the rule or criterion when the sentence is not understandable or usable without it.

Stop there when the intended reader can act safely. Add evidence, time, allowed-use, or blocked-inference detail only when that detail changes the receiving action or prevents a likely harmful conclusion.

Use a StateFamilyPrecisionRepair note only when another person or tool must replay the repair, or when the claim has enough consequence that its extra basis must remain inspectable:

StateFamilyPrecisionRepair:
  triggerSpan:
  finalSentence:
  recoveredObjectRef?:
  recoveredClaimValueRelationOrResult?:
  definingOrTestingPatternLocator?:
  predicateRef?:
  criteriaOrEvidenceRef?:
  allowedUse?:
  blockedInference?:
  checkAgainWhen?:

The optional fields are triggered separately:

A direct relation, classification, assertion episteme, evaluation result, decision result, or record field keeps its own form. The repair note does not turn it into a new state predicate or result kind.

#Direct repair

For ordinary prose, inspect only the current sentence:

1. Find the item. For system-role wording, distinguish an exact local system-role kind, an obtaining assignment, its state condition, the world-side assignment-state relation, and an assertion about either. Do not stop at bare role.
2. Write the claim. Say that the item has a value, that a relation obtains, that an assertion or result says something, or that a project record has a field value.
3. Use the direct rule. Cite the applicable pattern when its criterion or distinction matters. If the direct rule already settles the sentence, A.19.SPR has finished its job.

Add a time boundary, evidence basis, allowed use, or blocked inference only under the triggers above. If the item or claim still cannot be recovered, keep the wording as a quotation or navigation cue, narrow its use, or state the exact blocker.

#Assignment-state exits

#Readiness exits

When readiness or ready still hides which governed value is meant, use E.10.MOVE first. Once the claim is recovered, leave the wording repair through exactly one direct exit:

#Where the repaired claim belongs

#Keeping a technical state field

A technical field such as ...Status, ...Readiness, or ...State may stay when the text makes three things clear: what item the field describes, which values it can take, and which rule or criterion gives those values meaning.

Add an allowed-use boundary only when the field changes a receiving action. Add a blocked inference only when a likely misreading would be harmful. Add a validity window or recheck condition only when the value can change during the intended use. Machine-readable identifiers belong only to automation, audit, comparison, or replay that consumes them.

If the three basic facts are missing, complete them or replace the field with the ordinary sentence the reader actually needs. A narrowing adjective alone does not recover the claim.

#Worked examples

Each example starts with the smallest useful final wording. The second paragraph adds detail only for a machine-readable, replayed, or high-consequence use.

#Physical-system state

Before: “Pump 37 is in a good operating state.”

After: “Pump 37 satisfies InspectionOperatingCondition: its coolant temperature is 72 °C, within the 60–80 °C band, and its discharge pressure is 315 kPa, above the 300 kPa minimum.”

For a relied-on inspection decision, also name the reading time, measurement basis, condition edition, and the event that requires another check. Do not add those fields to a casual status sentence that no decision consumes.

#Work-entry readiness is not gate passage

Before: “Release 12 is ready.”

After: “At 10:00, the A.15.5 check found that PlanItem-Deploy-12 satisfied its release-entry criterion and was ready for work entry until 10:30; recheck if a required input changes. No A.21 gate decision has yet been made.”

When another use must replay the check, add the exact WorkPlan, criterion, checking Work, input facts, result episteme, and reliance window. Add an A.21 sentence only if a distinct OperationalGate(profile) actually consumes declared checks and publishes its own decision.

#Source currentness

Before: “The source posture is good.”

After: “This review uses edition E7 as the accepted decision source. Recheck that use if the edition or the reviewed question changes.”

For automation or consequential reliance, also name the exact source-use relation, currentness result, use window, and the claim that must be reconsidered. The short sentence does not turn the source into evidence, assurance, gate passage, or FPF doctrine.

#Other direct repairs

• Evidence. Replace “evidence status incomplete” with “The current evidence path does not yet support reliance on claim C; obtain the missing calibration record and check again.” Add exact evidence and currentness references only when the receiving decision needs them.
• Publication. Replace “publication posture allows decision input” with “This publication exposes candidate input X for the decision; the decision rule still evaluates X.” Publication does not decide or assure by itself.
• Mathematical lens. Keep LensUseBoundaryValue in C.29 when its possible values and intended lens use are defined. State the practical result in ordinary words; the field does not establish evidence, assurance, release, or source authority.
• Temporal claim. Keep dynClaimPosture in C.27 when its values and temporal use are defined. Say which temporal claim is usable and for what purpose; the field does not upgrade its evidence or authority.
• Project-side state. Put review, dispatch, release, admission, or source-control status in the project record that carries it. A pattern may mention only the user-facing boundary needed for its own subject.

#Conformance checks

#Common mistakes

#Relations

The dependency and distribution detail belongs here, after the working method. A.19.SPR builds on E.10, E.10.ARCH, E.10.MOVE, A.19, A.3.3, A.2.5, A.15.5, C.2.2a, A.10, B.3, A.20, A.21, C.27, C.29, E.17, E.9.DA, E.21, and F.18. It coordinates with A.17, A.18, C.16, C.16.P, C.16.Q, A.6.P, C.2.P, C.30.P, E.8, E.19, and E.11 when those patterns define or test the recovered claim.

#Rationale

The problem is not the word state. The problem is a sentence that hides what has changed, what is being judged, or which rule makes the judgment meaningful. Recovering those facts first lets FPF keep short engineering language without creating a general status ontology.

Local fields such as LensUseBoundaryValue and dynClaimPosture remain useful when their object, possible values, and rule are clear. Broad phrases such as source posture, evidence posture, or release posture should instead become the direct sentence or project record the reader actually needs.

#A.19.SPR:End

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