Quality Improvement Loop Method

E.23 · Stable · Method-description pattern · Normative unless marked informative · 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.

Type: Method-description pattern Status: Core Normativity: Normative unless marked informative

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 use its subject pattern for it. 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 withCharacterising Generative Novelty and 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.23outline childDeveloping Capability for a Named Work Family

E.23outline childCapability Access and Expression Differential Probe

E.23explicit referenceCultural Evolution and Cultural-Evolution Engineering

E.23explicit referencePractice Architecture Synthesis from Several Structures

E.23explicit referenceU.Method: Reusable Way of Doing with Explicit Applicability

E.23explicit referenceU.MethodDescription: Description Episteme for a Way of Doing

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

E.23explicit referenceThe Agential Role & Agency Spectrum

E.23explicit referenceU.SystemRoleAssignment - Contextual System-Role Assignment

E.23explicit referenceSystemRoleAssignment and Performed-Work Attribution Check

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

E.23explicit referenceTransformation Flow Structure

E.23explicit referenceSystem-Role–Method–Work Alignment

E.23explicit referenceGate Decisions from Independent Check Results

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 referenceMulti‑View Publication Kit

E.23explicit referenceOntic Description and Publication Discipline

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 referenceU.Mechanism - Reusable Law-Governed Operation Declaration

E.23explicit referenceImprovement-Oriented Quality Evaluation Question Framing

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

E.23explicit referenceConstraint-Governed Unfolding Structure

E.23explicit referenceCharacterising Generative Novelty and 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 referenceOntology-First Plain Technical Rewriting

E.23explicit referenceProblematic-For Relation

E.23explicit referenceUnified Lexical Rules for FPF

E.23explicit referenceLocal-First Unification Naming Protocol

E.23explicit referenceSystem-Role Kinds and Assignments

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

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 and Assurance Calculus

E.23explicit referenceConstraint Validity for Transformation Steps

E.23explicit referenceRecovering What “Role” Means in the Current Claim

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.

Use E.23.CAE first when the apparent object to improve remains ambiguous because a holder's capability may be outside its claimed envelope, unavailable through the current configuration, not selected as applicable, inaccessible or inactive, context-dependently unexpressed, unadapted, unenacted, or actually changed. That separate probe returns observations, a qualified disposition, surviving rivals, and candidate routes; it does not choose the object under improvement.

