Quality Improvement Loop Method

E.23 · Stable · Part E - The FPF Constitution and Authoring Guides

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.

Status: Core.

When the entry phrase is "loop engineering", "agent loop", "harness loop", or "improve this with an agent", treat the phrase as a recognition cue, not as an FPF kind. First recover the object version under improvement and the evaluation that can be rerun. If those cannot be named, this is not yet an E.23 use; name the live claim and send it to its direct governing pattern. Common exits are work, transformation-flow structure, evolutionary retention and publication, source use, refresh, gate-decision publication, and DPF framework authoring.

Relations

E.23builds onImprovement-Oriented Quality Evaluation Question Framing

E.23builds onEvaluation CharacteristicSpace Construction

E.23coordinates withFPF Pattern-Quality Evaluation CharacteristicSpace

E.23coordinates withDRR Decision-Adequacy Evaluation CharacteristicSpace

E.23coordinates withFPF Pillar-Adequacy Evaluation CharacteristicSpace

E.23coordinates withConstraint-Governed Unfolding Structure

E.23coordinates withCreativity‑CHR — Characterising Generative Novelty & Value

E.23coordinates withExplore-Exploit Live-Pool Governor

E.23coordinates withMulti‑Method Dispatcher & MethodFamily Registry

E.23coordinates withParity / Benchmark Harness

E.23coordinates withTelemetry-Driven Refresh & Decay Orchestrator

E.23explicit referenceU.Mechanism - Reusable Law-Governed Operation Declaration

E.23explicit referenceU.Episteme: Constitution, Empirical Grounding, and Edition Relations

E.23explicit referenceStructure and Structural Views (STRUCT-CAL)

E.23explicit referenceTransformation Flow Structure

E.23explicit referenceRole-Method-Work Alignment (Contextual Enactment)

E.23explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)

E.23explicit referenceParity / Benchmark Harness

E.23explicit referenceOpen-Ended Search Archive and Front Stewardship

E.23explicit referenceExplore-Exploit Live-Pool Governor

E.23explicit referenceMulti‑Method Dispatcher & MethodFamily Registry

E.23explicit referenceSoTA Harvester & Synthesis

E.23explicit referenceTelemetry-Driven Refresh & Decay Orchestrator

E.23explicit referencePrinciple-Framework Architecture Decision

E.23explicit referencePattern-Framework Relation and Edition Discipline

E.23explicit referenceFirst-Practical Entry and Pattern-Use Discoverability Discipline

E.23explicit referenceConstraint-Governed Transformation-Flow Unfolding Structure

E.23explicit referenceImprovement-Oriented Quality Evaluation Question Framing

E.23explicit referenceU.Work: Dated Performed Work Occurrence

E.23explicit referenceConstraint-Governed Unfolding Structure

E.23explicit referenceUnified Lexical Rules for FPF

E.23explicit referenceWording-Use Ontological Precision Restoration Architecture

E.23explicit referenceLocal-First Unification Naming Protocol

E.23explicit referenceOntology-First Plain Technical Rewriting

E.23explicit referenceCreativity‑CHR — Characterising Generative Novelty & Value

E.23explicit referenceDomain Principle Framework Package-Adequacy Evaluation CharacteristicSpace

E.23explicit referenceFPF Pattern-Quality Evaluation CharacteristicSpace

E.23explicit referencePattern Quality Gates: Review and Refresh Profiles

E.23explicit referenceProduction Work, Entity-Identity Inception, and Production Completion Recovery

E.23explicit referenceU.Transformation: Bounded Change Under Conditions

E.23explicit referenceProblematic-For Relation

E.23explicit referencePragmatic Utility and Value Alignment

E.23explicit referenceQ-Bundle: Authoring "-ilities" as Structured Quality Bundles

E.23explicit referenceQuality-Term Precision Restoration

E.23explicit referenceTask-family adaptation signature

E.23explicit referenceAgentic Tool-Use and Call Planning (C.Agent-Tools-CAL)

E.23explicit referenceProblem-to-Structure Architecturing Unfolding

E.23explicit referenceDecision Theory (Decsn-CAL)

E.23explicit referenceEvidence Graph Referring (C-4)

E.23explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)

E.23explicit referenceFlow Constraint Validity — Eulerian

E.23explicit referenceRelational Precision Restoration — Recovering Direct Relations from Under-Specified Claims

E.23explicit referenceEpistemic Precision Restoration

Content

Problem frame

Use E.23 when an object version will be improved through repeated passes under a declared object-under-improvement evaluation. The object can be a pattern, DRR, FPF corpus object, engineering quality object, naming candidate, OEE and NQD candidate, archive or front member, selected set, parity report, refresh report, or declared transformation result, if an exact evaluation supplies values and stop meanings for that object kind.

Not this pattern when one direct quality evaluation is enough. Use E.22 to frame one evaluation and then run the named object-under-improvement evaluation. Use A.19.ECS first if the needed evaluation characteristic space does not exist.

First useful move: name the object version under improvement, the exact evaluation that will re-evaluate it, the improvement aim, protected trade-offs, cost and risk account, and local stop condition. Here move is Plain instruction wording: it names no Move kind, method, plan, performed Work, or actual Transformation.

What goes wrong if missed: teams close discharge rows instead of improving quality, retry blindly, optimize visible values while damaging protected qualities, stop forever after a local all-5 result, or let a review recommendation become decision, work, evidence, selected-set publication, parity, or refresh by stealth.

What this buys in practice: each pass has a declared object version, an intended evaluation-result change, a rerunnable evaluation, protected trade-offs, and a stop or switch condition. Effort can then change substantive quality and stop when no non-dominated change is worth its cost, instead of merely producing more review state.

Primary EntityOfConcern in plain terms: the repeated quality-improvement method for one object version under one declared evaluation.

Problem

FPF often improves artifacts by repeated review, repair, and re-evaluation. The loop is useful only when the changed object is evaluated again by the same object-under-improvement evaluation or by a declared stronger one. Without that discipline, repeated passes become checklist closure, agentic retry, source citation, or process state.

The loop also avoids the maturity-ladder trap. A floor or all-5 result can close this loop under current use, comparison set, source state, and cost boundary; it is not proof that the object cannot improve under a new use, source, front, or payoff.

