Cognitive-OS-Wantsong/docs/MODEL_ORCHESTRATION_V0.md

Model Orchestration V0

status: draft_orchestration_boundary date: 2026-06-20

Purpose

Orchestration decides which small set of models should participate in a cognitive-processing run.

M0-M1 only defines the decision fields and call limits. It does not implement a selector.

Roles

• routing_model: classifies input and controls next-step routing.
• depth_model: performs vertical deep processing.
• primary_model: main explanatory model for a run.
• support_model: fills a known blind spot of the primary model.
• contrast_model: challenges or reframes the primary model.
• calibration_model: checks evidence, action boundary, or overclaim risk.
• translation_model: rewrites internal output for reader use.
• synthesis_model: integrates outputs into a coherent judgment.

Startup Defaults

qpi:

• default role: routing_model;
• should run before deep processing when problem framing is unclear;
• should stop at routing and misframing diagnosis.

intellectual_archaeology:

• default role: depth_model;
• can become primary_model for complex, high-value, reusable, or repeatedly failing issues;
• should run after intake/QPI justifies deeper work.

Single-Run Call Budget

A normal run may include at most:

• one primary model;
• two or three support or contrast models;
• one calibration lens;
• one reader translation layer.

Do not call every related model. A model must add explanatory value, reduce a blind spot, or change the action boundary.

Main Model Selection Signals

Primary model choice should consider:

• problem type match;
• explanatory gain;
• intended output;
• model maturity;
• processing cost.

Do not use simple keyword matching as the final selection method.

Support Model Entry Conditions

A support model may enter only when:

• the primary model has a known blind spot;
• the primary model may over-explain;
• the issue needs comparison, contrast, or calibration.

Guardrails

• QPI is not the product output.
• Intellectual Archaeology is not default for light tasks.
• No full selector in M0-M1.
• No flat scoring across a large model universe.
• No expansion beyond the two startup models without owner instruction.

Future 100-Model Direction

If the project later grows toward many models, orchestration should use a layered path:

input -> domain/problem family -> 5-8 candidates -> 1 primary -> 2-3 support/contrast -> calibration -> synthesis -> translation

This future direction is only a design hook. It is not part of v0.1 implementation.