A correction can fix the current answer without improving the system. A governed improvement path makes the proposed future change inspectable: what failed, which evidence supports the correction, what exact artifact changes, and who is entitled to release it.
The earlier build-along presented local FeedbackEntry/InsightCluster/StrategyProposal/ReplayVerdict/StrategyRule shapes as canonical runnable schemas. Its stubs returned empty typed proposals, a string was described as an enforced enum, capture did not implement its claimed authorization, and release applied a patch before establishing the pictured approval/lineage. Those incomplete functions are withdrawn. This is an explicit design guide, not an implemented feedback or deployment service.
The Improvement Loop distinguishes locally versioned candidate profiles such as FeedbackRecord, Insight and StrategyRule from exported base runtime contracts. They produce proposals; they cannot change a current grant or policy by appearing in memory.
1. Admit the correction before capture
Resolve the actual decision/source references and current operator identity, tenant/owner scope, permitted purpose and correction rights. A caller-provided signed_by or free-form override cannot authenticate itself. Keep server-derived identity/lineage fields protected from caller overwrite and validate bounded closed schemas at ingress.
Use an explicit versioned reason registry if closed categories are required. A TypeScript string plus a comment does not enforce an enum. Unknown/malformed input fails visibly; an unsupported reason does not become an empty object cast to a valid proposal.
Collection and candidate storage already need eligible readers, actual model/reviewer processors, residency and retention. Minimize personal data and credentials before persistence or export. Immutability means history is not silently rewritten; it does not justify indefinite raw payload retention. A permitted superseding correction can preserve eligible transition metadata while the old payload follows its retention/deletion policy.
2. Distinguish observation from authority
An operator correction is evidence about a case, and the operator can be wrong. Resolve conflicting evidence under current policy-defined decision rights; recency, repetition or fluent explanation does not establish authority.
A refund exception approved for one customer is not permission for every future VIP refund. A remembered correction cannot remove exact approval, independent denial/escalation or ancestor restrictions on the next action. Existing authorized narrow work can continue without a repeated prompt when no mandatory gate applies.
3. Cluster only eligible comparable cases
Group within current tenant/owner/purpose access and meaningful decision, policy, release and time scopes. Deduplicate correlated reports and preserve source ancestry; ten copies of one mistaken observation are not ten independent confirmations. Do not expose other tenants or broader evidence to a model merely to find a pattern.
Minimum cluster counts are calibrated domain parameters, not a universal threshold of five or a guarantee of statistical significance. A single serious control failure can require immediate blocking/incident handling; waiting for a cluster cannot waive a current mandatory requirement.
The output is an insight with source references, uncertainty and affected scope. It is not a new rule or a deployment instruction.
4. Propose a bounded future change
An illustrative non-executable progression is:
eligible authenticated correction
-> owned candidate with exact source/decision refs
-> scoped deduplicated insight with limitations
-> validated patch against immutable baseline and allowed target fields
-> frozen candidate/proposal digest
-> independent held-out release evaluation
-> current entitled exact release approval and atomic deployment claim
-> staged release, governed monitoring and explicit recovery limitsA proposal identifies exact baseline/target versions, patch semantics, intended impact, required tests and recovery plan. Required policy, approval, evidence, data or conformance controls are not optimization knobs. A future policy change needs its governing owner and authorized release; a proposer cannot weaken it merely by calling the patch an improvement.
Unknown targets, unsupported operations, malformed bodies and unimplemented proposal classes return a structured error or rejected candidate. Never emit {} with a type assertion to satisfy a return type.
5. Keep replay and release evidence honest
Freeze the candidate before the protected release set is inspected. Separate development/search evidence from sealed release evidence, bound submissions and feedback, and deduplicate related cases across splits. A proposer repeatedly ranking candidates against held-out details has converted those cases into search data.
Replay uses eligible pinned inputs and recorded model/tool artifacts without reissuing effects. Compare deterministic compiler/policy artifacts exactly; model-dependent stages require recorded outputs or declared properties/scorecard tolerances. Output-hash equality alone cannot establish policy, safety, data eligibility or usefulness.
Require complete valid expected outcomes, denominators, artifact/report bindings and current independent observations. Missing, stale, malformed, synthetic-only, unevaluated, empty required sets or non-finite scores are insufficient, not neutral zeroes. A changed-to-expected answer cannot offset an independent control failure. Record partial replay and retained/deleted-data gaps visibly.
6. Authorize the exact release before applying it
Bind the current stored proposal, complete candidate artifact/release digest, baseline, tests/reviewer evidence and immutable policy/profile pins. Verify current entitled distinct approver quorum and separation rules where required. A string approver_id, passed replay status or unmatched verdict cannot establish release authority.
A release or deployment is a governed effect. Its protected owner checks current requester/tenant/audience/ancestor mandate, independent business policy, exact required approval, active execution/credential/data controls, external preconditions and original shared reserved capacity. Persist the owned operation/approval transitions atomically with revisions and current worker/target fencing before mutation. A trace is not synchronization.
Preserve complete eligible feedback/insight/evidence lineage rather than publishing empty placeholders after patching. Store failure after an external mutation leaves an uncertain outcome to reconcile; it cannot be reported as if the change never happened.
7. Operate background work and rollback
Scheduled synthesis, review, evaluation, canary and monitoring need current owner mandates. Wake/resume rechecks authority and ancestor revocation, exact approval when required, actual boundaries/data routes, external preconditions and current fenced ownership. Model, tool, reviewer, retry and child jobs consume original shared spent/reserved capacity; a new session cannot reset it.
Use stable operation identities and provider-specific recovery for uncertain deployment, export or policy-store effects. Cancellation is not observed stop; re-pinning a baseline changes future behavior without proving prior external actions were reversed. Compensation/correction is a new separately governed effect, and uncertain usage/effects retain reservations until evidence supports release.
Track source, candidate, summaries, embeddings, caches, memory, evaluation datasets, exports and delegated copies through bound correction/deletion receipts. Pending, failed or externally unknown propagation remains incomplete. Cleanup after expiry can remain eligible under the actual policy; expired access is not proof of deletion.
Acceptance evidence
Exact profiles and conformance requirements bind useful positive and required denial/fault cases to the actual workflow, implementation, release and environment. The current reference validators exercise these shared boundaries over synthetic facts; they do not deploy this improvement pipeline:
rtk npx vitest run tests/authorization.test.ts tests/conformance.test.ts tests/execution-workflows.test.tsA release needs actual current independent evidence from its owners. No fixed number of files, thirty-day promise, permanent error-prevention claim or successful background run is established by this design guide.