[RAGE-7][P1] Add bounded candidate revision/evolution and trusted lifecycle promotion workflow #41

New issue

Open

opened 2026-09-20 01:40:01 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-20 01:40:01 +00:00

Owner

Parent: #6
Depends on: RAGE-6
Consumes:

Goal

Close the RAGE loop after evaluation: revise weak candidates when useful, preserve lineage, and route evidence-backed candidates into the upstream lifecycle without giving models self-promotion authority.

Flow

evaluation evidence
-> reject | revise | propose promotion
-> bounded evolution/revision
-> re-evaluate
-> trusted lifecycle action
-> future outcome observation

Requirements

immutable candidate/version identities;
lineage for every revision/evolution step;
explicit max generations/candidates/provider budget;
multi-objective evidence preserved; do not collapse everything into one magic score downstream;
promotion/rejection/disable/rollback use upstream lifecycle contracts;
model output may propose content, never mutate active state directly;
active versions are resolved by upstream lifecycle policy;
post-promotion observations feed future evidence without mutating historical eval records.

Acceptance

weak candidate can produce bounded child candidates and re-enter eval;
rejection leaves active skill set untouched;
promotion references concrete upstream eval evidence;
rollback restores a prior eligible version without deleting lineage;
budget/cancel/failure states stop evolution cleanly;
no downstream lifecycle database or evolution kernel is introduced.

Parent: #6 Depends on: RAGE-6 Consumes: - lost-rob0t/prolog-rlm#170 - lost-rob0t/prolog-rlm#171 ## Goal Close the RAGE loop after evaluation: revise weak candidates when useful, preserve lineage, and route evidence-backed candidates into the upstream lifecycle without giving models self-promotion authority. ## Flow ```text evaluation evidence -> reject | revise | propose promotion -> bounded evolution/revision -> re-evaluate -> trusted lifecycle action -> future outcome observation ``` ## Requirements - immutable candidate/version identities; - lineage for every revision/evolution step; - explicit max generations/candidates/provider budget; - multi-objective evidence preserved; do not collapse everything into one magic score downstream; - promotion/rejection/disable/rollback use upstream lifecycle contracts; - model output may propose content, never mutate active state directly; - active versions are resolved by upstream lifecycle policy; - post-promotion observations feed future evidence without mutating historical eval records. ## Acceptance - [ ] weak candidate can produce bounded child candidates and re-enter eval; - [ ] rejection leaves active skill set untouched; - [ ] promotion references concrete upstream eval evidence; - [ ] rollback restores a prior eligible version without deleting lineage; - [ ] budget/cancel/failure states stop evolution cleanly; - [ ] no downstream lifecycle database or evolution kernel is introduced.

nsaspy referenced this issue

2026-09-20 01:40:38 +00:00

[EPIC] Personal skill refinery: observe workflows, synthesize candidates, RAGE-evaluate, and import external skills #6