Use E.23.CDI instead when a separate applicable steering or choice result has made capability development current for one admitted holder System and named Work family, and the change must be checked in representative Work. That is a separate capability-development Method; E.23 points to its description without copying its actions. Use a population assessment when the question is a distribution across member capabilities, C.36 when generation, transmission, recognition, selection, retention, or loss across a cultural population is current, and C.32.MWA first only when the target-practice architecture itself must be recovered or compared.

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 result declaration, actual 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 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. 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.

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. If the change is performed, identify the improvement 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 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 and evidence basis, unless a stronger evaluation was explicitly selected. 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.

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 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 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 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 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:
  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 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.

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](/generated/patterns/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.

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.

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 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.

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 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.

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, 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.

Archetypal Grounding

Tell. Name the object version and evaluation, make one bounded change through separately identified Work, and re-evaluate the changed object before claiming improvement. Keep proposals, performed Work, the changed object or Transformation, the later evaluation, and its returned result distinct.

Show — agent harness improvement from a loop-engineering request. A user asks to improve a local DPF seed. The record names that seed version as the object under improvement, selects E.4.DPF.DA or E.21 for evaluation, and states the aim: make the seed usable for local first entry without public-Core claims. The loop may change only that seed or another explicitly declared evaluation or harness slice. Prompts, adversarial examples, and harness checks enter only when the record states the expected evaluation change and their removal or stop condition. Selection makes them proposals. Each actual harness run or seed edit is separate Work governed by the central §4 rule; returned values, durable results, changed versions, and Transformations stay separate and use their declared bindings or relations.

Use G.2 for source-use decisions, G.11 for refresh, G.9 for parity, C.18 or C.19 for retained variants, and G.5 for selected-set results. Use E.17 and E.24.PUB for publication, and E.4.PFAD or E.4.PFR for their respective claims. A change outside the declared slice opens that neighboring work; it does not enlarge one E.23 loop without a new boundary. Affordable floor evaluation. E.22 frames a floor evaluation; the evaluator applies E.21 to every coordinate and returns the result through the declared application binding or result relation. If that evaluation is recorded as dated Work, the central §4 rule applies. If the result is admissible and no improvement aim was requested, E.23 stays closed. Any admission, refresh, landing, or release claim still uses its own E.19 or release gate; the E.21 result is quality evidence, not the gate.

Pattern exceptional improvement. A pattern already passes the floor but lacks worked slices and source-currentness. Use E.22 to frame optional improvement for those named coordinates. Selecting a proposal does not perform it. Add the useful worked case or refresh the source-bound rule, identify the repair pass as Work only if that dated occurrence is asserted, and re-evaluate the changed pattern through a later E.21 pass with its own result. Check what became worse. Stop at 4 when no worthwhile content improvement remains under the declared use; do not add apparatus merely to defend all-5.

Show again — physical prototype improvement. The object is PumpAssembly@Prototype-3. Its evaluation declaration states any evaluator condition that changes result admissibility and keeps the vibration evaluation pattern and Method, Q-Bundle and characteristic-space descriptions, expected calibrated evidence, and result form distinct. The question frame binds those values to the engineering decision that will consume the result.

A test-bench measures Prototype-3 vibration. If this evaluation is asserted as dated Work, the central §4 rule applies. Its returned vibration value uses the evaluation's binding or result relation; any durable result claim is a separate episteme. E.22 then proposes an impeller-geometry change while protecting efficiency and manufacturability. The proposal is not performance.

Actual machining and assembly produce Prototype-4 through separately identified Work. Link them to the changed version or Transformation only through an obtaining A.6.1 binding, Work-to-result relation, Work-to-change relation, or applicable A.15.PROD local claim. A later vibration evaluation uses the same characteristic space and evidence basis before any measured-improvement claim obtains; each asserted Work occurrence follows the central §4 rule. Three proposals remain three evaluated alternatives. Under the same evaluation use, 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 without merging them or pretending that any was performed. Each has its own ExpectedEvaluationResultChange@Context for the pump-assembly version and keeps protected trade-offs such as efficiency, mass, manufacturability, and service access separate. If comparable operating-point measurements are missing, the actual LoopEvaluationEvidenceBasis@Context names that gap and holdUntilInformationBasisSufficient states the comparability condition. A later pass may select only proposals still worth their cost and risk; actual improvement begins with separately identified Work and an obtaining 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, repair the decision, and re-evaluate the changed DRR through a separate E.9.DA pass and result. Identify each repair or evaluation as dated Work only when that occurrence is asserted, using the central §4 rule. 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. An E.22 application returns proposal rows. Use E.23 to organize candidate changes and later re-evaluation of Q; apply the central §4 Work rule only to actual performed passes. Use the direct definitions and tests for archive or front insertion, selected-set result declaration, publication, parity, and refresh. None is a quality-loop decision.

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.

Scope: limited. The pattern covers repeated improvement of one declared object version under one rerunnable evaluation. It is not a universal account of change, learning, capability development, cultural evolution, publication, release, or project authorization; use the subject pattern for those claims.

Lens	Declared bias and check
Gov	Favors an explicit evaluation, protected trade-offs, and a local stop or switch condition. Keep evaluation evidence separate from the decision, gate, publication, or release that may later use it.
Arch	Favors one bounded object-under-improvement loop with named exits to specialized Methods and neighboring patterns. Do not let the loop absorb capability development, cultural evolution, DPF authoring, archive, selection, parity, or refresh architecture.
Onto-Epist	Favors keeping a proposal, selected continuation, performed Work, changed object or Transformation, later evaluation, evidence, and result episteme distinct. Completion or a better score alone establishes none of the neighboring claims.
Prag	Favors rerunnable evidence and non-dominated improvement under cost, risk, and protected qualities. For a cheap one-pass question, a direct evaluation is preferable to maintaining a loop.
Did	Favors an ordinary first move and unlike worked cases before formal loop records. Loop language can invite readers to mistake a visible cycle for enduring Work or context, so the grounding and anti-patterns show the distinctions in use.

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`	Every asserted evaluation or improvement `U.Work` first recovers each exact actual performer through A.13, then uses A.15.1 to identify the occurrence, time, Method, and containing System independently. Add A.2.1 and F.6 only when the record or receiving use expressly represents precise assignment-bound attribution; their absence or failure leaves the Work intact. Then name the evaluation application and result binding or direct result or change relation, plus any separate result episteme. Re-evaluate the changed object 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 subject 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`	For a precision-restoration defect, apply F.19 as guidance and open a subject pattern only for unresolved FPF-specific meaning; claim Method or MethodDescription only after A.3.1 and A.3.2 admit it. Apply `CC-E23-4` only when actual repair Work is asserted. Consume E.21's compact `PrecisionRestorationProfile` when that evaluation is active. Require one bounded `KindRestorationCheck` when the changed expression can alter the object, kind, relation, slot or use position, claim kind, admissible use, or scope; otherwise F.19's local revalidation completes the ordinary repair.
`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, required result summaries, and coordinate-specific payloads in every re-evaluation. For E.21, consume the compact `PrecisionRestorationProfile` under E.21:4.3a.
`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 subject 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 subject pattern, not implicit `E.23` scope.
`CC-E23-13`	Keep the selected proposal, actual improvement Work governed by `CC-E23-4`, its result or change relation, changed object or Transformation, later evaluation pass, and result episteme distinct. When a required relation has no governor, retain those objects and the blocker; do not mint a generic Work-result relation.
`CC-E23-14`	Represent current alternatives, exact guards, selected obtaining relations, selected continuation, stop, and subject-assertion reconsideration conditions 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 How to Avoid Them

Anti-pattern	Repair
Checklist closed, quality improved. Discharge count replaces re-evaluation.	Re-evaluate the changed object and apply `CC-E23-4` when dated Work is asserted.
Loop result without evaluation form. The loop says the object improved but retains no evidence in the declared evaluation form.	Restore that result form and evidence basis, then apply `CC-E23-4` to any dated Work claim.
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 subject 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 use its subject pattern for the live claim. Common exits are work, gates, evolutionary retention and publication, source use, refresh, transformation-flow, and DPF subject patterns.
Proposal as performance. A selected proposal or `continue` decision is treated as if the repair happened.	Apply `CC-E23-13`: keep selection epistemic until separate Work and an obtaining result or change relation exist.
Cycle as Work or context. A record, dashboard, retry label, or visible arrow cycle is treated as enduring Work or ambient context.	Apply `CC-E23-14`: recover the conditional structure only when needed, and identify each asserted performed pass separately.
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 follows one explicit improvement method and one current unfolding structure, while each performed pass retains its own dated Work identity and attribution under `CC-E23-4`.	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; connect any returned value or changed object through its direct relation or A.6.1 binding; then re-evaluate through a separate pass and result. CC-E23-4 supplies the dated-Work account whenever either performed pass is asserted as Work. Check trade-offs and cost, then stop, continue, switch method, open a new frame, or hold. A.22 carries the guarded alternatives, selected continuation, stop, and returns; when transformation-flow membership is independently current, E.18 and E.18.3 recognize that 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

SoTA here means the current best-known problem-solving practice for the stated question, not the newest, most official, or most familiar source. The comparison below is current to 2026-08-19. Lineage, bounded current research, internal governing dependencies, and rejected transfers are named as such.

Practice question	Exact source and status	Selected payload and limit	Source-use decision, receiving locus, qualification, and reopen
What must a repeated improvement pass expose so that it produces learning rather than merely naming a cycle?	Gerald Langley et al., The Improvement Guide, 2nd ed. (2009), retained Model-for-Improvement lineage; 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 (2014), DOI 10.1136/bmjqs-2013-001862; Julie Reed and Alan Card, The problem with Plan-Do-Study-Act cycles, BMJ Quality & Safety 25 (2016), DOI 10.1136/bmjqs-2015-005076; D. Royce Sadler, Formative assessment and the design of instructional systems, Instructional Science 18 (1989), DOI 10.1007/BF00117714; John Hattie and Helen Timperley, The Power of Feedback, Review of Educational Research 77(1) (2007), DOI 10.3102/003465430298487. The last two are retained formative-feedback lineage.	The sources contribute aim, explicit measures, prediction or proposal, tested change, comparison with the prior result, learning, and the connection among desired condition, current condition, and next move. Their healthcare and education evidence establishes neither a universal lifecycle nor FPF ontology or improvement.	Adapt as lineage — reason: the common learning structure changes the E.23 action, while the named domain methods do not dominate current cross-domain practice. Receiving loci: E.23:4.1 steps 1, 3, 7–10; Affordable floor evaluation; Pattern exceptional improvement. Qualification/currentness: retained for this structure, not as present-front authority. Reopen: comparative evidence overturns the learning structure, or E.23 changes its proposal, re-evaluation, or stop action.
When does a specialized improvement-cycle family fit better than a general adaptive loop?	Theory of Constraints Institute, Five Focusing Steps (`https://www.tocinstitute.org/five-focusing-steps.html`), living institutional explanation of POOGI; John R. Boyd, The Essence of Winning and Losing (1996 briefing), retained OODA lineage.	POOGI contributes constraint selection, throughput-shaped improvement, and attention to inertia after a constraint shifts. OODA contributes orientation and feedback under changing external conditions. Neither source makes every quality problem a constraint or makes loop speed, cadence, or action volume a quality result.	Adapt as lineage — reason: each branch supplies a useful selection discriminator without supplying a universal method. Receiving loci: `POOGIFamily` and `OODAFamily` in E.23:4.4. Qualification/currentness: living explanation and historical lineage, not current SoTA for all improvement. Reopen: either family is used outside its stated discriminator, or current comparative practice supplies a better branch at comparable effort.
Which repeated-agent and harness mechanisms warrant bounded use rather than one generic “agent loop”?	Thoughtworks Technology Radar Vol. 34, Ralph loop (2026-04-15, `Assess`), current external-technique signal; Ralph CLI, Ralph loop (`https://ralph-cli.dev/docs/core-concepts/ralph-loop/`), and Wiggum.dev, The Loop (`https://wiggum.dev/concepts/the-loop/`), implementation/rationale sources; Noah Shinn et al., Reflexion (arXiv:2303.11366), Aman Madaan et al., Self-Refine (arXiv:2303.17651), Shunyu Yao et al., ReAct (arXiv:2210.03629), Andy Zhou et al., LATS (arXiv:2310.04406), and John Yang et al., SWE-agent (arXiv:2405.15793), retained stepping stones; Boyuan Wang et al., Harnesses for Inference-Time Alignment over Execution Trajectories (arXiv:2605.21516), Wenze Wang et al., A Physical Agentic Loop for Language-Guided Grasping with Execution-State Monitoring (arXiv:2604.07395), and Roxana Geambasu et al., Engineering Robustness into Personal Agents with the AI Workflow Store (arXiv:2605.10907), current 2026 preprints in distinct settings.	The combined branch contributes fresh-context work against a specification, feedback memory, action–observation coupling, decomposition versus guided execution, partial-harness and over-structuring limits, bounded physical monitoring/retry/escalation, finite termination, and the flexibility–robustness trade-off of hardened workflows. It does not establish convergence by repetition, a general FPF loop kind, or that more harness is better.	Adapt and combine — reason: Thoughtworks supplies a current practice signal, the 2026 papers supply distinct mechanisms and failure limits, and the older papers remain mechanism lineage. Reject as load-bearing current evidence: Ralph CLI and Wiggum documentation remain implementation/rationale only. Receiving loci: `RalphLikeGeneralAdaptiveFamily`, E.23:4.5, and Agent harness improvement. Qualification/currentness: primary official and arXiv sources checked 2026-08-19; evidence remains setting- and benchmark-bound. Reopen: the Radar posture or cited papers materially change, or comparative evidence changes the mechanism, cost, or stop choice.
When do an extra supervisor or accumulated search memory improve the loop rather than add apparatus?	Zeda Xu, Nikolas Martelaro, and Christopher McComb, Supervising Ralph Wiggum / CRDAL (arXiv:2603.24768v2, 2026-05-07), current engineering-design research signal; Yanlong Wang et al., FactorMiner (arXiv:2602.14670v1, 2026-02-16), current financial-alpha-search research signal.	CRDAL contributes metacognitive co-regulation when fixation, underexploration, or expensive design mistakes are live. FactorMiner contributes retrieve/generate/evaluate/distill, modular skills, experience memory, and reduced redundant search in a large comparable search space. Neither supports a universal supervisor, financial-alpha objectives, or automatic transfer to every object.	Adapt as two domain-bounded branches — reason: the operation cues are useful only when E.23 can name the corresponding risk or comparable search. Receiving loci: E.23:4.5 operation-family selection, E.23:4.6 cost/risk discipline, and Agent harness improvement. Qualification/currentness: current preprints for engineering design and financial alpha, not general improvement evidence. Reopen: either paper changes materially, a comparative source dominates its cue, or E.23 begins using the domain objective as a general quality value.
When may a fixed performer improve by changing one external method-description object?	Yifan Yang et al., SkillOpt: Executive Strategy for Self-Evolving Agent Skills (arXiv:2605.23904v2, 2026-05-25), current preprint.	SkillOpt keeps the target model fixed while a separate optimizer makes bounded add/delete/replace edits to one external skill document, accepts only held-out improvement, and keeps rejected-edit and optimizer memory separate. Its benchmark results do not transfer automatically to arbitrary Methods, physical systems, or work-facing system-role kinds and assignments.	Adapt — reason: the fixed-performer, mutable-object, bounded-edit, held-out-acceptance split directly sharpens an E.23 family without importing the optimizer as FPF method law. Receiving loci: `FixedPerformerObjectVersionUnderImprovementOptimizationFamily`, `BoundedObjectChangeBudget`, held-out re-evaluation, and Agent harness improvement. Qualification/currentness: current preprint, limited to its models, benchmarks, skill documents, and harnesses. Reopen: the paper changes materially or stronger comparable evidence changes the held-out acceptance or bounded-edit rule.
How should several quality coordinates and OEE/NQD alternatives be compared without turning one score or algorithm into authority?	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, Swarm and Evolutionary Computation 100:102240 (2026), DOI 10.1016/j.swevo.2025.102240, current survey; Rick Kazman, Mark Klein, and Paul Clements, ATAM (CMU/SEI-2000-TR-004, 2000), retained software-architecture lineage.	QD/MOO contributes set-valued multi-coordinate comparison and explicit behavior or descriptor spaces. ATAM contributes scenario-based exposure of quality-attribute trade-offs. These sources do not supply one universal scalar, an FPF archive/front policy, or authority over candidate generation, retention, selection, parity, refresh, or publication.	Adapt — reason: set-valued and scenario-visible trade-offs support non-dominated choice while direct neighbours retain their own decisions. Receiving loci: E.23:4.1 steps 8–9, Physical prototype improvement, Three proposals, and NQD quality-side improvement; C.17–C.19/G.5/G.9/G.11 remain the exits. Qualification/currentness: QD sources are current for QD/MOO; ATAM is domain lineage. Reopen: a current QD overview dominates these payloads, or E.23 starts defining a neighbour-owned archive, front, pool, selection, parity, or refresh rule.
When does optimization of a visible measure cease to improve the intended value?	Jacek Karwowski et al., Goodhart's Law in Reinforcement Learning (ICLR 2024), and Thomas Kwa, Drake Thomas, and Adrià Garriga-Alonso, Catastrophic Goodhart: regularizing RLHF with KL divergence does not mitigate heavy-tailed reward misspecification (NeurIPS 2024), current narrow proxy-risk anchors; Charles Goodhart, Problems of Monetary Management: The U.K. Experience (1975); Donald T. Campbell, Assessing the Impact of Planned Social Change, Occasional Paper 8 (1976); David Manheim and Scott Garrabrant, Categorizing Variants of Goodhart's Law (arXiv:1803.04585, 2018); and Jongwoon Choi, Gary Hecht, and William Tayler, Lost in Translation: The Effects of Incentive Compensation on Strategy Surrogation, The Accounting Review 87(4) (2012), retained monetary, social-indicator, taxonomy, and strategy-surrogation lineage or evidence.	The sources distinguish proxy misspecification, optimization pressure, behavior change, heavy-tailed reward error, and strategy surrogation. They do not forbid measurement, predict every failure, or make RL/RLHF results a general project-value model.	Adapt and combine — reason: the 2024 papers provide current domain-bounded mechanisms while the older sources preserve distinct cross-domain failure explanations. Receiving loci: protected trade-offs, E.23:4.3 stop, Goodharted pass, and the `E.13` exit. Qualification/currentness: the current anchors are narrow RL/RLHF results; older sources remain lineage or bounded experimental evidence. Reopen: stronger current proxy-risk evidence changes a used mechanism, or E.13's intended-value boundary changes.
How should a source-composed improvement claim expose what each source contributes?	Joanne McKenzie and Sue Brennan, Cochrane Handbook for Systematic Reviews of Interventions, version 6.5 (2024), Chapter 12, current evidence-synthesis reference; FPF `G.2` and `G.11`, current internal governing dependencies for source-use decisions and source currentness.	Chapter 12 contributes disclosure of the selected synthesis method and limitations. FPF supplies the cross-domain decision and currentness rules. Cochrane's healthcare evidence hierarchy and statistical methods are not imported, and the broad synthesis of cycle, agent, trade-off, proxy, and OEE/NQD lines remains rationale rather than independent current evidence.	Adapt Chapter 12 for transparent contribution and limitation reporting; adopt as governing dependencies `G.2`/`G.11`; reject healthcare-specific apparatus and citation-count front claims. Receiving loci: `SourceComposedResultClaim`, E.23:4.7, and the source-use/currentness exits. Qualification/currentness: current reference plus internal rules, not external cross-domain SoTA. Reopen: Chapter 12 materially changes the used reporting rule, `G.2`/`G.11` changes, or a composed claim no longer names its admitted sources and limits.

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`	Defines the current improvement unfolding structure predicate: exact constituents, already-obtaining relations, guards, admissible alternatives, selected continuation, stop, and subject-assertion reconsideration conditions. The structure, visible cycle, record, and slice perform no Work.
`A.13`, `A.15.1`, `A.2`, `A.2.1`, `F.6`, `A.6.1`, `C.2.1`, `A.3.4`, `A.15.PROD`	Define or constrain exact actual performers, independently admitted evaluation or improvement Work, optional local classification and precise assignment-bound attribution, application and result binding, result episteme, 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`, `E.10.ROLE`, `A.3.1`, `A.3.2`, `A.6.P`, `C.2.P`, `F.18`, `F.19`	Repair load-bearing wording and names introduced by loop records. `E.10.ROLE` resolves ambiguous source role before any system-role-kind, assignment, participant, or non-system use is asserted. A.3.1 supplies the Method admission test; A.3.2 supplies the membership test for a qualifying `U.MethodDescription`. Selected pattern content otherwise defines, constrains, tests, or guides without becoming the Method or its description.
`E.23.CAE`	Supplies the separate observation-and-disposition probe when apparent capability loss or failed transfer leaves the object to improve ambiguous. It returns candidate routes, not an improvement-object choice or loop decision.
`E.23.CDI`	Describes the separate Method for developing one admitted holder System's capability for a named Work family and checking transfer in representative Work after development is separately selected. E.23 routes to it but does not absorb its action sequence; member distributions and cultural propagation keep their own results.

E.23:End

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

#Quality Improvement Loop Method

#About this pattern

#How to use this pattern

#Relations

#Content

#Problem frame

#Problem

#Forces

#Solution

#Ordinary loop method

#Conditional names and kind settlement

#Conditional Improvement Unfolding Structure Block

#How the conditional detail supports the loop

#Stop, continue, and reopen

#Method-family selection

#Operation-family selection

#Cost and BLP discipline

#Source-composed, OEE, and NQD improvement

#Archetypal Grounding

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#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

Ordinary loop method

Conditional names and kind settlement

Conditional Improvement Unfolding Structure Block

How the conditional detail supports the loop

Stop, continue, and reopen

Method-family selection

Operation-family selection

Cost and BLP discipline

Source-composed, OEE, and NQD improvement

Archetypal Grounding

Bias-Annotation

Conformance Checklist

Common Anti-Patterns and How to Avoid Them

Consequences

Rationale

SoTA-Echoing

Relations

E.23:End