ULAM / DISTILLSWE
v0.4.1 / Pilot RC Discuss a pilot ↗
Private frontier-lab pilot

// Autonomous-teacher environment

Can a model teach another coding model?

DistillSWE is a closed-loop meta-RL environment. An outer model receives a frozen coding student, visible repositories, a controlled post-training stack, and a fixed resource budget. It must create the learning loop—not merely solve a task.

Episode10 hours
StudentFrozen 3–4B model
SubmissionOne adapter
RewardSealed transfer
Agent objectiveImprove another modelCurriculum creation under budget.
CorrectnessExecutableBehavioral tests, not model vibes.
GeneralizationRepository-disjointPrivate tasks the outer model never sees.
EvidenceAuditableReceipts, lineage, resource ledger, reports.

// 01

Not another coding benchmark.

Most software benchmarks measure whether a model can produce one correct patch. DistillSWE measures whether a model can diagnose a student, manufacture useful experiences, allocate post-training compute, and cause durable improvement.

THE OUTER MODEL IS THE AGENT.
THE STUDENT IS THE SYSTEM IT MUST IMPROVE.

Conventional SWE evaluation

Task-level
→Model receives a software issue
→Model edits a repository
→Tests return pass or fail

Useful for measuring local coding ability. It says less about whether a model can run a long-horizon scientific improvement process.

DistillSWE

Capability-level
→Outer model creates and validates learning experiences
→Student failures become verified training artifacts
→One adapted student faces a sealed transfer suite

The unit of success is not a clever synthetic task. It is measurable improvement of the student on private, unseen repositories without unacceptable retention loss.

// 02

The autonomous teaching loop.

DistillSWE exposes a persistent macro-action environment. The outer policy decides what to inspect, what to generate, which attempts to repair, which data to train on, and when to spend scarce development queries.

RESET → OBSERVE → STEP
EVERY ACTION RETURNS AN IMMUTABLE RECEIPT.

Stage 01 / task creation

Create executable learning experiences.

The outer model proposes repository issues, behavioral tests, reference patches, regression commands, skill tags, and difficulty metadata. Proposals enter a staged validation pipeline before they can influence training.

ArtifactTaskProposalStrict structured schema; no free-form task handwaving.
GateFail before, pass afterBaseline must fail; independently validated reference must pass.
StrengthMutation-tested verifierWeak and bypassable tests are rejected.
BudgetTeacher tokens + test CPUProblem creation has explicit resource cost.

// 03

Five environments. One substrate.

Labs can start with high-volume sub-environments or run the full ten-hour autonomous teaching campaign. The same repositories, verifiers, receipts, and evaluator boundaries support every track.

FORGE + CRITIC FOR VOLUME.
FULL FOR FRONTIER EVALUATION.

Selected track

DistillSWE-Full

The flagship environment. Terminal reward is sealed student transfer, adjusted for robustness, retention, compute, and integrity.

// 04

The lab supplies the intelligence. Ulam operates the experiment.

The evaluated model or policy receives a typed action interface. Ulam hosts the student, training stack, sandboxes, private evaluators, evidence service, and organizer controls in a disposable single-tenant deployment.

MINIMAX OR ANOTHER LAB CAN SUPPLY
A POLICY CONTAINER OR PINNED MODEL ENDPOINT.

Visible to the outer policy

  • Visible curriculum repositories and approved code search
  • Frozen student and scaffold identities
  • Accepted and rejected task receipts
  • Checkpoint-bound student trajectories
  • Bounded aggregate development feedback
  • Remaining tokens, rollouts, compute, tests, and wall time

Sealed by Ulam

  • Private final repositories, prompts, and tests
  • Retention suite and Forge probe suite
  • Reference solutions and evaluator internals
  • Organizer capabilities and signing keys
  • Independent scoring and evidence generation
  • Final terminal evaluation outside the action space

// Single-tenant pilot boundary

Lab-operated model
01Lab model / outer policyPinned identity
02Participant gatewayAuth + rate limits
03DistillSWE action environmentState + receipts
Task forgeStructured proposals and isolated validation.
Student workersDisposable, checkpoint-bound rollouts.
TrainerSupervised bounded GPU jobs.
Sealed evaluator boundaryPrivate development, final, retention, and Forge suites. Only strict allowlisted aggregates cross back into the participant environment.

// 05

Measured by transfer—not activity.

Generating more tasks, collecting more rollouts, or consuming more compute does not directly earn the terminal score. The authoritative result is whether the adapted student becomes better on a sealed distribution.

ONE STUDENT. ONE CHECKPOINT.
ONE PRECOMMITTED EVALUATION CONTRACT.

Authoritative terminal reward

R = min(grobust, LCB(gseed)) − Pretention − λCcompute − Pintegrity

Robust target performance blends aggregate capability with lower-tail skill performance. Fixed-seed lower confidence bounds discourage lucky checkpoints. Retention and compute remain explicit costs, while an integrity failure can invalidate the run.

01
Repository-disjoint transferPrivate tasks from unseen repositories.
target
02
Weak-tail capabilityHard skill families cannot be ignored.
P10
03
Run robustnessFixed seeds and lower-confidence scoring.
LCB
04
General retentionBroad coding capability must survive.
ΔG
05
Resource efficiencyTokens, GPU, CPU, tests, storage, time.
cost

// 06

Designed for an untrusted outer policy.

