Repository navigation
Hill-climb property generation quality #84
Copy link
Copy link
Closed as not planned
Labels
enhancementNew feature or requestNew feature or request
Description
Goal
Improve property-generation prompts so they produce more valid, interesting properties with fewer property-level false positives.
This is a follow-up to #79. Property provenance must land first so outcomes can be attributed to the exact source lens/framework and generated property.
Definitions
- Valid property: consistent with the target protocol's intended behavior, reachable, non-vacuous, and expressible as an observable oracle.
- Interesting property: project-specific and capable of detecting a meaningful state violation rather than restating a generic or duplicate assertion.
- Property false positive: a generated property that would flag intended protocol behavior as a violation.
V1 scope
- Define a structured adjudication record keyed by the canonical property ID from Create provenance of properties #79:
property_idvalid | invalid | needs-reviewinteresting: booleanfalse_positive: booleanrationale
- Aggregate valid rate, interesting rate, and false-positive rate by source lens/framework.
- Define a deterministic score for comparing a candidate property-generation prompt against its baseline.
- Run candidates against a fixed, pinned benchmark cohort for multiple trials.
- Accept a candidate only when it improves the aggregate score without increasing the false-positive rate; otherwise retain the baseline.
- Preserve the candidate prompt/config, benchmark lineage, per-property adjudications, aggregate score, and accept/reject decision as artifacts.
Non-goals
- Property provenance itself; that belongs to Create provenance of properties #79.
- Changing invariant fuzzer selection or scheduling.
- Automatically changing target production code.
- Optimizing downstream finding triage.
Acceptance criteria
- A fixed benchmark cohort and trial count can be configured.
- Baseline and candidate runs use compatible benchmark and scoring lineage.
- Each adjudicated property links to its canonical property ID and source provenance from Create provenance of properties #79.
- Reports show valid, interesting, and false-positive rates overall and per source lens/framework.
- Candidate acceptance is deterministic from the recorded inputs and scoring rule.
- Rejected candidates do not replace the active property-generation prompt.
- Tests cover improved, regressed, tied, and incomplete-adjudication outcomes.
- Documentation explains the scoring rule, artifacts, and how to reproduce an optimization run.
Dependency
Blocked by #79.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or request
Activity
mrthankyou commentedon Jul 30, 2026
Models drift over time under the same version. Worth being aware of when tracking quality over time, and worth OSS/self-hosted where we need results reproducible long-term.
aviggiano commentedon Oct 5, 2026
Closing as not planned. This is long-horizon research. It needs per-property adjudication (none exists today; adjudication only covers findings), stage-level evals (#80) and paid multi-trial cohort runs, and paid benchmark CI was retired in #1129. The #5 ablation also doesn't justify the cost right now. Removing the property specialists dropped NoFuzz from 26/38 to 24/38, and each cohort arm cost about $14k. The concrete property-quality work continues in #687 (unfalsifiable oracles), which now also absorbs #524's executable-oracle checks. Reopen with a funded eval plan.