E.23:4 - Solution · fpf.tools

E.23:4 - Solution

E.23 guides repeated improvement of one object version under a current QualityEvaluationQuestionFrame and QualityEvaluationUseDeclaration. The evaluation pattern defines the evaluation; restoration and subject patterns supply the relevant rules or guidance. A pattern body or locator does not by itself establish a semantic U.Method or qualify as its description. Claim Method or MethodDescription identity only after A.3.1 and A.3.2 admit it.

When an evaluation or improvement pass is claimed as actual A.15.1 U.Work, recover every exact actual performer through A.13 and independently identify the occurrence, time, Method, and containing System through A.15.1. Add A.2.1 assignment-occurrence identity and F.6 only when the loop record or receiving use expressly represents precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. A proposed pass, intended performer, planned condition, or A.15.2 WorkPlan remains modal until its predicates obtain.

Keep a returned value, durable result episteme, changed object, and actual Transformation separate. Connect a returned value through its A.6.1 binding or the evaluation’s direct result relation. Connect Work to a result or change only through a declared direct relation or local claim that actually obtains; otherwise return the missing governor.

The repeated organization changes the object, re-evaluates the changed version through the same declared method and quality model, checks trade-offs and cost, and exposes admissible stop, continue, switch, new-frame, information-hold, branch, and subject-pattern-return continuations. When the receiving use needs its structure, admit that organization under A.22.CGUS through §4.2a; use E.18 only when an independently selected transformation-flow structure is actually the EntityOfConcern. Neither the method, record, visible cycle, nor selected continuation is an enduring Work occurrence or context container.

E.23:4.1 - Ordinary loop method

For one quality-improvement loop:

Name the exact object version and the evaluation that will judge it. Reuse the current QualityEvaluationQuestionFrame and QualityEvaluationUseDeclaration when they still fit the purpose and receiving use. Keep the evaluator, evaluation pattern or Method, characteristic space, evidence basis, result form, ClaimScope, and qualification window separate.
State the content change sought, protected trade-offs, cost and risk account, and local stop condition. Do not use 5, all-5, or 5-defensible as the target; say what should become better in practice.
Reuse the exact current E.22 question frame, or open one when no frame binds the current object, purpose, scope, and result-consuming work or decision.
Run the declared evaluation. When the evaluated object is one FPF pattern version, retain the complete E.21 result: every coordinate, ShortRationale, PrecisionRestorationProfile, evidence basis, coordinate payload, and status. A loop note, blocker summary, or “no blockers” statement is not a substitute. If dated evaluation Work is asserted, identify it and its result binding or direct result relation; keep any durable result episteme separate.
Record each returned finding or proposal separately. A grouped memory summary does not close skipped items, and a proposal remains a proposed next action rather than performed Work.
Select the next change. Selection does not perform it. When the account asserts dated improvement Work, identify that Work and connect it to a returned value or changed object only through an obtaining A.6.1 binding or declared Work-to-result or Work-to-change relation. If that relation is unavailable, keep proposal, Work, changed object, and Transformation separate and return the missing relation.

Repair below-floor findings first. Above the floor, prefer a substantive gain—such as clearer action, a missing case or countercase, current source support, restored predecessor content, cleaner relations, or a split of overloaded material. Do not add guards, catalogues, or quality proof merely to defend a higher score. Close with no change only after the evidence shows that no feasible non-dominated improvement remains worth its cost under the protected trade-offs.

For a precision-restoration defect, apply F.19 and open a restoration or subject pattern for an unresolved FPF-specific meaning. Claim a Method or MethodDescription only when A.3.1 and A.3.2 admit it. Keep locator, Method, description, performer, assignment, Work, result, and responsibility separate. Run one bounded KindRestorationCheck when the changed expression can alter FPF-governed meaning; otherwise F.19’s local revalidation completes the ordinary repair.
Re-evaluate the changed object as a separate pass through the same declared evaluation with comparable evidence and conditions. If the evaluation itself needs to change, use §4.1a before comparing values across that change. Keep the later Work, application or direct result relation, evidence, returned value, and result episteme distinct from the first pass.
Record what improved, what stayed at the floor, what was unchanged by value, what became worse, and which findings moved outside this evaluation. Compare the two result epistemes rather than treating the later pass as a continuation field of the first Work.
Decide stop, continue, switchMethodFamily, openNewFrame, or holdUntilInformationBasisSufficient. When later replay depends on alternatives and guards, use the conditional structure block below. A decision or selected continuation neither authorizes nor performs the next Work.
Leave an account that lets the next reader recover the object versions, evaluation, proposals, performed passes, result or change bases, evidence, trade-offs, cost and risk, continuation, stop and return boundaries, and the reason for the decision. Use the structured QualityImprovementLoopRecord only when a named replay, handoff, audit, or machine-facing use needs that form; otherwise a short result with the same recoverable facts is enough.

