{"id":"mlip-flywheel-readiness","title":"MLIP Flywheel Readiness","subtitle":"Cloudflare is deployed, gated, and ready for scientist review before the next expensive Distill campaign.","category":"changelog","tags":["mlip","flywheel","cloudflare","phoenix"],"source":"articles/docs/mlip-flywheel-readiness.md","lang":"en","words":706,"readMinutes":3,"toc":[{"depth":2,"text":"Review Target","id":"review-target"},{"depth":2,"text":"What Is Ready","id":"what-is-ready"},{"depth":2,"text":"What This View Is For","id":"what-this-view-is-for"},{"depth":2,"text":"Current Operating Model","id":"current-operating-model"},{"depth":2,"text":"What Is Not Claimed Yet","id":"what-is-not-claimed-yet"},{"depth":2,"text":"Release Gate For The Next Run","id":"release-gate-for-the-next-run"}],"html":"

MLIP Flywheel Readiness: Cloudflare At-Ready State

This note is the review surface for the current Lupine MLIP flywheel deployment. It is not a new result claim. It is the checklist state that says the control plane is ready for scientists to use when we have the next local or cloud Distill campaign ready to promote.

\n

The visual review instrument lives at MLIP Flywheel Visual Review. Use that page for stage comprehension, quantitative grid review, qualitative evaluator review, and the offset-lattice relaxation image.

\n

Review Target

The deployed Worker is:

\n\n

The core idea stays deliberately simple: local and GCP runners do compute, Cloudflare owns durable research state, Phoenix owns observability evidence, and the Rust Distill engine owns in-run policy decisions.

\n

What Is Ready

The deployed control plane now exposes the MLIP workflow family in a reviewable, gated state:

\n\n

This is the state we wanted before handing the surface to the scientist team: the system can be inspected and configured without accidentally launching a costly run.

\n

What This View Is For

Use this page to review the system before the next ambitious campaign:

\n
    \n
  1. Confirm that the public library says what we actually deployed.
    2. \n
  2. Confirm that the Worker exposes the expected workflow family.
    3. \n
  3. Confirm that campaign creation remains auth gated.
    4. \n
  4. Confirm that Phoenix is treated as evidence and observability, not as the inner-loop optimizer.
    5. \n
  5. Confirm that Distill remains a runtime intervention layer rather than a post-hoc scoring script.
    6. \n
\n

The important distinction is ownership. Phoenix should help us compare, trace, and evaluate. The hill climb that improves accuracy and speed belongs inside the Distill runtime and its policy engine, where it can change the outcome of an MLIP run while the run is happening.

\n

Current Operating Model

The flywheel is at-ready, not fully autonomous:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
LayerCurrent stateReview question
Local labBest place to iterate on Distill policies and MLIP runner behaviorCan we reproduce a small baseline and show an accuracy win before promotion?
GCP labReproducible cloud execution lane for real campaignsAre target jobs, budget guards, and artifact paths correct before launch?
CloudflareDurable control plane and public report surfaceAre workflow state, ledger rows, and gated routes behaving correctly?
PhoenixExperiment and evaluator evidence homeAre traces and evaluator packets aligned to the right project and dataset?
Rust DistillInner-loop policy and hyper-ribbon runtimeAre interventions improving sealed metrics without leaking support data?

That split keeps the system portable. A lab can bring its own runner stack, local workstation, GCP project, or HPC scheduler, while Lupine contributes the runtime policy, evidence contract, and public research control plane.

\n

What Is Not Claimed Yet

This deployment does not claim a completed 5x5x3 Distill result.

\n

It also does not claim that Phoenix promotion is the deciding mechanism for scientific improvement. Phoenix should organize the evidence, compare variants, and make drift visible. The improvement loop still needs to be proven inside the Distill runtime with sealed fixtures, row-aware policies, and repeatable MLIP runs.

\n

The next published result should come from the compute loop, not from the deployment alone.

\n

Release Gate For The Next Run

Before launching the next expensive campaign, the review gate should be:

\n\n

This is the right pre-launch posture: deployed, inspectable, gated, and ready for the next real run once the local Distill evidence says it is worth spending cloud time.

\n"}