Frontier Delta

A rigorous small-compute research system testing whether recursive self-improving LLM loops expand a model's support set or merely sharpen existing behavior.

Research scope: The research and development narrative is tied to discoveries reviewed through the July 2026 cutoff. Papers, projects, or benchmark results published after July 31, 2026 should be treated as new evidence and evaluated before updating the design.

Setup

# Clone
git clone <repo-url>
cd frontier-delta

# Create/update the locked uv environment.
uv sync

# Run tests
uv run python -m unittest discover -s tests -v

# Run proposer viability (mock, no GPU/network required)
uv run python scripts/00_proposer_viability.py

Phase 0 has no runtime dependencies beyond the Python standard library. uv manages the local environment, Python version selection, and uv.lock.

Current V1 Experiment

The mock loop runs on toy program-induction tasks. A mock proposer generates input-output examples for hidden functions (e.g., lambda a, b: a + b). A mock solver generates candidate Python functions. The sandbox executes them against held-out test cases. The verifier classifies each task as solved or unsolved, and the pass@k estimator produces unbiased solve rates. The ledger records per-problem solve counts, and the analysis module classifies tasks as gained/lost/sharpened/unchanged relative to baseline.

No real training happens in Phase 0 -- the mock trainer records what would be trained. This validates the full measurement pipeline before committing GPU resources.

Architecture

Green marks the reward path (public training examples may influence weights); amber marks the evaluation path (held-out examples are measured, never rewarded); dashed purple marks later-phase components.

Loop Detail

1. Task Proposal: Frozen frontier model generates program-induction tasks with training examples and held-out test examples. Each task declares an argument type per parameter, so generated inputs stay inside the hidden function's domain, and held-out inputs are disjoint from training inputs.
2. Solver Rollouts: Small trainable model generates k candidate Python functions per task. Each candidate must define solve(...).
3. Sandbox / Checker A: All examples in a split run in one subprocess (isolated mode, -I), with a per-example timeout and a whole-process backstop. Results return as sentinel-tagged JSON lines, so candidate stdout cannot corrupt them. Checker A compares values with type-strict equality -- True != 1, 0 != 0.0, containers recurse -- rather than comparing reprs.
4. Rewards: Configurable reward function -- verified correctness, partial credit, format-only, random -- assigned per experimental arm. The random control hashes (seed, task_id, candidate_code), so its labels are stable under reordering and parallelism.
5. Mock Trainer: Records what a GRPO + LoRA training step would compute. In later phases, performs actual weight updates.
6. Support-Set Eval: Phase 0 uses a smoothed beta-binomial point estimate; later phases add posterior intervals. Tasks are classified as gained, lost, sharpened, or unchanged by support membership.
7. Checker B: Independent audit verifier checks for reward hacking, contamination, and disagreement with Checker A. Planned for Phase 3.
8. Analysis / Ledger: Accumulates per-round, per-arm statistics into a support-set transfer map.
9. Claims-Gated Notebook: Results rendered locally, with claim values HTML-escaped and gate status validated. Nothing posted without human review.

Support-Set Classification

The central measurement. A task is in the support set when its smoothed solve probability p = (c + 0.5) / (n + 1.0) is at least epsilon. Each task is labeled by how that membership moves between two measurement points:

gained is the expansion claim and the primary endpoint. sharpened is the conservative null hypothesis: the model was already able to solve the task and merely does so more often. Reporting only aggregate pass@1 cannot tell the two apart, which is why the ledger tracks every task separately.

Test Commands

# All tests
uv run python -m unittest discover -s tests -v

# Specific modules
uv run python -m unittest tests.test_passk -v
uv run python -m unittest tests.test_verifier -v
uv run python -m unittest tests.test_rewards -v
uv run python -m unittest tests.test_ledger -v
uv run python -m unittest tests.test_tasks -v
uv run python -m unittest tests.test_sandbox -v
uv run python -m unittest tests.test_analysis -v
uv run python -m unittest tests.test_curriculum -v
uv run python -m unittest tests.test_notebook -v

# Mock loop (no GPU/network)
uv run python scripts/00_proposer_viability.py

Documentation

See docs/ for:

• Idea Development -- rationale and constraints
• Recursive Learning Map -- taxonomy of approaches
• Current Design -- full system design and experimental arms
• Implementation Plan -- phases, kill gates, compute budget
• References -- linked bibliography

License

Research code. License TBD.