Runtime & Integrations · Runtime Harness · M5
Extension Lanes (framework)
How optional capabilities attach without contaminating required paths.
A metadata-only framework:
ExtensionLane declares a lane (port, module, factory,
boundary, deletion_rule, prerequisites); LaneResult reports
ran / skipped /
blocked with diagnostics and no score or verdict;
LaneRegistry lists lanes without importing any of them.
This is the runtime behind Extension Lanes.
The registry’s resolve() is the only place a lane’s concrete code is lazily imported
(importlib), so no required import path ever loads a lane or a provider SDK.
The pieces
ExtensionLane— declarative metadata; aLanePortis one oftrace_source,score_sink,judge_model,task_runner.LaneResult— status plus diagnostics; never a score, never a verdict.LaneRegistry— lists lanes inertly;resolve(name)lazily imports the one you opt into.MissingPrerequisite— raised when a prerequisite is absent; the lane skips, it does not fail the run.
built_in_lanes() registers four: live-judge, trace-backend,
score-sink-export, and async-observation — each declaring a
deletion_rule stating what removing its file leaves intact.
Deletion is verified, not promised
Deleting a lane’s adapter file must leave the required suite green. That property is part of the
milestone proof, not a claim — it is exercised by the test suite.