The loop also fails when an ordinal value becomes a work target. 5 is an assigned result after measurement, not an instruction to add apparatus until a 5 can be defended. Below-floor values return a repair proposal or intended-work claim; they do not establish that Work occurred. Above-floor improvement becomes a selected proposal when the frame selects it, but the target is a substantive content improvement: stronger positive action guidance, worked slice, case and countercase coverage, source-currentness carry-through, mature-content discharge, relation cleanup, deletion of displaced apparatus, split of overloaded content, or another named content gain. Stay at 4 or no proposal is admissible only after a by-value search finds no non-dominated content improvement worth its cost under protected qualities. A selected proposal becomes neither performed Work nor actual Transformation until those independently governed occurrences obtain.

A below-floor value, finding, improvement aim, or repeated-evaluation need is not by itself an actual Problem. If one improvement use relies on an actual Problem, cite one current C.22.PFR ProblematicForRelation occurrence with its actual-condition and criterion-applicability participants and its maximal continuous adverse-episode identity. Evaluation Work, result epistemes, evidence, and loop records may support a claim about that occurrence; they neither create nor split it.

Forces

Force	Tension
Improvement ambition vs cost	Exceptional improvement can be valuable while ordinary floor work stays affordable.
General adaptive methods vs specialized cycles	Broad loops scale, while specialized cycles can be cheaper when the characteristic space fits.
Feedback vs self-confirming retry	Feedback helps only when re-evaluation checks changed quality.
Operation hardening vs bureaucracy	Verification, memory, decomposition, and supervision are admitted only when their expected improvement effect justifies cost.
Visible improvement vs protected trade-offs	One coordinate can rise while use, source preservation, locality, or ecology worsens.
Proposal portfolio vs selector overread	Proposals can guide improvement without becoming selected results or work plans.

Solution

E.23 is the general method for repeated improvement of an object version under one current QualityEvaluationQuestionFrame and one QualityEvaluationUseDeclaration named by value. The exact governing evaluation pattern owns the evaluation. Any separately identified semantic U.Method supplies the way the evaluation is done and is enacted by the independently identified dated evaluation U.Work that performs it; the declaration's characteristic-space, Q-Bundle, rubric, review-profile, evidence-basis, and result-form descriptions constrain or interpret that evaluation. Each performed evaluation or improvement pass is one independently identified dated U.Work occurrence under A.15.1, with its own performer assignment, enacted method, extent, and containing system. Any returned value, separately constituted result episteme, changed object, and actual Transformation remain distinct: the returned value uses its exact A.6.1 result binding or direct evaluation-result relation; C.2.1 identifies the result episteme; and any Work-to-result or Work-to-change claim names its already-declared direct predicate and obtaining facts or remains at the exact missing-governor boundary.

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 governing-pattern-return continuations. That organization is one current A.22 constraint-governed unfolding structure; 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.

