E.23:4.2 - Conditional names and kind settlement
Source and practitioner phrases such as “loop engineering”, “agent loop”, “harness loop”, “prompt loop”, and “workflow hardening loop” are entry phrases. Lower them into ObjectUnderImprovementRef, QualityEvaluationQuestionFrame, QualityEvaluationUseDeclaration, ImprovementAim, MethodFamilySelection, CostAndRiskAccount, and QualityImprovementLoopRecord, or else name the subject pattern for the live claim and leave E.23 closed.
Quick lowering map:
| Entry cue | E.23 use | Exit when this is the live claim |
|---|---|---|
| “Build a loop” or “loop engineering” | Ask which object version is being improved and which evaluation will be rerun. | If no object-version improvement claim is present, choose the subject pattern named by the live claim. |
| Agent retry, monitor, or escalation cycle | Use E.23 only when the retry changes an object version and re-evaluation can show a changed result on declared coordinates. | Performed execution and work plans use the A.15 family; gate passage uses A.21; transformation-flow cycle structure uses E.18. |
| Harness engineering | The harness can be the object under improvement when its next version is evaluated against declared quality, cost, and risk conditions. | Running the harness is work; comparing harness variants is G.9; retaining variants is C.18 or C.19; selected-set result declaration is G.5; for publication, use E.17 for a source-backed face and return to source and E.24.PUB for the occurrence, form, carrier, audience, bounded use, and availability. |
| Fast DPF seed hardening | A local DPF seed, pattern seed, relation record, or source pack can enter E.23 after the object version and evaluation are declared. | Source-use and source-pack return use G.2; source decay, edition change, and refresh use G.11; PFAD and PFR decisions use E.4.PFAD and E.4.PFR; first-entry publication uses E.11 only when publication is current. |
The next table names the local values used after this routing choice.
| Local name | Kind and function |
|---|---|
QualityImprovementLoopMethod | Repeated improvement U.Method for one object version under one declared evaluation use. |
ObjectUnderImprovementRef | Exact U.Entity version being changed, paired with its exact U.Kind. |
QualityEvaluationQuestionFrame | The E.22 U.Episteme that binds one exact object version and use declaration to the selected characteristic space, predicate or comparator, ClaimScope, exact result-consuming work or decision, evaluation purpose, qualification window, and any grounded non-use boundary required by E.22. E.23 reuses that frame; it does not move the consuming-use position into the declaration. |
QualityEvaluationUseDeclaration | The E.22 U.Episteme that keeps any question-changing evaluator condition or intended-evaluator identity separate from the actual evaluator, assignment and dated Work, and keeps the evaluation pattern, optional semantic Method, selected characteristic space, predicate or comparator, ClaimScope, quality-model descriptions, evidence basis, result form, and qualification window distinct. E.23 reuses it; it does not define a second evaluation ontology. |
LoopEvaluationEvidenceBasis@Context | U.Episteme whose EntityOfConcern is the exact object version evaluated in one loop pass. It describes the evidence values actually checked and missing evidence positions found for that pass and is distinct from E.22’s expected evidence-basis description. |
LoopEvaluationResultFormDescription | U.Episteme describing the result-row form used for the current pass; normally the same form cited by the evaluation-use declaration. |
ImprovementAim | Desired evaluation-result change. It names the intended quality change, not a value established by the repair itself. |
MethodFamilySelection | Selected method family for the current object and evaluation. |
OperationFamilySelectionSet | Optional operation-family set selected because its operations can change the evaluated result enough to justify cost. |
ObjectUnderImprovementEvaluationWorkRef | Reference to one independently identified dated A.15.1 evaluation Work occurrence. The Work remains distinct from its application, returned value, result episteme, evidence, and judgment. |
ObjectUnderImprovementEvaluationResultRef | Reference to one separately constituted result episteme whose claims state the evaluation result. The episteme is not the returned value; the exact A.6.1 result binding or direct evaluation-result relation remains separately identified. |
ImprovementPassWorkRef | Reference to one independently identified dated A.15.1 Work occurrence that actually changes or attempts to change the object. Selection of a proposal supplies no such occurrence. |
CostAndRiskAccount | Cost and risk account used to judge another pass or operation. |
ImprovementLoopDecisionValue | Local closed value set `stop |
QualityImprovementLoopRecord | U.Episteme whose EntityOfConcern is the exact starting object version for one bounded improvement-loop application. Its ClaimGraph relates that version to one admitted unfolding structure, selected next-action proposals, independently identified evaluation and improvement Work, exact result bases and result epistemes, changed versions, evidence bases, trade-offs, cost and risk, and the selected continuation and boundaries. It describes those objects and relations; it is not the method, performer, Work occurrence, changed object, or structure. |
QualitySideEvaluationChangeClaim | Controlled claim-node form inside a U.ClaimGraph; it compares before and after evaluation results for named object versions on declared Q coordinates. Each result uses the evaluation-use declaration bound to its own object version; keep the evaluation criterion, scope, scale and qualification conditions comparable, or state the explicitly selected stronger evaluation. |
SourceComposedResultClaim | Controlled claim-node form inside a U.ClaimGraph; it relates one changed-object result claim to exact accepted source-use decisions and each source contribution. It is neither the changed object nor a source-use decision. |
KindRestorationCheck | Conditionally present precision-repair check required by the selected restoration predicate and its evaluation result. |
LoopEvaluationEvidenceBasis@Context <: U.Episteme:
entityOfConcernRef: U.EntityRef, referencing the exact object version evaluated in this loop pass
entityOfConcernKindRef: U.KindRef, referencing the exact kind of that object version
claimGraph: U.ClaimGraph by value
referenceScheme: U.ReferenceScheme by value
editionId
qualityEvaluationUseDeclarationRef: U.EpistemeRef, referencing one QualityEvaluationUseDeclaration about that object version
checkedEvidenceValueRefs[]: U.EntityRef, each referencing one evidence value actually checked
checkedEvidenceValueKindRefs[]: U.KindRef, each referencing the exact kind of the paired evidence value
checkedEvidenceRelationRefs[]: U.EntityRef, each referencing one governed evidence relation
checkedEvidenceRelationKindRefs[]: U.KindRef, each referencing the exact kind of the paired evidence relation
unfilledEvidencePositionDescriptionRefs[]: U.EpistemeRef, each referencing one description of an unfilled evidence position
qualificationWindowDescriptionRef: U.EpistemeRef, referencing one EvaluationQualificationWindow description
QualityImprovementLoopRecord <: U.Episteme:
entityOfConcernRef: U.EntityRef, referencing the exact starting object version for this bounded loop application
entityOfConcernKindRef: U.KindRef, referencing the exact kind of that starting object version
claimGraph: U.ClaimGraph by value
referenceScheme: U.ReferenceScheme by value
editionId
improvementUnfoldingStructureRef: U.EntityRef, referencing one admitted A.22 constraint-governed unfolding structure; when transformation-flow membership is current, this same selected U.Structure also satisfies E.18/E.18.3 rather than designating a second structure
qualityEvaluationUseDeclarationRef: U.EpistemeRef, referencing one QualityEvaluationUseDeclaration
selectedNextActionProposalRefs[]: U.EpistemeRef, each referencing one CandidateImprovementProposalRow@Context; selection does not establish performance
evaluationPassClaims[1..*]:
evaluationWorkRef: U.EntityRef, constrained to U.Work
evaluationApplicationRef?: U.EntityRef, referencing one exact A.6.1 application when that is the evaluation route
evaluationResultBasisRef: U.EntityRef, referencing its A.6.1 result binding or the evaluation-result relation defined by the evaluation pattern
evaluationResultEpistemeRef: U.EpistemeRef, referencing one separately constituted result episteme
loopEvaluationEvidenceBasisRef: U.EpistemeRef, referencing one LoopEvaluationEvidenceBasis@Context
improvementPassClaims[]:
selectedNextActionProposalRef: U.EpistemeRef, referencing one still-propositional E.22 row
improvementWorkRef?: U.EntityRef, constrained to U.Work and present only after actual improvement Work obtains
changedObjectVersionRef?: U.EntityRef, present only when that changed version exists independently of this record
changedObjectVersionKindRef?: U.KindRef, paired with changedObjectVersionRef
workResultOrChangePredicateRefs[]?: U.EntityRef, each referencing a declared Work-to-result or Work-to-change predicate, or an A.6.1 result-binding predicate used by the basis
workResultOrChangePatternLocators[]?: U.EntityRef, positionally paired with the predicate refs and each referencing the subject pattern that defines that predicate
workResultOrChangeBasisRef?: U.EntityRef, referencing either the obtaining Work-to-result or Work-to-change relation, a filled local claim that names the Work, result or change, applicable conditions and facts, or an A.6.1 result binding
tradeoffProtectionSet: TradeoffProtectionSet@Context by value
costAndRiskAccountDescriptionRef: U.EpistemeRef, referencing one cost-and-risk-account description
loopDecisionValue: ImprovementLoopDecisionValue
selectedContinuationClaimRef?: U.EpistemeRef, referencing the current branch-selection claim without turning it into Work
stopBoundaryRef: U.EntityRef, referencing one ImprovementLoopBoundaryCondition@Context
reconsiderationBoundaryRefs[]: U.EntityRef, each referencing one ImprovementLoopBoundaryCondition@Context
loopDecisionReasonDescriptionRef: U.EpistemeRef, referencing one loop-decision-reason description
QualitySideEvaluationChangeClaim in U.ClaimGraph:
beforeQualityEvaluationUseDeclarationRef and afterQualityEvaluationUseDeclarationRef
beforeObjectVersionRef and afterObjectVersionRef
beforeEvaluationResultRefs[] and afterEvaluationResultRefs[]
evaluationCoordinateRefs[]
qualificationWindowDescriptionRef
SourceComposedResultClaim in U.ClaimGraph:
changedObjectVersionRef and changedObjectVersionKindRef
resultClaimNodeRef
acceptedSourceUseDecisionRefs[1..*]
sourceContributionDescriptionRefs[1..*]
The two named claims are node forms inside the claim graph of a result or loop episteme; a table row or serialization may publish them but does not become the claim.
Checked evidence values stay paired with their kinds; evidence relations form a separate pair. Every actual Work reference points to an independently identified occurrence governed by the central §4 Work rule. A compact rendering may use only the omission allowed there.
For an improvement pass, the changed-version reference appears only after that version exists. The workResultOrChange... fields keep the declared predicate, its pattern locator, and the obtaining basis distinct. That basis must be an A.6.1 result binding, a direct Work-to-result or Work-to-change relation, or a local relation claim that names its participants, conditions, and obtaining facts. If only the predicate or locator is known, keep the proposal, Work, changed object, and Transformation separate and return a missing-governor finding for the intended Work-to-result or Work-to-change relation. An A.15.PROD route points to its applicable local claim rather than to the pattern as a generic claim.
The two record epistemes follow C.2.1 identity: claim content, exact EntityOfConcern, and effective U.ReferenceScheme determine each episteme edition. The listed loop fields contribute to claim content; editionId designates an already distinguished edition but does not constitute it. Empirical grounding, viewpoint membership, claim scope, model-use structure, applicability, qualification, evidence currentness, and source currentness remain separate relations or values defined elsewhere. A change in one of them changes a record episteme only when its claim content, EntityOfConcern, or reference scheme is revised; carrier and support serialization alone change neither episteme. These records do not create quality values, project evidence, release state, selected-set result declaration, actual publication, parity, refresh, Work, Transformation, or proof of quality.
The retained @Context suffixes on support species such as LoopEvaluationEvidenceBasis@Context, CandidateImprovementProposalRow@Context, TradeoffProtectionSet@Context, and ImprovementLoopBoundaryCondition@Context are compatibility and retrieval spellings only. No suffix or context label supplies a container, participant, ClaimScope, applicability, or identity discriminator. The three identity-bearing interface names in this package are suffixless: QualityEvaluationQuestionFrame, QualityEvaluationUseDeclaration, and QualityImprovementLoopRecord.