Architecture · Task routing

How a consumer gets a viable task model route

Task model routing architecture Architecture diagram showing an active consumer declaring a ModelTask to the shared task-models control plane, which selects an explicit override or declared default profile and resolves primary then fallback routes; Pi’s effective model registry determines availability and canonical IDs, scoped models make pinned thinking authoritative, and an empty scope falls back to Pi’s full model registry; viable routes return to the consumer and failures remain visible as TaskRouteError. SHARED TASK-MODELS CONTROL PLANE CONFIG REGISTRY RULES NO VIABLE CONSUMER Active consumer extension OWNS MODELTASK DECLARATION registerModelTask(ModelTask) SELECT Effective task profile EXPLICIT TASK OVERRIDE OR DECLARED DEFAULT PROFILE Selected profile PRIMARY + FALLBACK MODEL THINKING LEVEL FOR EACH RESOLVE Route resolver PRIMARY FIRST FALLBACK SECOND RETURN Consumer receives routes VIABLE PRIMARY → FALLBACK CANONICAL MODEL + THINKING PI Effective model registry SCOPED MODELS PINNED THINKING IS AUTHORITATIVE EMPTY SCOPE → FULL PI REGISTRY AVAILABILITY + CANONICAL IDS CONFIG Task-models config PROFILES + TASK OVERRIDES ONLY TASK-MODELS WRITES ERROR Visible TaskRouteError CONFIG · PROFILE · NO-ROUTE RUN /TASK-MODELS OWNERSHIP Only task-models writes config. Consumers use its API. PRIMARY → FALLBACK · FAILURE STAYS VISIBLE