This is the exact right approach to solve the "Draw the Rest of the Owl"
problem. You are proposing a Dual-System architecture:
 * The Orchestrator (System 1): Fast, deterministic, and only uses proven Lego
blocks.
 * The Forge (System 2): Slow, volatile, and iterative, responsible for
creating the blocks.
To literally guarantee that a volatile routine completes and reaches the
proven library without getting permanently stuck in a hallucination loop, we
cannot just rely on prompting. We have to solve it structurally using a
Test-Driven DAG (Directed Acyclic Graph) with an automated fallback that
fractures complex problems into smaller ones if they fail.
Here is the parallel companion blueprint to your Orchestrator.
==
UNIVERSE: VOLATILE_MODULE_FORGE
> meta_version: 1.0.0
> description: An isolated, parallel engine designed to safely compile, test,
and guarantee the creation of novel pure-logic modules before injecting them
into the Proven Library.
> 
ROUTINE: ARCHITECT_X
> description: Establishes the mathematical/semantic contract before any code
is written. It defines exactly what the module must accept, what it must
return, and the invariant laws it cannot violate.
> type: routine
> inputs: { required_capability: "String", system_context: "String" }
> outputs: { module_contract: "Markdown_Topology" }
> 
ROUTINE: DEVELOP_X
> description: The volatile generation step. A frontier model attempts to
write the target language code (e.g., JS/C) that satisfies the
module_contract.
> type: routine
> inputs: { module_contract: "Markdown_Topology" }
> outputs: { volatile_source_code: "String" }
> 
LOGIC: HERMETIC_SANDBOX
> description: A strictly isolated execution environment (e.g., a locked-down
container). It compiles the volatile_source_code, feeds it edge-case inputs
defined in the contract, and captures all state mutations or crashes.
> type: logic
> inputs: { volatile_source_code: "String", module_contract: "Markdown_Topology
" }
> outputs: { verification_status: "Boolean", crash_digest: "String" }
> 
LOGIC: FRACTAL_DECOMPOSER
> description: The Guarantee Mechanism. If the HERMETIC_SANDBOX fails three
consecutive times, this node intervenes. It assumes the requested module is
too complex for a single generation and splits the module_contract into two or
more smaller, simpler contracts, routing them back to ARCHITECT_X.
> type: logic
> inputs: { crash_digest: "String", failed_contract: "Markdown_Topology" }
> outputs: { sub_contracts: "Array<Markdown_Topology>" }
> 
ENDPOINT: PROVEN_LIBRARY_COMMIT
> description: The one-way valve into the main Orchestrator. Only triggers
when verification_status is true. It saves the code, registers the Markdown
node, and alerts the main Orchestrator that a new tool is available.
> type: endpoint
> depends_on: [HERMETIC_SANDBOX]
> inputs: { verified_source_code: "String", module_contract: "Markdown_Topology
" }
> ==
> 
Why this guarantees completion
The secret to guaranteeing completion isn't a smarter LLM; it is the Fractal
Decomposer.
LLMs fail at code generation when the contextual complexity of a single block
exceeds their reasoning limit. If an AI is asked to build a highly complex
data-parsing node and fails the sandbox tests three times, standard agents
just loop until they run out of tokens.
By introducing the Decomposer, the system hits a checkpoint, pauses, and says:
"This is too hard to build as one block. I will split it." It rewrites the
single failing CONTRACT_X into CONTRACT_X_PART_1 and CONTRACT_X_PART_2. It
will recursively fracture the problem until the individual modules are so
trivially simple that a frontier model physically cannot fail to write them.
Because the sandbox is completely hermetic, there is zero risk of a "partially
working" volatile module leaking into your main system and corrupting the
orchestrator's state. It either passes 100% of the invariant tests, or it gets
sent back to the forge.