Stop here when this route answers the current use. Open the names, record schemas, and unfolding-structure block below only when a named receiving use depends on that added assurance detail.

E.23:4.1a - When the evaluation needs to change

Use this branch when a missed defect, false objection, harmful proposed repair, changed use or excessive evaluation cost gives reason to reconsider the evaluation. An ordinary object repair can keep using the existing adequate evaluation.

First identify what changed. A new object version, a new requirement, a different task population, a different measuring procedure and a different evaluator implementation can require different responses. Fixing an implementation error can preserve the intended evaluation while invalidating the results affected by that error. A threshold that varies with load under a fixed rule still uses that rule; it does not by itself change the evaluation.

Keep the evaluation meanings and comparison conditions stable within one comparison. To change them between cycles, use A.19.ECS:4.5: compare the old and proposed evaluations on independently grounded defect and admissible cases, inspect harmful repairs and full cost, and use a new independent case when known cases were used for tuning. Decide whether to adopt the change for a stated use, retain it on trial, revise it, reject it or keep the current evaluation. A stricter result or higher evaluator agreement is not the adoption criterion.

After adoption, name which earlier conclusions depend on the changed rule. Re-evaluate affected preserved cases where cross-evaluation comparison is needed; otherwise retain earlier results with their original scope. Declare a bridge when it is justified, and leave unlike values incomparable when it is not. New task populations and requirements create new questions without retroactively falsifying supported old answers.

Worked slice. A review evaluation rewards concise explanations but misses an omitted dependency that makes the instruction unusable. Adding the missing dependency improves the object under its existing usefulness requirement. Changing the evaluator so it notices that defect is a different proposal. Compare that evaluator with its predecessor on the defective text and a concise, fully usable alternative; reject a repair that makes every explanation longer without need. A new independently grounded case supports adoption beyond those development cases. Previously supported readability judgements remain scoped to their text and reading conditions; only conclusions depending on the missed dependency need reopening.

E.23:4.2 - Conditional names and kind settlement

Source and practitioner phrases such as “loop engineering”, “agent loop”, “harness loop”, “prompt loop”, and “workflow hardening loop” are entry phrases. Lower them into ObjectUnderImprovementRef, QualityEvaluationQuestionFrame, QualityEvaluationUseDeclaration, ImprovementAim, MethodFamilySelection, CostAndRiskAccount, and QualityImprovementLoopRecord, or else name the subject pattern for the live claim and leave E.23 closed.

Quick lowering map:

Entry cue	`E.23` use	Exit when this is the live claim
“Build a loop” or “loop engineering”	Ask which object version is being improved and which evaluation will be rerun.	If no object-version improvement claim is present, choose the subject pattern named by the live claim.
Agent retry, monitor, or escalation cycle	Use `E.23` only when the retry changes an object version and re-evaluation can show a changed result on declared coordinates.	Performed execution and work plans use the A.15 family; gate passage uses `A.21`; transformation-flow cycle structure uses `E.18`.
Harness engineering	The harness can be the object under improvement when its next version is evaluated against declared quality, cost, and risk conditions.	Running the harness is work; comparing harness variants is `G.9`; retaining variants is `C.18` or `C.19`; selected-set result declaration is `G.5`; for publication, use `E.17` for a source-backed face and return to source and `E.24.PUB` for the occurrence, form, carrier, audience, bounded use, and availability.
Fast DPF seed hardening	A local DPF seed, pattern seed, relation record, or source pack can enter `E.23` after the object version and evaluation are declared.	Source-use and source-pack return use `G.2`; source decay, edition change, and refresh use `G.11`; PFAD and PFR decisions use `E.4.PFAD` and `E.4.PFR`; first-entry publication uses `E.11` only when publication is current.

