E.23:5 - Archetypal Grounding

Tell. Name the object version and evaluation, make one bounded change, and re-evaluate the changed object before claiming improvement. Identify dated improvement Work only when that occurrence is asserted. 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.