Local 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 direct governing 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 direct governing 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 publication is `G.5`.
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.

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 ordinary non-use boundary. E.23 reuses that frame; it does not move the consuming-use position into the declaration.
`QualityEvaluationUseDeclaration`	The E.22 `U.Episteme` that keeps evaluator assignment, governing 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 under one evaluation-use declaration and qualification window.
`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 governed by the selected restoration pattern.

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, referencing one independently identified dated U.Work occurrence
    evaluationApplicationRef?: U.EntityRef, referencing one exact A.6.1 application when that is the evaluation route
    evaluationResultBasisRef: U.EntityRef, referencing its exact A.6.1 result binding or direct evaluation-result relation under the governing 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, present only for one independently identified dated U.Work occurrence that actually happened
    changedObjectVersionRef?: U.EntityRef, present only when that exact changed version independently exists
    changedObjectVersionKindRef?: U.KindRef, paired with changedObjectVersionRef
    workResultOrChangePredicateRefs[]?: U.EntityRef, each referencing one exact declared Work-to-result/change predicate or A.6.1 result-binding predicate used by the basis
    workResultOrChangeGovernorRefs[]?: U.EntityRef, positionally paired with the predicate refs and each referencing that predicate's exact direct owner
    workResultOrChangeBasisRef?: U.EntityRef, referencing one exact obtaining direct Work-to-result/change relation occurrence, one exact filled local relation-bearing claim that names the Work, result or change, applicability or condition, and obtaining facts, or one exact A.6.1 result-binding occurrence
  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
  governingPatternReturnBoundaryRefs[]: U.EntityRef, each referencing one ImprovementLoopBoundaryCondition@Context
  loopDecisionReasonDescriptionRef: U.EpistemeRef, referencing one loop-decision-reason description
QualitySideEvaluationChangeClaim in U.ClaimGraph:
  qualityEvaluationUseDeclarationRef
  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-value refs and kinds are positionally paired; checked evidence-relation refs and kinds form a second positional pair. Within every evaluation pass, the dated Work, exact application when used, exact result binding or direct relation, result episteme, and evidence basis remain independently identified. Within every improvement pass, a changed-version ref and kind are paired only after that version exists; the selected proposal remains usable even while the Work and result/change positions are absent. workResultOrChangePredicateRefs and workResultOrChangeGovernorRefs are positionally paired and both are present whenever workResultOrChangeBasisRef is present. They expose predicate semantics and direct authority separately and may also remain present while the obtaining basis is absent; neither fills that basis. That basis resolves only to an exact obtaining direct Work-to-result/change relation occurrence, an exact filled local relation-bearing claim naming the Work, result or change, applicability or condition, and obtaining facts, or an exact A.6.1 result-binding occurrence. An A.15.PROD route identifies the exact applicable local claim, not the pattern or a generic [A.15.PROD](/generated/patterns/A.15.PROD) claim. When only a predicate, pattern, or other governor is known, retain the proposal, Work, changed object, and Transformation separately and return missing-governor[work-to-result/change] instead of inventing a generic relation.

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 separately governed relations or values. 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 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.

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, referencing one independently identified dated U.Work occurrence under A.15.1
    evaluationApplicationRef?: U.EntityRef, referencing one exact A.6.1 application when used
    evaluationResultBasisRef: U.EntityRef, referencing one exact A.6.1 result binding or direct evaluation-result relation
    evaluationResultEpistemeRef: U.EpistemeRef, referencing one separate result episteme under C.2.1
  improvementPassPositionRows[]:
    selectedNextActionProposalRef: U.EpistemeRef
    improvementWorkRef?: U.EntityRef, present only after one dated U.Work occurrence obtains
    changedObjectVersionRef?: U.EntityRef, present only after that exact version exists
    workResultOrChangePredicateRefs[]?: U.EntityRef, each referencing one exact declared Work-to-result/change predicate or A.6.1 result-binding predicate used by the basis
    workResultOrChangeGovernorRefs[]?: U.EntityRef, positionally paired with the predicate refs and each referencing that predicate's exact direct owner
    workResultOrChangeBasisRef?: U.EntityRef, referencing one exact obtaining direct Work-to-result/change relation occurrence, one exact filled local relation-bearing claim that names the Work, result or change, applicability or condition, and obtaining facts, or one exact A.6.1 result-binding occurrence
  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 under its direct governing pattern
  stopBoundaryRef: U.EntityRef, referencing one ImprovementLoopBoundaryCondition@Context
  governingPatternReturnBoundaryRefs[]: U.EntityRef, each referencing one ImprovementLoopBoundaryCondition@Context

ImprovementLoopUnfoldingStructure is a local [A.22.CGUS](/generated/patterns/A.22.CGUS) U.Structure specialization governed here for improvement-loop use. Its constituents are the independently identified values named above; its selected obtaining relations and guard claims keep their exact direct governors. 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 | governingPatternReturn | informationBasisSufficiency, a condition description, the affected object-version ref and exact kind, and a conditional receiving-pattern ref when the boundary is a governing-pattern return. Source currentness stays with G.11, selected-set publication stays with G.5, work stays with A.15, and evidence and assurance stay with their direct governing patterns. A return boundary ends or redirects this E.23 use; it does not make the receiving 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.

Loop method

For one quality-improvement loop:

Declare ObjectUnderImprovementRef, its exact kind and version, and one QualityEvaluationUseDeclaration; recover the current QualityEvaluationQuestionFrame when one already exists. Keep the declaration's evaluation performer assignment, exact governing evaluation pattern identity, optional semantic method, selected characteristic space, predicate or comparator, ClaimScope, quality-model descriptions, expected evidence basis, result-form description, and qualification window separate; keep the exact result-consuming work or decision in the question frame rather than in the declaration.
Declare ImprovementAim, declared floor or desired substantive evaluation-result change, protected trade-offs, cost and risk account, and local stop condition. Do not declare 5, all-5, or 5-defensible as the work target; name the content property to improve instead.
Reuse the exact current E.22 question frame, or use E.22 to open one for the first quality evaluation when no frame already binds the current purpose, scope, and result-consuming use.
Identify and run one dated evaluation Work occurrence under A.15.1. Keep its performer system, covering assignment, enacted method, temporal extent, and containing system distinct from the frame and descriptions. Name the exact evaluation application and result binding or the direct evaluation-result relation under the governing evaluation pattern; when a durable result claim is needed, identify one separate C.2.1 result episteme. For one FPF pattern version, that result has every E.21 coordinate, every ShortRationale, the PrecisionRestorationProfile, evidence basis, coordinate-specific payloads, and status. A loop record, profile pass, blocker summary, two-column table, or "no blockers" note is not a substitute.
Record row-atomic findings or proposal rows when work is returned. A step is closed only after its finding or proposal row is written; do not rely on memory or a later grouped summary. Each row is still an episteme about a proposed next action, not the action's performance, Work, or Transformation.
Select a proposal only as the next-action proposal. When an improvement is actually performed, identify one separate dated improvement Work occurrence with its performer system, covering assignment, enacted method, temporal extent, and containing system. Identify any actual U.Transformation independently under A.3.4. Connect a returned value, changed object, or that Transformation to the Work only through one exact obtaining basis: an A.6.1 result-binding occurrence, a direct Work-to-result/change relation occurrence, or a filled local relation-bearing claim that names the Work, result or change, applicability or condition, and obtaining facts. Name the declared predicate or predicates and their direct governors separately; an A.15.PROD branch cites its exact applicable local claim, not the pattern or a generic claim label. If that obtaining basis is missing, retain the proposal, Work, changed object, and Transformation separately and return the exact missing-governor blocker. Repair below-floor findings first. When exceptional improvement is requested, search coordinate-by-coordinate for substantive content improvements: better positive action guidance, a missing worked slice, case and countercase coverage, source-currentness carry-through, mature-content discharge, relation cleanup, deletion of displaced apparatus, split of overloaded content, or relocation of quality proof or process proof. Guards, boundary catalogues, relation menus, or quality proof added solely to make a higher value defensible are dominated changes, not improvements. A no-change closure is admissible only when the row cites its LoopEvaluationEvidenceBasis@Context and explains why no non-dominated content improvement is available under the protected trade-offs. When generation, selection, publication, parity, refresh, decision, planning, work, evidence, or assurance claims leave quality improvement, keep the pattern that governs that claim, relation, or boundary in the loop record or Relations. Do not let loop-method prose replace the object's positive content. For precision-restoration defects, use the selected restoration or governing pattern named by the evaluation: E.10, E.10.ARCH, F.18, F.19, or an object-specific pattern. Before closure, a bounded complete KindRestorationCheck states what kind, relation, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope were present before the edit and what kind, relation, current ontic slot, relation position, use relation, or claim kind, admissible use, and scope the changed text now carries when those items are live. No-op closure is admissible only as not triggered, ordinary prose, already satisfied, or blocker with its evidence basis; otherwise unchanged text remains a live finding. When another pattern governs the kind under repair, relation, claim, or position, cite that pattern; E.23 records the repair and reruns the evaluation, it does not duplicate the restoration algorithm.
Identify a later re-evaluation as another independently dated evaluation Work occurrence, not as a continuation field of the first Work. Re-evaluate the changed object version through the object-under-improvement evaluation, preserving that evaluation's coordinate set, evidence basis, result-row shape, short rationales, attention-discharge rows, and coordinate-specific payloads. Again name the exact application/result binding or direct evaluation-result relation and any separate result episteme.
Record what improved, what stayed floor-only, what was unchanged by value with its evaluation evidence basis, what became worse, and which rows were reclassified outside the evaluation. The before and after result epistemes remain distinct from both evaluation Work occurrences.
Decide stop, continue, switchMethodFamily, openNewFrame, or holdUntilInformationBasisSufficient. Keep current alternatives, exact guard or constraint claims, selected obtaining relation occurrences, selected continuation, stop, and governing-pattern returns in one admitted A.22 improvement unfolding structure. When transformation-flow membership is independently current, E.18/E.18.3 recognizes that same selected structure rather than another loop object. The decision and branch selection do not perform or authorize the next Work.
Leave a QualityImprovementLoopRecord sufficient for the next reader to replay the object versions, the QualityEvaluationQuestionFrame carried by its admitted unfolding structure, the QualityEvaluationUseDeclaration, selected proposal rows, independently identified evaluation and improvement Work occurrences, exact applications and result/change bases, actual LoopEvaluationEvidenceBasis@Context epistemes, result epistemes, applicable source-use and currentness result references, limitations, trade-offs, cost and risk, selected continuation, stop and return boundaries, and the loop decision with its reason.

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 ExpectedEvaluationResultChange@Context states a scale-qualified change worth its cost and risk. 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 closes this loop locally. It does not say that future development is impossible. A new use, Q component, source anchor, SoTA front, comparison set, affordability boundary, or higher-payoff proposal can open a later loop.

Treat the five decision values as current continuation dispositions, not as Work states. A branch is usable only when its A.22 guarded continuation cites the exact current guard or constraint claim and the already-obtaining relation occurrences that make that alternative admissible. A stop or governing-pattern return is a boundary until its direct owner establishes any stronger relation. Returning to A.15, E.22, G.11, G.5, or another named pattern neither performs Work nor creates that pattern's object.

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 ExpectedEvaluationResultChange@Context values, cost and risk, and protected trade-offs. Familiarity, automation, or current popularity is not enough.

Operation-family selection

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

one scale-qualified ExpectedEvaluationResultChange@Context;
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.

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 still evaluates end-to-end accepted-work cost:

AcceptedWorkCost ~= resource_cost + tool_and_instrument_cost + adaptation_attempt_cost + skilled_attention_cost + rework_and_delay_cost + risk_exposure - avoided_loss_value

This is not a hidden quality score. It is a prompt for cost and risk reasoning. resource_cost can include compute, materials, energy, consumables, occupied facilities, or another resource consumed by the declared work; the other terms are interpreted for the actual project rather than presumed to be software costs. If avoided loss is large, an expensive loop can be right. If the object is simple, a direct edit or adjustment, small repair, lower-cost performer, specialized cycle, or one-shot evaluation can be better.

Harness improvement is usually the first high-leverage intervention when it reduces blind retry: better frames, row shapes, test cases, source references, local tools, memory, verification, and stop conditions.

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, E.23 can change one object version or candidate to improve its evaluation result on declared Q coordinates. C.17, C.18, C.19, G.5, G.9, and G.11 keep authority over novelty, diversity, descriptors, distances, archive or front insertion, pool policy, selected-set publication, parity, and refresh.

Worked slices

Agent harness improvement from a loop-engineering request. A user asks to "build an agent loop that improves my local DPF seed." The E.23 entry is not the loop word; it is the recovered object and evaluation use: ObjectUnderImprovementRef = PersonalDevelopmentDPFSeed@v0.1; governingEvaluationPatternDescriptionRef = E.4.DPF.DA or E.21; the separate quality-model, expected-evidence-basis, and result-form refs are those declared by that pattern; and ImprovementAim = make the seed usable as a local first-entry framework without public-Core claims. The loop may change only the declared seed version, or a declared evaluation or harness slice that is itself the object under improvement. Source-use prompts, pattern-seed expansion, adversarial examples, or harness checks enter the loop only when the record states an ExpectedEvaluationResultChange@Context and a removal or stop condition for that declared slice. Selecting any of them still selects only a proposed next action. Each actual harness run or seed-editing pass is one independently identified dated A.15.1 Work occurrence. A returned evaluation value uses its exact A.6.1 binding or direct evaluation-result relation; a durable result claim is a separate C.2.1 episteme; and a changed seed version or Transformation is linked to the exact Work only by one exact obtaining direct relation occurrence, an exact filled local relation-bearing claim that names the Work, result or change, applicability or condition, and obtaining facts, or an exact A.6.1 result-binding occurrence. Its predicate and direct governor are named separately; an A.15.PROD route cites the exact applicable local claim rather than the pattern. Source-use decisions are G.2; source decay, edition change, and refresh orchestration are G.11; parity between harness variants is G.9; retained candidate variants are C.18 or C.19; selected-set publication is G.5; PFAD and PFR claims stay with E.4.PFAD and E.4.PFR. A change outside the declared slice opens that neighboring work; it is not one giant E.23 evolution loop.

Affordable floor evaluation. A pattern needs admission readiness. E.22 frames floorEvaluation; one independently dated evaluation Work applies E.21 to its complete coordinate set and returns its result through the exact evaluation application and binding or direct evaluation-result relation. If the result is admissible and no improvement aim is requested, E.23 stays closed. If an admission, refresh, landing, or release crossing is claimed, E.19 and the release process named by value still check the gate conditions; the E.21 status is necessary quality evidence, not the gate itself.

Pattern exceptional improvement. A pattern already passes floor but lacks worked slices and source-currentness. Use E.22 to frame optional exceptional improvement for named coordinates. E.22 returns proposal rows; selecting one row still does not perform it. The practitioner then applies E.23: search for substantive non-dominated content improvements, identify each actual repair pass as separate dated Work with its exact result or change basis, re-evaluate the changed pattern through a later E.21 evaluation Work and separate result episteme, check what became worse, and stop locally only when no worthwhile content improvement remains under the declared use. The loop may stop at 4, but only after the missing-exceptional opportunity has been searched and discharged by value; it is not a proof-building run toward all-5.

Physical prototype improvement. The object version is PumpAssembly@Prototype-3, kind U.System. Its QualityEvaluationUseDeclaration keeps the following positions distinct: a vibration-test engineer role assignment; the exact pump-vibration evaluation pattern identity; a steady-operating-point vibration evaluation method; an engineering Q-Bundle description and characteristic-space specification defining RMS vibration, efficiency, and manufacturability coordinates and scales; an expected-evidence-basis episteme naming calibrated test-bench measurements at declared operating points; and a result-form episteme describing the coordinate rows. The current QualityEvaluationQuestionFrame references that declaration and binds the same object version, selected characteristic space, predicate or comparator, ClaimScope, and qualification window to the exact engineering decision that will consume the result. One dated test-bench evaluation Work enacts the semantic method and uses one exact evaluation application or direct evaluation relation. Its returned value uses the exact result binding or relation; the current durable result claim remains a separate C.2.1 result episteme. An E.22 proposal describes an impeller-geometry change while its TradeoffProtectionSet@Context retains efficiency and manufacturability. The E.23 loop description carries an ExpectedEvaluationResultChange@Context with the current result, changeExpressionKind=expectedDirection, and expectedScaleDirection=decreaseOnScale. That proposal remains a proposal. Each actual machining and assembly occurrence for Prototype-4 is independently identified as A.15.1 Work; the link from that Work to the exact changed version or Transformation must be one exact obtaining direct relation occurrence, one exact filled local relation-bearing claim naming the Work, result or change, applicability or condition, and obtaining facts, or one exact A.6.1 result-binding occurrence. Its predicate and governor are recorded separately. An A.15.PROD branch cites its exact applicable local claim; A.15.PROD and A.3.4 remain governors of their own objects and do not themselves fill the basis. A later, independently dated evaluation Work must evaluate Prototype-4 on the same characteristic space and evidence basis, return another exact value or relation, and separately constitute any durable result episteme before a measured improvement claim obtains.

Three proposals remain three evaluated alternatives. Under that same evaluator assignment, evaluation method, quality model, and expected evidence basis, E.22 can return three exact CandidateImprovementProposalRow@Context values: change impeller geometry, change bearing-support stiffness, and add vibration isolation. The QualityImprovementLoopRecord cites all three rows without merging them into one repair summary or pretending that any was performed. Each row has its own ExpectedEvaluationResultChange@Context whose entityOfConcernRef names the pump-assembly version expected to change, whose prediction uses an admitted scale, and whose protected-trade-off membership remains separate, such as efficiency, mass, manufacturability, or service access. If comparable operating-point measurements are missing, the actual LoopEvaluationEvidenceBasis@Context names that unfilled position. None of the predictions selects a proposal: holdUntilInformationBasisSufficient states the comparability condition. A later pass may select only proposals whose expected change remains worth cost and risk after that position is filled; even then, actual improvement begins only with separately identified Work and its exact result or change basis.

DRR improvement. A DRR needs drafting adequacy for authoring across several selected pattern hosts. Use the coordinates supplied by E.9.DA, return row-atomic proposals, identify each actual decision-repair pass as dated Work only when it occurs, and re-evaluate the changed DRR through a separately identified E.9.DA evaluation Work and result. The improved object is still a decision record, not prewritten pattern prose.

NQD quality-side improvement. A generated candidate has declared Q components and a comparison set. E.22 returns proposal rows. E.23 may organize separately performed candidate-change Work and re-evaluation of Q; archive or front insertion, selected-set publication, parity, and refresh remain under the pattern that governs each claim and are not quality-loop decisions.

Bias annotation

This pattern biases FPF toward adaptive improvement with explicit re-evaluation. The bias is useful because many real objects improve only through feedback and revision.

The bias is bounded. One direct evaluation can close without a loop. Repetition is justified only by a scale-qualified ExpectedEvaluationResultChange@Context and acceptable cost and risk.

Conformance checklist

Check	Passing condition
`CC-E23-1`	Name the exact object version, exact object-under-improvement evaluation, one current `QualityEvaluationQuestionFrame`, and one `QualityEvaluationUseDeclaration` before claiming a changed evaluation result.
`CC-E23-2`	Reuse an E.22 or equivalent exact frame only when it binds the current object version, selected characteristic space, predicate or comparator, ClaimScope, result-consuming work or decision, purpose, qualification window, and non-use boundary; otherwise open a new frame.
`CC-E23-3`	Represent returned repair possibilities as row-atomic E.22 findings or proposal rows with closure tests; pair proposals selected for the next pass with scale-qualified `ExpectedEvaluationResultChange@Context` values. A grouped memory summary does not discharge skipped rows, and proposal selection does not establish performance.
`CC-E23-4`	Identify each evaluation pass as one dated A.15.1 Work occurrence and name its exact evaluation application/result binding or direct evaluation-result relation plus any separate result episteme. Re-evaluate the changed object version before claiming coordinate, status, `Q`, or front-relation change.
`CC-E23-5`	Record what became worse and protected trade-offs.
`CC-E23-6`	Continue only when a scale-qualified expected evaluation-result change and the cost and risk account support another pass.
`CC-E23-7`	Treat all-`5`, exceptional, or front-reaching results as local loop stops, not permanent maturity endings.
`CC-E23-7a`	Do not treat `5`, all-`5`, or `5-defensible` as a repair target. Repair below-floor results first. Exceptional-improvement work proceeds through non-dominated proposal rows that name the expected substantive content change, protected trade-offs, and cost and risk. A no-proposal or stay-at-current-value disposition is admitted only when it cites the `LoopEvaluationEvidenceBasis@Context` and explains why every plausible content improvement is dominated, unavailable, or outside the declared scope. Reject changes that add guards, relation catalogues, evidence theatre, or quality proof while reducing use, affordability, locality, or ecology.
`CC-E23-8`	When a neighboring claim appears during a loop, name the live claim and its direct governing pattern before continuing. `E.23` may cite that pattern in the loop record, but it does not absorb the neighbor's authority unless the neighbor's object version is itself the declared object under improvement.
`CC-E23-8a`	When the evaluation names a precision-restoration defect, apply the selected restoration or governing pattern named by that evaluation. For `E.21`, use its `PrecisionRestorationProfile` to decide whether the repair concerns word, head, or use precision (`E.10`, `E.10.ARCH`, `F.18`), phrase-level plain rewriting (`F.19`), or a governing-pattern repair. The repair row is not closed until it includes a `KindRestorationCheck`: kind, relation, current ontic slot, relation position, use relation or claim kind, admissible use, and scope before and after repair; or a `not triggered`, `ordinary prose`, `already satisfied`, or `blocker` disposition with its evidence-basis references.
`CC-E23-9`	Apply `E.10` to load-bearing loop names, status values, examples, stop conditions, and result wording introduced or repaired by the loop.
`CC-E23-10`	Preserve the named evaluation's evidence basis, result-row shape, short-rationale rule, attention-discharge rows, and coordinate-specific payloads in every re-evaluation.
`CC-E23-11`	If a practitioner entry phrase such as "loop engineering", "agent loop", or "harness loop" appears, lower it to object version plus object-under-improvement evaluation before opening `E.23`, or name the direct neighboring governing pattern and stop the `E.23` overread.
`CC-E23-12`	In agent or harness cases, state which slice the loop may change: the target object version, the evaluation, or the harness object. Any other slice becomes neighboring work under its own governing pattern, not implicit `E.23` scope.
`CC-E23-13`	Keep a selected next-action proposal, independently dated improvement Work, exact A.6.1 binding or direct Work-to-result/change relation, changed object or Transformation, later evaluation Work, and result episteme distinct. When a required direct governor is missing, retain the separately identified objects and the exact blocker; do not mint a generic Work-result relation.
`CC-E23-14`	Represent current alternatives, exact guards, selected obtaining relations, selected continuation, stop, and governing-pattern returns in one admitted A.22 unfolding structure. When transformation-flow membership is current, E.18/E.18.3 recognizes that same selected `U.Structure`; do not mint a parallel loop object. A visible cycle, record, structure, decision value, or branch is not enduring Work, context, authorization, or performance.
`CC-E23-15`	A low value, finding, floor miss, or improvement aim does not establish an actual Problem. Any actual Problem used by the loop resolves to one current C.22.PFR occurrence with its direct participants and temporal identity.

Common anti-patterns and repairs

Anti-pattern	Repair
Checklist closed, quality improved. Discharge count replaces re-evaluation.	Re-evaluate the changed object through one independently dated evaluation Work and its exact result route.
Loop result without evaluation form. The loop says the object improved but records only prose, applied rows, or values without the named evaluation's evidence basis.	Re-run the object-under-improvement evaluation in its declared result-row shape and keep its Work, application or direct result relation, result episteme, and evidence basis distinct.
Agentic retry as method law. Repetition continues without a scale-qualified predicted evaluation-result change.	Add `ExpectedEvaluationResultChange@Context`, cost and risk, trade-offs, and a stop or switch condition.
Operation-family creep. Verification, memory, supervision, or search is added everywhere.	Keep only operations that can change the evaluation result enough to justify cost.
Goodharted pass. Visible values rise while protected qualities worsen, or a non-`5` value is treated as a defect to be fixed by more apparatus.	Use trade-off inspection; apply `E.13` when the visible value is replacing the intended value; reject, delete, split, relocate, or hold dominated changes; continue searching for substantive content improvement when the improvement aim is still open; record `stay at current value` only when the `LoopEvaluationEvidenceBasis@Context` shows that no non-dominated content improvement remains.
Lexical substitution closure. A trigger word disappears, but the replacement narrows, widens, or changes the object kind; for example a graph-shaped method or workflow cue becomes a work sequence without a selected ontology decision.	Reopen the row, recover the pre-repair and post-repair kind through `E.10`, `F.19`, `F.18`, or the governing pattern, and leave the repair blocking if the kind cannot be preserved or explicitly changed by accepted decision.
Maturity-ceiling stop. All-`5` is treated as end of development.	Close this loop locally and record reopen conditions.
SoTA citation as self-assignment. Sources are cited as proof of frontier quality.	State source contributions and re-evaluate the composed result.
Loop engineering as ontology. A fashionable source phrase is treated as a new Core kind or as proof that all repeated activity is one improvement loop.	Use the phrase only as an entry cue; recover object version and evaluation, or send the live claim to its direct governing pattern. Common exits are work, gates, evolutionary retention and publication, source use, refresh, transformation-flow, and DPF governing patterns.
Proposal as performance. A selected E.22 proposal or `continue` decision is treated as if the repair happened.	Keep the proposal and selection claim epistemic. Identify actual improvement only after one dated A.15.1 Work occurrence and its exact result/change route obtain.
Cycle as Work or context. One record, dashboard, retry label, or visible arrow cycle is used as an enduring Work occurrence or ambient context container.	Recover one A.22 improvement unfolding structure with exact constituents, obtaining relations, guards, alternatives, stop, and returns; use E.18 only for an actual transformation-flow structure, and identify every performed pass independently under A.15.1.
Finding as actual Problem. A low coordinate, floor miss, or loop-entry need is treated as a Problem occurrence.	Keep the finding epistemic; cite C.22.PFR only when one actual condition and one criterion-applicability occurrence make the temporally identified `ProblematicForRelation` obtain.

Consequences

Consequence	Benefit	Cost
Repeated improvement is governed by one explicit improvement method and one current unfolding structure, while every performed pass retains its own dated Work identity.	FPF no longer relies on hidden authoring habits or one fictitious enduring loop occurrence.	A complete loop record names its object, evaluation, structure, independently identified Work and result routes, and boundaries.
Row discharge is separated from evaluated quality change.	Improvement claims become replayable.	The claim remains inadmissible until the changed object is re-evaluated through a separately identified Work and result.
General and specialized loops are comparable.	BLP can be applied without craft folklore.	Comparison is admitted with explicit cost, risk, and characteristic-space fit.
Exceptional stop remains local.	All-`5` or front-reaching closure no longer freezes future development.	The closure record includes its reopen conditions.

Rationale

The shared method is simple: select a proposed improvement, perform it only through independently identified dated Work, connect any returned value or changed object through an exact obtaining direct relation occurrence, an exact filled local relation-bearing claim with its Work, result or change, applicability or condition, and obtaining facts, or an exact A.6.1 result-binding occurrence while naming the predicate and direct governor separately, re-evaluate through a separate dated evaluation Work and result episteme, check trade-offs and cost, then stop, continue, switch method, open a new frame, or hold. A.22 carries the current guarded alternatives, selected continuation, stop, and returns; when transformation-flow membership is independently current, E.18/E.18.3 recognizes that same selected structure rather than a second loop object. Classical improvement cycles, agentic loops, fixed-performer optimization, MCDA, Goodhart, and OEE and NQD lines contribute useful operations and boundaries, but they do not replace this method or turn the cycle into enduring Work or context.

SoTA-Echoing

Claim	Exact source and status	Inherited contribution and limit	Local adoption and disciplined case
Repeated improvement needs an aim, explicit measures, tested changes, and learning from each pass; merely naming a cycle is insufficient.	Gerald Langley et al., The Improvement Guide: A Practical Approach to Enhancing Organizational Performance, 2nd ed. (Jossey-Bass, 2009), ISBN 9780470430880, retained historical Model-for-Improvement practice; Michael Taylor et al., Systematic review of the application of the plan-do-study-act method to improve quality in healthcare, BMJ Quality & Safety 23, 290-298 (2014), DOI 10.1136/bmjqs-2013-001862; Julie Reed and Alan Card, The problem with Plan-Do-Study-Act cycles, BMJ Quality & Safety 25, 147-152 (2016), DOI 10.1136/bmjqs-2015-005076.	Langley et al. contribute aim-measure-change questions and iterative tests. Taylor et al. and Reed/Card show that key iterative, prediction, data-use, and documentation features are often weakly implemented. The evidence is largely healthcare process improvement and does not establish one universal lifecycle.	E.23 requires a declared evaluation use, proposal or prediction, re-evaluation on the same quality model, evidence basis, trade-offs, and a stop or hold decision. The Affordable floor evaluation slice stays one-pass when no repeated improvement claim is live.
Formative feedback supports improvement only when the current condition, desired condition, and actionable next move remain connected.	D. Royce Sadler, Formative assessment and the design of instructional systems, Instructional Science 18, 119-144 (1989), DOI 10.1007/BF00117714; John Hattie and Helen Timperley, The Power of Feedback, Review of Educational Research 77(1), 81-112 (2007), DOI 10.3102/003465430298487. Both are retained historical education lineages.	The works support gap comparison and next-step feedback, not an FPF loop ontology, a selected work plan, or proof that a proposed change improved the object.	E.22 proposal rows and E.23 `ExpectedEvaluationResultChange@Context` keep current result, candidate change, predicted effect, and later measured result distinct. The Pattern exceptional improvement slice requires re-evaluation after applying proposals.
Reflection, self-feedback, action-observation coupling, and tree search are different adaptive mechanisms, not synonyms for one loop kind.	Noah Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, arXiv:2303.11366; Aman Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, arXiv:2303.17651; Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, arXiv:2210.03629; Andy Zhou et al., Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models, arXiv:2310.04406; John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, arXiv:2405.15793. These are retained 2022-2024 stepping stones.	Reflexion uses linguistic feedback memory, Self-Refine iterates self-feedback and output revision, ReAct interleaves reasoning and environment action, LATS adds tree search and environment feedback, and SWE-agent engineers a software-environment interface. Their benchmark gains do not imply that every retry changes an object version or satisfies E.23 comparability.	`RalphLikeGeneralAdaptiveFamily` is selected only when a declared object version is changed and re-evaluated. The Agent harness improvement slice sends performed execution, tool use, and work to their direct patterns rather than calling them one E.23 loop.
Current harness practice shows both useful operation families and failure from excessive structure.	Boyuan Wang et al., Harnesses for Inference-Time Alignment over Execution Trajectories, arXiv:2605.21516 (2026); Wenze Wang, Mehdi Hosseinzadeh, and Feras Dayoub, A Physical Agentic Loop for Language-Guided Grasping with Execution-State Monitoring, arXiv:2604.07395 (2026); Roxana Geambasu et al., Engineering Robustness into Personal Agents with the AI Workflow Store, arXiv:2605.10907 (2026). These are current preprints for distinct agent settings.	The first separates decomposition from guided execution and reports over-decomposition, over-pruning, and effective partial harnesses; the second contributes bounded physical monitoring, retry, escalation, and finite termination around one grasp primitive; the third proposes hardened reusable workflows to trade flexibility for robustness. None establishes a general-purpose FPF loop kind or says more harness is always better.	Operation families enter E.23 only with expected evaluation-result change, cost, failure mode, and stop or removal condition. The Agent harness improvement boundary keeps physical recovery, hardened workflow reuse, and object-version improvement as distinct claims.
A fixed performer can improve through bounded edits to an external method-description object while performer and optimizer remain distinct.	Yifan Yang et al., SkillOpt: Executive Strategy for Self-Evolving Agent Skills, arXiv:2605.23904 (2026), current preprint.	SkillOpt keeps the target model fixed while a separate optimizer makes bounded edits to one external skill document, accepts only held-out improvement, and keeps rejected-edit memory. Its evidence concerns text skills, selected benchmarks, models, and harnesses; it does not establish the same gains for arbitrary methods, physical systems, or roles.	`FixedPerformerObjectVersionUnderImprovementOptimizationFamily` keeps performer, mutable object, optimizer memory, validation evidence, and acceptance rule separate. The Agent harness improvement slice may use this family only when the skill or document version is the declared object under improvement.
Trade-off evaluation asks which coordinates improve and which worsen; domain-specific review methods are examples, not the universal ontology.	Xi Lin et al., Quality-Diversity Optimization as Multi-Objective Optimization, arXiv:2602.00478 (2026), current preprint; Haoxiang Qin et al., A survey on Quality-Diversity optimization: Approaches, applications, and challenges, DOI 10.1016/j.swevo.2025.102240 (2026), current survey; Rick Kazman, Mark Klein, and Paul Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004 (2000), retained historical software-architecture practice; David Manheim and Scott Garrabrant, Categorizing Variants of Goodhart's Law, arXiv:1803.04585 (2018), later proxy-overoptimization taxonomy.	QD/MOO supports set-valued multi-coordinate comparison; ATAM shows scenario-based exposure of architectural quality-attribute trade-offs but is software-architecture-specific and not current general evolutionary architecture; Goodhart variants warn that optimization pressure can invalidate a proxy.	Every pass records protected trade-offs and what became worse. The Physical prototype improvement and Three proposals slices preserve RMS vibration, efficiency, manufacturability, mass, and service access without turning any one coordinate into a universal score.
Proxy optimization and strategy surrogation are different reasons not to target all-`5` or evaluator-preferred apparatus.	Charles Goodhart, Problems of Monetary Management: The U.K. Experience (1975), retained historical monetary-control formulation; Donald T. Campbell, Assessing the Impact of Planned Social Change, Occasional Paper 8 (1976), retained social-indicator warning; David Manheim and Scott Garrabrant, Categorizing Variants of Goodhart's Law, arXiv:1803.04585 (2018), later taxonomy; Jongwoon Choi, Gary Hecht, and William Tayler, Lost in Translation: The Effects of Incentive Compensation on Strategy Surrogation, The Accounting Review 87(4), 1135-1164 (2012), peer-reviewed experimental evidence.	The common comparison question is whether stronger optimization of the visible measure still improves the intended value. The sources do not forbid measurement; they require attention to mechanism, behavior change, and proxy substitution.	E.23 forbids score-proof targeting, rejects apparatus-only changes as dominated, protects other qualities, and opens `E.13` when the visible target replaces intended value. The Goodharted pass repair is the direct boundary.
OEE and NQD improvement is relative to declared `Q`, comparison sets, and behavioral or descriptor spaces.	Lin et al., Quality-Diversity Optimization as Multi-Objective Optimization, arXiv:2602.00478 (2026), current preprint; Qin et al., A survey on Quality-Diversity optimization, Swarm and Evolutionary Computation 100:102240 (2026), DOI 10.1016/j.swevo.2025.102240, current survey.	The works support collections of high-performing alternatives and explicit descriptor spaces. They do not give E.23 authority over candidate generation, archive insertion, front maintenance, pool policy, or selected-set publication.	`NQDQualitySideImprovementFamily` changes and re-evaluates one declared object version on `Q`; the NQD quality-side improvement slice returns retention and publication claims to C.17-C.19 and G.5.
A synthesis claim should expose how each admitted source contributes and which synthesis method and limitations apply.	Joanne McKenzie and Sue Brennan, Cochrane Handbook for Systematic Reviews of Interventions, version 6.5 (2024), Chapter 12, is current evidence-synthesis guidance; FPF `G.2` and `G.11` are the current internal governors for source-use decisions and source currentness.	Chapter 12 requires the chosen synthesis method and limitations to be reported instead of using an unexplained narrative-synthesis label. Its healthcare evidence hierarchy and statistical methods are not imported into arbitrary FPF projects. FPF contributes source-use and edition-currentness relations across domains.	`SourceComposedResultClaim` is a claim-node form that relates the changed result to exact accepted source-use decisions and contribution descriptions. E.23 re-evaluates that result; it does not infer front reach from citation count or from the mere presence of several sources.

Relations

Pattern	Relation
`A.19.ECS`	Constructs or repairs an object-under-improvement evaluation when none exists.
`E.22`	Frames each quality evaluation through suffixless `QualityEvaluationQuestionFrame` and `QualityEvaluationUseDeclaration` epistemes and can return finding or proposal rows.
`E.21`	Supplies pattern-quality values for pattern-improvement loops.
`E.9.DA`	Supplies `DRR` decision-adequacy values for `DRR` loops.
`E.2.DA`	Supplies FPF Pillar-adequacy values for corpus-level loops.
`A.22.CGUS`	Governs the current improvement unfolding structure: exact constituents, already-obtaining relations, guards, admissible alternatives, selected continuation, stop, and governing-pattern returns. The structure, visible cycle, record, and slice perform no Work.
`A.15.1`, `A.6.1`, `C.2.1`, `A.3.4`, `A.15.PROD`	Govern each independently dated evaluation or improvement Work occurrence, exact operation application and result binding, separately constituted result episteme, independently identified actual Transformation, and any separately current production branch. E.23 mints no generic Work-result or Work-to-change relation.
`C.22.PFR`	Governs an actual Problem occurrence when one is used by an improvement claim; a finding, floor miss, evaluation need, or loop record does not establish its actuality or temporal identity.
`E.13`	Governs pragmatic utility and proxy-to-value alignment when loop targets, quality values, metrics, or review results become substitutes for the intended value.
`G.2`	Governs source-use and source-pack return before DPF seeds based on source-use records, admitted source publications, agent-practice claims, or source-composed improvement claims can be used as evidence.
`F.18`	Supplies durable-name evaluation for naming loops.
`C.25`, `C.16.Q`	Govern engineering quality bundles and quality-word precision repair.
`C.19.1`	Governs BLP and cost and risk comparison for method-family choice.
`C.22.1`, `C.24`	Govern durable task-family adaptation and tool-call planning when the loop makes those claims.
`C.17`, `C.18`, `C.19`, `G.5`, `G.9`, `G.11`	Govern OEE and NQD candidate characteristics, archive, front, pool, selected set, parity, and refresh.
`E.18`, `E.18.3`	When the exact selected A.22 improvement structure also satisfies transformation-flow membership and boundary conditions, recognize that same `U.Structure` as the current transformation-flow unfolding structure. A visible loop, method, record, or series of Work occurrences supplies neither membership nor a second TFS by shape.
`E.18.1`	Carries accepted problem-side records or generated seed records toward the next FPF relation, including DPF seed-to-hardening routes before a quality-improvement loop is ready.
`E.4.DPF`	Governs DPF authoring routes and publication carriers when a fast local framework seed is the object being carried toward use or admission.
`E.4.PFAD`, `E.4.PFR`	Govern framework architecture decisions and framework relation records; `E.23` may improve a declared artifact version but does not decide those framework slots.
`A.21`	Governs gate-decision publication; monitoring, retry, escalation, or a green harness state does not publish gate passage unless an `OperationalGate(profile)` gate-decision relation is present.
`C.32.P2S`	Uses improvement-loop results only when they reopen architecture problem-to-structure carry-through; E.23 still governs the loop record and re-evaluation.
`C.11`, `A.10`, `B.3`, `A.15`, `A.20`, `A.21`	Govern decision, evidence, assurance, work, gate, and release claims when a loop result is reused beyond quality improvement.
`E.10`, `A.6.P`, `C.2.P`, `F.18`	Repair load-bearing wording and names introduced by loop records.

E.23:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)

#Quality Improvement Loop Method

#About this pattern

#How to use this pattern

#Relations

#Content

#Problem frame

#Problem

#Forces

#Solution

#Local names and kind settlement

#Improvement Unfolding Structure Block

#Loop method

#Stop, continue, and reopen

#Method-family selection

#Operation-family selection

#Cost and BLP discipline

#Source-composed, OEE, and NQD improvement

#Worked slices

#Bias annotation

#Conformance checklist

#Common anti-patterns and repairs

#Consequences

#Rationale

#SoTA-Echoing

#Relations

#E.23:End

Quality Improvement Loop Method

About this pattern

How to use this pattern

Relations

Content

Problem frame

Problem

Forces

Solution

Local names and kind settlement

Improvement Unfolding Structure Block

Loop method

Stop, continue, and reopen

Method-family selection

Operation-family selection

Cost and BLP discipline

Source-composed, OEE, and NQD improvement

Worked slices

Bias annotation

Conformance checklist

Common anti-patterns and repairs

Consequences

Rationale

SoTA-Echoing

Relations

E.23:End