The next table names the local values used after this routing choice.

Local name	Kind and function
`QualityImprovementLoopMethod`	Repeated improvement `U.Method` for one object version under one declared evaluation use.
`ObjectUnderImprovementRef`	Exact `U.Entity` version being changed, paired with its exact `U.Kind`.
`QualityEvaluationQuestionFrame`	The E.22 `U.Episteme` that binds one exact object version and use declaration to the selected characteristic space, predicate or comparator, ClaimScope, exact result-consuming work or decision, evaluation purpose, qualification window, and any grounded non-use boundary required by E.22. E.23 reuses that frame; it does not move the consuming-use position into the declaration.
`QualityEvaluationUseDeclaration`	The E.22 `U.Episteme` that keeps any question-changing evaluator condition or intended-evaluator identity separate from the actual evaluator, assignment and dated Work, and keeps the evaluation pattern, optional semantic Method, selected characteristic space, predicate or comparator, ClaimScope, quality-model descriptions, evidence basis, result form, and qualification window distinct. E.23 reuses it; it does not define a second evaluation ontology.
`LoopEvaluationEvidenceBasis@Context`	`U.Episteme` whose EntityOfConcern is the exact object version evaluated in one loop pass. It describes the evidence values actually checked and missing evidence positions found for that pass and is distinct from E.22’s expected evidence-basis description.
`LoopEvaluationResultFormDescription`	`U.Episteme` describing the result-row form used for the current pass; normally the same form cited by the evaluation-use declaration.
`ImprovementAim`	Desired evaluation-result change. It names the intended quality change, not a value established by the repair itself.
`MethodFamilySelection`	Selected method family for the current object and evaluation.
`OperationFamilySelectionSet`	Optional operation-family set selected because its operations can change the evaluated result enough to justify cost.
`ObjectUnderImprovementEvaluationWorkRef`	Reference to one independently identified dated A.15.1 evaluation Work occurrence. The Work remains distinct from its application, returned value, result episteme, evidence, and judgment.
`ObjectUnderImprovementEvaluationResultRef`	Reference to one separately constituted result episteme whose claims state the evaluation result. The episteme is not the returned value; the exact A.6.1 result binding or direct evaluation-result relation remains separately identified.
`ImprovementPassWorkRef`	Reference to one independently identified dated A.15.1 Work occurrence that actually changes or attempts to change the object. Selection of a proposal supplies no such occurrence.
`CostAndRiskAccount`	Cost and risk account used to judge another pass or operation.
`ImprovementLoopDecisionValue`	Local closed value set `stop
`QualityImprovementLoopRecord`	`U.Episteme` whose EntityOfConcern is the exact starting object version for one bounded improvement-loop application. Its ClaimGraph relates that version to one admitted unfolding structure, selected next-action proposals, independently identified evaluation and improvement Work, exact result bases and result epistemes, changed versions, evidence bases, trade-offs, cost and risk, and the selected continuation and boundaries. It describes those objects and relations; it is not the method, performer, Work occurrence, changed object, or structure.
`QualitySideEvaluationChangeClaim`	Controlled claim-node form inside a `U.ClaimGraph`; it compares before and after evaluation results for named object versions on declared `Q` coordinates. Each result uses the evaluation-use declaration bound to its own object version; keep the evaluation criterion, scope, scale and qualification conditions comparable, or state the explicitly selected stronger evaluation.
`SourceComposedResultClaim`	Controlled claim-node form inside a `U.ClaimGraph`; it relates one changed-object result claim to exact accepted source-use decisions and each source contribution. It is neither the changed object nor a source-use decision.
`KindRestorationCheck`	Conditionally present precision-repair check required by the selected restoration predicate and its evaluation result.

LoopEvaluationEvidenceBasis@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the exact object version evaluated in this loop pass
  entityOfConcernKindRef: U.KindRef, referencing the exact kind of that object version
  claimGraph: U.ClaimGraph by value
  referenceScheme: U.ReferenceScheme by value
  editionId
  qualityEvaluationUseDeclarationRef: U.EpistemeRef, referencing one QualityEvaluationUseDeclaration about that object version
  checkedEvidenceValueRefs[]: U.EntityRef, each referencing one evidence value actually checked
  checkedEvidenceValueKindRefs[]: U.KindRef, each referencing the exact kind of the paired evidence value
  checkedEvidenceRelationRefs[]: U.EntityRef, each referencing one governed evidence relation
  checkedEvidenceRelationKindRefs[]: U.KindRef, each referencing the exact kind of the paired evidence relation
  unfilledEvidencePositionDescriptionRefs[]: U.EpistemeRef, each referencing one description of an unfilled evidence position
  qualificationWindowDescriptionRef: U.EpistemeRef, referencing one EvaluationQualificationWindow description

QualityImprovementLoopRecord <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the exact starting object version for this bounded loop application
  entityOfConcernKindRef: U.KindRef, referencing the exact kind of that starting object version
  claimGraph: U.ClaimGraph by value
  referenceScheme: U.ReferenceScheme by value
  editionId
  improvementUnfoldingStructureRef: U.EntityRef, referencing one admitted A.22 constraint-governed unfolding structure; when transformation-flow membership is current, this same selected U.Structure also satisfies E.18/E.18.3 rather than designating a second structure
  qualityEvaluationUseDeclarationRef: U.EpistemeRef, referencing one QualityEvaluationUseDeclaration
  selectedNextActionProposalRefs[]: U.EpistemeRef, each referencing one CandidateImprovementProposalRow@Context; selection does not establish performance
  evaluationPassClaims[1..*]:
    evaluationWorkRef: U.EntityRef, constrained to U.Work
    evaluationApplicationRef?: U.EntityRef, referencing one exact A.6.1 application when that is the evaluation route
    evaluationResultBasisRef: U.EntityRef, referencing its A.6.1 result binding or the evaluation-result relation defined by the evaluation pattern
    evaluationResultEpistemeRef: U.EpistemeRef, referencing one separately constituted result episteme
    loopEvaluationEvidenceBasisRef: U.EpistemeRef, referencing one LoopEvaluationEvidenceBasis@Context
  improvementPassClaims[]:
    selectedNextActionProposalRef: U.EpistemeRef, referencing one still-propositional E.22 row
    improvementWorkRef?: U.EntityRef, constrained to U.Work and present only after actual improvement Work obtains
    changedObjectVersionRef?: U.EntityRef, present only when that changed version exists independently of this record
    changedObjectVersionKindRef?: U.KindRef, paired with changedObjectVersionRef
    workResultOrChangePredicateRefs[]?: U.EntityRef, each referencing a declared Work-to-result or Work-to-change predicate, or an A.6.1 result-binding predicate used by the basis
    workResultOrChangePatternLocators[]?: U.EntityRef, positionally paired with the predicate refs and each referencing the subject pattern that defines that predicate
    workResultOrChangeBasisRef?: U.EntityRef, referencing either the obtaining Work-to-result or Work-to-change relation, a filled local claim that names the Work, result or change, applicable conditions and facts, or an A.6.1 result binding
  tradeoffProtectionSet: TradeoffProtectionSet@Context by value
  costAndRiskAccountDescriptionRef: U.EpistemeRef, referencing one cost-and-risk-account description
  loopDecisionValue: ImprovementLoopDecisionValue
  selectedContinuationClaimRef?: U.EpistemeRef, referencing the current branch-selection claim without turning it into Work
  stopBoundaryRef: U.EntityRef, referencing one ImprovementLoopBoundaryCondition@Context
  reconsiderationBoundaryRefs[]: U.EntityRef, each referencing one ImprovementLoopBoundaryCondition@Context
  loopDecisionReasonDescriptionRef: U.EpistemeRef, referencing one loop-decision-reason description
QualitySideEvaluationChangeClaim in U.ClaimGraph:
  beforeQualityEvaluationUseDeclarationRef and afterQualityEvaluationUseDeclarationRef
  beforeObjectVersionRef and afterObjectVersionRef
  beforeEvaluationResultRefs[] and afterEvaluationResultRefs[]
  evaluationCoordinateRefs[]
  qualificationWindowDescriptionRef

SourceComposedResultClaim in U.ClaimGraph:
  changedObjectVersionRef and changedObjectVersionKindRef
  resultClaimNodeRef
  acceptedSourceUseDecisionRefs[1..*]
  sourceContributionDescriptionRefs[1..*]

The two named claims are node forms inside the claim graph of a result or loop episteme; a table row or serialization may publish them but does not become the claim.

Checked evidence values stay paired with their kinds; evidence relations form a separate pair. Every actual Work reference points to an independently identified occurrence governed by the central §4 Work rule. A compact rendering may use only the omission allowed there.

For an improvement pass, the changed-version reference appears only after that version exists. The workResultOrChange... fields keep the declared predicate, its pattern locator, and the obtaining basis distinct. That basis must be an A.6.1 result binding, a direct Work-to-result or Work-to-change relation, or a local relation claim that names its participants, conditions, and obtaining facts. If only the predicate or locator is known, keep the proposal, Work, changed object, and Transformation separate and return a missing-governor finding for the intended Work-to-result or Work-to-change relation. An A.15.PROD route points to its applicable local claim rather than to the pattern as a generic claim. The two record epistemes follow C.2.1 identity: claim content, exact EntityOfConcern, and effective U.ReferenceScheme determine each episteme edition. The listed loop fields contribute to claim content; editionId designates an already distinguished edition but does not constitute it. Empirical grounding, viewpoint membership, claim scope, model-use structure, applicability, qualification, evidence currentness, and source currentness remain separate relations or values defined elsewhere. A change in one of them changes a record episteme only when its claim content, EntityOfConcern, or reference scheme is revised; carrier and support serialization alone change neither episteme. These records do not create quality values, project evidence, release state, selected-set result declaration, actual publication, parity, refresh, Work, Transformation, or proof of quality.

The retained @Context suffixes on support species such as LoopEvaluationEvidenceBasis@Context, CandidateImprovementProposalRow@Context, TradeoffProtectionSet@Context, and ImprovementLoopBoundaryCondition@Context are compatibility and retrieval spellings only. No suffix or context label supplies a container, participant, ClaimScope, applicability, or identity discriminator. The three identity-bearing interface names in this package are suffixless: QualityEvaluationQuestionFrame, QualityEvaluationUseDeclaration, and QualityImprovementLoopRecord.

E.23:4.2a - Conditional Improvement Unfolding Structure Block

Use this block when a named review or replay use relies on the improvement loop’s constraint-governed unfolding structure rather than only its method record. It keeps the proposal epistemes, predicted evaluation-result changes, independently identified pass Work and results, guarded alternatives, decision value, information-basis hold, stop, and neighboring returns exact instead of treating them as generic structural locations.

ImprovementUnfoldingStructureBlock:
  unfoldingStructureRef: U.EntityRef, referencing one ImprovementLoopUnfoldingStructure
  objectVersionUnderImprovementRef: U.EntityRef
  objectVersionKindRef: U.KindRef
  evaluationFrameRef: U.EpistemeRef, referencing one QualityEvaluationQuestionFrame or equivalent exact frame
  qualityEvaluationUseDeclarationRef: U.EpistemeRef, referencing one QualityEvaluationUseDeclaration
  currentEvaluationResultRefs[]: U.EpistemeRef under that evaluation pattern
  candidateRepairProposalRefs[]: U.EpistemeRef, each referencing one CandidateImprovementProposalRow@Context under E.22
  tradeoffProtectionSet: TradeoffProtectionSet@Context by value
  expectedEvaluationResultChangeRefs[]: U.EpistemeRef, each referencing one ExpectedEvaluationResultChange@Context
  evaluationPassPositionRows[]:
    evaluationWorkRef: U.EntityRef, constrained to U.Work
    evaluationApplicationRef?: U.EntityRef, referencing one exact A.6.1 application when used
    evaluationResultBasisRef: U.EntityRef, referencing an A.6.1 result binding or evaluation-result relation
    evaluationResultEpistemeRef: U.EpistemeRef, referencing one separate result episteme under C.2.1
  improvementPassPositionRows[]:
    selectedNextActionProposalRef: U.EpistemeRef
    improvementWorkRef?: U.EntityRef, constrained to U.Work and present only after one dated U.Work occurrence obtains
    changedObjectVersionRef?: U.EntityRef, present only after that version exists
    workResultOrChangePredicateRefs[]?: U.EntityRef, each referencing a declared Work-to-result or Work-to-change predicate, or an A.6.1 result-binding predicate used by the basis
    workResultOrChangePatternLocators[]?: U.EntityRef, positionally paired with the predicate refs and each referencing the subject pattern that defines that predicate
    workResultOrChangeBasisRef?: U.EntityRef, referencing either the obtaining Work-to-result or Work-to-change relation, a filled local claim that names the Work, result or change, applicable conditions and facts, or an A.6.1 result binding
  guardedContinuationRows[1..*]:
    exactGuardOrConstraintClaimRef
    selectedObtainingRelationOccurrenceRefs[]
    admissibleContinuationDescription
  loopDecisionValue: ImprovementLoopDecisionValue
  selectedContinuationClaimRef?: U.EpistemeRef
  unfilledInformationBasisPositionDescriptionRefs[1..*]?: U.EpistemeRef
  informationBasisSufficiencyConditionRef?: U.EntityRef, referencing one ImprovementLoopBoundaryCondition@Context
  evidenceRelationRefs[]?: U.EntityRef, each referencing one exact evidence relation occurrence with its subject-pattern locator
  stopBoundaryRef: U.EntityRef, referencing one ImprovementLoopBoundaryCondition@Context
  reconsiderationBoundaryRefs[]: U.EntityRef, each referencing one ImprovementLoopBoundaryCondition@Context

ImprovementLoopUnfoldingStructure is a local A.22.CGUS U.Structure specialization whose improvement-loop membership predicate is defined here. Its constituents are the independently identified values named above; its selected obtaining relations and guard claims keep their exact predicates, occurrence-identity rules, and defining ClaimGraphs. A position row, adjacency, or selected continuation creates none of them. When that exact selected structure additionally satisfies the transformation-flow membership and boundary conditions, E.18/E.18.3 recognizes the same U.Structure; do not manufacture a generic CGUS plus a second transformation-flow structure from reciprocal references. The organization is neither a root U-kind, enduring Work, context container, evidence, nor quality proof.

E.23 governs the coordinate-qualified prediction episteme:

ExpectedEvaluationResultChange@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the exact object version whose later evaluation result is predicted
  entityOfConcernKindRef: U.KindRef, referencing the exact kind of that object version
  claimGraph: U.ClaimGraph by value
  referenceScheme: U.ReferenceScheme by value
  editionId
  qualityEvaluationUseDeclarationRef: U.EpistemeRef, referencing one QualityEvaluationUseDeclaration about that object version
  evaluationCoordinateRef: U.EpistemeRef, referencing one governed evaluation-coordinate description
  coordinateScaleRef: U.EpistemeRef, referencing one scale description that admits results for that coordinate
  currentEvaluationResultRef: U.EpistemeRef, referencing one current result episteme under the declared evaluation use
  changeExpressionKind: ExpectedEvaluationChangeExpressionKindValue
  expectedScaleValueRef?: U.EntityRef, referencing one value admitted by coordinateScaleRef
  expectedScaleValueKindRef?: U.KindRef, referencing the exact kind of that scale value
  expectedScaleRangeRef?: U.EpistemeRef, referencing one range description on coordinateScaleRef
  expectedScaleDirection?: EvaluationScaleDirectionValue
  candidateRepairProposalRefs[]: U.EpistemeRef, each referencing one CandidateImprovementProposalRow@Context
  predictionBasisRefs[]: U.EpistemeRef, each referencing one prediction-basis episteme
  tradeoffProtectionSet: TradeoffProtectionSet@Context by value

ExpectedEvaluationChangeExpressionKindValue is expectedValue | expectedRange | expectedDirection. Exactly one of value, range, or direction is present according to that kind. An expected value includes its exact kind and is admitted by coordinateScaleRef; an expected range belongs to that scale. EvaluationScaleDirectionValue is increaseOnScale | decreaseOnScale | preserveWithinRange | enterDeclaredRange | leaveDeclaredRange. Free direction prose does not close this episteme. The episteme predicts a later re-evaluation result. Its listed prediction fields contribute to claim content; a new claim content, EntityOfConcern, or effective reference scheme yields another C.2.1 episteme edition. A changed grounding, viewpoint, applicability, qualification, source-currentness, carrier, or rendering relation does not by itself change the prediction episteme; revise its claims when that change alters the prediction. It is not an operation, move, transition, work occurrence, or proof of improvement.

ImprovementLoopDecisionValue is stop | continue | switchMethodFamily | openNewFrame | holdUntilInformationBasisSufficient. The hold value has non-empty unfilledInformationBasisPositionDescriptionRefs[] and an informationBasisSufficiencyConditionRef; other values leave both absent. Each description says which information-basis position is unfilled without pretending to reference an entity that does not exist. The sufficiency condition says what information would make continuation admissible. A decision value or selected-continuation claim neither authorizes nor performs the next action.

ImprovementLoopBoundaryCondition@Context carries boundaryConditionKind = stop | subjectAssertionReconsideration | informationBasisSufficiency, a condition description, the affected object-version ref and exact kind, the unresolved assertion ref, and an optional non-semantic candidateSubjectPatternLocator. Source currentness, selected-set result declaration, actual publication, Work, evidence, and assurance remain distinct subject assertions under their exact predicates. A reconsideration boundary ends or redirects this E.23 use; it makes no later Work, decision, or relation obtain.

A visible cycle such as “draft -> evaluate -> repair -> re-evaluate” may be useful before execution. While any constituent, obtaining relation, guard, expected result change, protected trade-off, selected continuation, decision value, stop, or return needed for the wider improvement CGUS remains unresolved, keep that presentation as a ProvisionalUnfoldingDemonstrationDescription@Context about the object version and proposed continuation set. It may guide slot discovery, but it is not yet a structure or a slice. Admit the wider ImprovementLoopUnfoldingStructure first. Only then may a separate DemonstrativeUnfoldingSlice@Context select one traversal through that admitted structure and name it as EntityOfConcern. Neither episteme is a QualityImprovementLoopRecord, performed Work, actual Transformation, or proof of improvement.

E.23:4.2b - How the conditional detail supports the loop

The names and schemas in 4.2 and the unfolding-structure block in 4.2a support the ordinary steps above; they do not define a second loop. Use them only when a receiving use must inspect exact record identity, evidence positions, independently admitted Work and result relations, guarded alternatives, or replayable structure. Otherwise keep the ordinary account and do not manufacture a record or structure merely to complete the schema.

For a structured use, the complete E.21 result belongs to step 4, proposal and Work separation to steps 5–7, before/after comparison to step 8, guarded continuation to step 9, and the replayable record to step 10. The central Work rule, direct result or change relation, and precision-restoration checks remain the same in both forms.

E.23:4.3 - Stop, continue, and reopen

Stop when the current object version meets the declared floor or improvement aim and no feasible non-dominated proposal remains worth its cost under the current use, comparison set, source state, and protected trade-offs. If the remaining proposal mainly makes a value easier to argue while adding apparatus or worsening use, affordability, locality, source preservation, or ecology, reject that proposal; continue searching for a substantive content improvement if the improvement aim is still open, and stop only with a by-value no-proposal disposition.

Continue only when at least one predicted evaluation-result change states a scale-qualified change worth its cost and risk. Use ExpectedEvaluationResultChange@Context when the conditional account in §4.2a is needed. Switch method when the current method family is not changing the evaluated result, is too costly, or no longer fits the evaluation. Use holdUntilInformationBasisSufficient only with non-empty unfilled-position descriptions and the sufficiency condition that would make continuation admissible.

An all-5, all-exceptional, current-front-reaching, or current-front-improving result is neither necessary nor sufficient to stop. Use the practical gain, protected trade-offs and attainable cost in the preceding rule. A stopped loop can reopen when a new use, Q component, source anchor, SoTA front, comparison set, affordability boundary or worthwhile proposal changes that judgement. If the object still fails its required use and no repair is feasible, choose replacement, withdrawal or another admissible continuation; stopping work does not make that object adequate.

Treat the five decision values as current continuation dispositions, not as Work states. When the admitted A.22 structure is used, a branch is usable only when its guarded continuation cites the exact current guard or constraint claim and the already-obtaining relation occurrences that make that alternative admissible. A stop or subject-assertion reconsideration is a boundary until an exact stronger predicate and current facts establish another relation. Naming A.15, E.22, G.11, G.5, or another subject pattern as a locator neither performs Work nor creates an object described there.

E.23:4.4 - Method-family selection

Method family	Use when
`PDSAorPDCAFamily`	Learning quality, baseline comparison, measuring instruments, or standardize-then-repeat action matter for the improvement loop.
`POOGIFamily`	The evaluation problem is throughput-shaped or constraint-shaped.
`OODAFamily`	Orientation quality and feedback under changing conditions affect the evaluation.
`RalphLikeGeneralAdaptiveFamily`	A broadly capable agent can improve the object through repeated specification, feedback, memory, and verification under `C.19.1` cost and risk discipline.
`FixedPerformerObjectVersionUnderImprovementOptimizationFamily`	The performer or harness stays fixed while the object version is edited and re-evaluated.
`NQDQualitySideImprovementFamily`	The evaluation supplies the `Q` side for a declared NQD and OEE comparison and loop changes seek a non-dominated change in evaluated `Q` coordinates.
`SoTAReachAndMaintainFamily`	Reaching or maintaining an externally assigned front depends on composing several accepted source or practice anchors.
`SpecializedObjectFamilyCycle`	A specialized method family fits a declared characteristic space and is BLP-compatible.

The selected family is justified by characteristic-space fit, the declared scale-qualified predicted evaluation-result changes, cost and risk, and protected trade-offs. Familiarity, automation, or current popularity is not enough.

E.23:4.5 - Operation-family selection

An operation family is selected only when the loop account names:

one scale-qualified predicted evaluation-result change;
failure mode addressed;
cost or risk reason;
protected trade-offs;
stop or removal condition.

Typical operation families are specification articulation, task decomposition, context refresh with carry-forward evidence, failure-context retry, verification against specification, memory or distillation, external critic or co-regulation, proposal portfolio use, search breadth or variants, bounded object-change budget, held-out evaluation, rejected-change memory, optimizer-memory separation, source-anchor contribution assignment, agent-tool-interface hardening, and task-family adaptation signature. They remain selectable only for the loop that justifies them.

E.23:4.6 - Cost and BLP discipline

C.19.1 governs the preference for broad, scale-amenable methods when safety, admissibility, and practical fitness are comparable. E.23 uses that preference but does not assume that accepted-work cost is one number. Compare material resources, tools and instruments, adaptation attempts, skilled attention, rework or delay, risk exposure, and avoided loss on their admitted scales. Keep the components separate, reject a dominated option, and use the declared project policy to choose or hold when no option dominates.

Net-cost arithmetic is permitted only after every term has been converted to one declared unit through an admissible conversion whose basis, uncertainty, and scope remain visible. Until then, avoided loss is a separate project estimate rather than a quantity subtracted from concrete burden. A justified avoided loss can still make an expensive loop preferable. For a simple object, a direct edit or adjustment, small repair, lower-cost performer, specialized cycle, or one-shot evaluation can remain the better option.

Choose harness improvement when a named defect in framing, tools, memory, verification or stopping causes avoidable retry and repairing it compares favourably with direct object repair or another available method. Apply C.11.DUA to preparation, recurring use, transition, independent judgement, maintenance and displaced useful work. Leave unavailable cost evidence unknown; a larger harness is not itself a gain.

E.23:4.7 - Source-composed, OEE, and NQD improvement

Accepted SoTA is the working external front only when assigned by the object-under-improvement evaluation, accepted source-use decision, or declared comparison set. E.23 can govern a loop that reaches, maintains, or improves relative to that front; it does not self-assign SoTA.

When an evaluation-result change depends on source use, source currentness, or a dated external front, the loop record cites the exact accepted result from G.2 or G.11, including the edition or date needed for replay. E.23 carries that reference; it does not make the source-use or currentness decision.

When several source anchors are used, the loop records each exact accepted source-use decision and each source contribution. The changed object’s result episteme then carries a SourceComposedResultClaim node in its U.ClaimGraph, relating the result claim to those decisions and contributions, and the changed object version is re-evaluated.

For NQD and OEE, use E.23 to change one object version or candidate and re-evaluate it on declared Q coordinates. Use C.17 for novelty, diversity, descriptors, and distances, C.18 for archive and front insertion, C.19 for pool policy, G.5 for selected-set result declaration, G.9 for parity, and G.11 for currentness and refresh. When audience availability is current, use E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability.