# 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:

```text
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.