One Loop Runtime: Composing Deterministic and Model Nodes with Swappable Engine Slots

Every executable graph vertex in Loop Engine is a Loop. Learn how Practitioner, Intelligence, and Solution roles combine with swappable engine slots in engine_slots.yaml so engines can be replaced at runtime without changing a caller.

In most agent frameworks, adopting an open-source library or switching from a model call to a deterministic rule engine requires rewriting the orchestration graph. In Loop Engine, every executable graph vertex is a Loop, and every functional capability outside the fixed runtime frame binds to a typed engine slot declared in engine_slots.yaml. Callers communicate only with the slot's fixed, versioned request and result contract. A host setting or runtime preference switches between a Baltor-native engine, a containerized GitHub adapter, or a model-assisted engine without editing a single caller.

The Loop classification tree

Passive files, scene meshes, ports, slots, and edges are not graph vertices. Every executable graph vertex is a Loop classified along four orthogonal axes:

Loop
├── Relationship: Starting, Spawned by, Queried by, Retrieved by, Connected from
├── Role: Practitioner, Intelligence, or Solution
├── Mode: deterministic, hybrid, or non-deterministic
└── Settings: contract, loop condition, exit condition, budget, and permissions

A discrete cognitive or act step Loop node retains its complete behavioral explanation: a narrowly scoped assignment, selected context and resources, separately initialized harnesses, permitted harness changes, expectation checks, iteration until declared completion conditions, continued production of alternative outputs, and protection against repeated external effects. Publication of an output is separate from completion.

How engine_slots.yaml and conformance kits work

When we integrate an external project from GitHub or a research paper, it never enters the codebase as an ad-hoc dependency. Instead:

• Typed edge definition: We define or reuse the functional slot in engine_slots.yaml with explicit input schemas, output schemas, and refusal codes.
• Pinned adapter and Baltor-native engine: The external project is wrapped as an engine adapter pinned to its exact source revision and license inside the sandbox its trust requires. Beside it, we build a Baltor-native engine that passes the exact same conformance kit.
• Known-good and known-wrong conformance testing: Every engine registered to a slot is tested individually against positive vectors, boundary inputs, and known-wrong adversarial controls before it is eligible for runtime selection.

# Runtime Engine Selection by Declared Order and Recorded Conformance Evidence
def select_slot_engine(slot_spec: dict, preference: list[str], evidence_store: dict) -> str:
    order = preference or slot_spec["default_engine_order"]
    for engine_id in order:
        rec = evidence_store.get((slot_spec["slot_id"], engine_id))
        if rec and rec.get("conformance_passed") and rec.get("known_wrong_rejected"):
            return engine_id
    raise RuntimeError(f"no_qualified_engine_for_slot:{slot_spec['slot_id']}")

By keeping deterministic pipeline steps (Connected from) and model-driven steps (Spawned by / Queried by) on the same Loop runtime and behind typed engine slots, a team can prototype a workflow with a frontier model, distill hot paths into sub-millisecond deterministic engines, and verify every transition against the same conformance kit.