The pilot boundary is intentionally stricter than an ordinary research harness. Participant actions are confined, transactional, schema-validated, resource-bounded, and auditable before they can affect the measured result.

CONTROLLED, DISPOSABLE,
SINGLE-TENANT PILOT RELEASE CANDIDATE.

Enforced

Path confinement

Participant paths are resolved against action-specific roots before any read, write, deletion, or subprocess use.

Enforced

Transactional actions

Work executes in hidden staging paths and publishes atomically; rejected or interrupted actions do not commit artifacts.

Enforced

Idempotent requests

Every step carries a request ID. Safe replays return the original receipt without repeating work or spending budget twice.

Enforced

Organizer-owned tests

Candidate repositories cannot shadow or replace the verifier harness. Test counts and harness digests are attested.

Enforced

Isolated execution

Student and verifier jobs run in disposable, network-disabled boundaries with only the minimum task mounts.

Enforced

Strict action schemas

Unknown fields, coercions, oversized payloads, and out-of-range resource requests are rejected.

Enforced

Hard job limits

Rollout, verifier, evaluator, and training process trees have external deadlines and forced cancellation.

Enforced

Adapter attestation

Submission is adapter-only, tensor-allowlisted, shape-checked, lineage-bound, and tied to the pinned base model.

// 07

A pilot built to produce a decision.

Ulam and the lab precommit the model identity, student, repositories, resource envelope, evaluator, retry rules, and success criterion before measured execution. A valid negative result is still a completed pilot.

RECOMMENDED: ONE SMOKE RUN
+ THREE INDEPENDENT MEASURED CAMPAIGNS.

01

Technical scoping

Select integration mode, freeze identities, approve repository substrate, and sign the evaluation plan.

1–2 weeks
02

Integration + unmeasured smoke run

Verify API behavior, endpoint capacity, sandboxing, cancellation, evaluator schemas, and evidence generation.

1–2 weeks
03

Measured campaign

Run three independent Full-track episodes from clean student checkpoints under the same pinned protocol.

3 × 10h
04

Decision report

Deliver per-run evidence, campaign aggregate, adapter lineage, resource ledger, interpretation, and next-step recommendation.

1 week

// 08

Evidence a research and security team can inspect.

DistillSWE does not end at a leaderboard number. Every measured campaign produces enough protocol identity and provenance to understand what improved, under which constraints, and with which limitations.

RESULTS ARE SPECIFIC TO THE PINNED
MODEL, STUDENT, SCAFFOLD, BUDGET, AND SUITE.

01

Per-run scorecard

Target, weak-tail, robustness, retention, compute, integrity, and terminal reward.

02

Campaign aggregate

Three-run mean, variation, confidence interval, success rate, and comparability checks.

03

Adapter + lineage

Submitted tensors, checkpoint ancestry, training configuration, and base-model binding.

04

Resource ledger

Teacher and student tokens, training tokens, GPU time, sandbox CPU, tests, tools, storage, and wall clock.

05

Receipt and audit chain

Hashed inputs, outputs, action state, budget changes, integrity events, and provenance verification.

06

Interpretation memo

What the result establishes, what it does not establish, and the highest-value follow-on experiment.

Customer-safe output

A benchmark artifact, not a marketing dashboard.

The report leads with the measured question, protocol identity, raw score movement, robust reward, and capability profile. Private prompts, repositories, and hidden tests remain excluded.

Self-contained HTMLOffline-safeChecksummedOptional HMAC signingMachine-readable JSON

// 09

Questions labs ask first.

The protocol is intentionally explicit about what is measured, who operates each boundary, and where the current release stops.

THE PILOT IS AN AUDITABLE MEASUREMENT.
IT IS NOT A GUARANTEED UPLIFT CONTRACT.

Is DistillSWE just an automated fine-tuning benchmark?

No. Fine-tuning is one action inside a larger environment. The outer model must diagnose the student, create and validate experiences, allocate rollouts, judge failures, construct training artifacts, choose bounded recipes, use scarce feedback, and decide when to submit.

Does the outer model see the final benchmark?

No. Final repositories, prompts, behavioral tests, reference solutions, retention tasks, and evaluator internals remain inside an organizer-controlled sealed boundary. Development feedback is aggregate and strictly allowlisted.

Who hosts the pilot?

For the first engagements, Ulam should host the complete environment in a disposable single-tenant deployment. The lab supplies a pinned model endpoint or policy container; Ulam operates the student, trainer, sandboxes, private suites, scoring, and evidence service.

Can a lab provide its own agent controller?

Yes. The preferred integration is a signed policy container or a remote controller connected through an authenticated gateway. A Ulam controller calling a pinned model endpoint is also possible for a faster, narrower baseline.

What training methods are supported in v0.4.1?

Full tool-use trajectories can be trained through SFT and DPO. The bundled verifier-guided GRPO stage is patch-level. Full multi-turn student-agent policy optimization remains outside this pilot release.

What happens if the model does not improve the student?

The pilot still produces a valid capability result: which strategies were attempted, where the student failed to transfer, how resources were spent, and what the evidence supports. Commercial delivery acceptance is separate from a precommitted performance success criterion.

// DistillSWE pilot

Bring your model. We’ll bring the student, environment, and sealed evaluator.

Start with an integration session to select the outer-policy interface, student checkpoint, repository distribution, resource envelope, and decision criterion.

Discuss a pilot ↗