Model tier discipline
fix(applications,systems,patterns): correct app-orchestration-command misattribution, retire 2 redundant articles
@@ -6,6 +6,7 @@ category: patterns type: topic content_type: topic quality: complete index_group: collaboration-and-editorial-workflow short_description: "The discipline for routing work to the appropriate AI model tier — deep-think, implementation, or mechanical — to match model capability to work shape and control inference cost." status: active bcsc_class: public-disclosure-safe @@ -15,7 +16,7 @@ cites: [] paired_with: model-tier-discipline.es.md --- **Correction (2026-08-02):** the Doorman does not implement this deep-think/implementation/mechanical taxonomy. The real Doorman tier enum (`service-slm/crates/slm-core/src/tier.rs`) is `Local` (Tier A, on-host inference)/`Yoyo` (Tier B, burst GPU)/`External` (Tier C, external API) — an AI-inference-*backend* routing scheme, confirmed by both `reference/service-slm-operationalization-plan.md` and `ai/doorman-protocol.md`, neither of which mentions "deep-think"/"mechanical." The concept this article actually describes is real, but it's this very Foundry *workspace's own internal* practice for routing AI-development-session work to different Claude model tiers by task shape — `conventions/model-tier-discipline.md` in the workspace root — not something the customer-facing Doorman implements. Same misattribution pattern already found in `systems/app-orchestration-command-branch-model.md` (Foundry-internal tooling described as a PointSav product). **Flagged, not resolved.** **Correction (2026-08-02):** the Doorman does not implement this deep-think/implementation/mechanical taxonomy. The real Doorman tier enum (`service-slm/crates/slm-core/src/tier.rs`) is `Local` (Tier A, on-host inference)/`Yoyo` (Tier B, burst GPU)/`External` (Tier C, external API) — an AI-inference-*backend* routing scheme, confirmed by both `reference/service-slm-operationalization-plan.md` and `ai/doorman-protocol.md`, neither of which mentions "deep-think"/"mechanical." The concept this article actually describes is real, but it's this very Foundry *workspace's own internal* practice for routing AI-development-session work to different Claude model tiers by task shape — `conventions/model-tier-discipline.md` in the workspace root — not something the customer-facing Doorman implements. Same misattribution pattern found and corrected elsewhere in this corpus (Foundry-internal tooling described as a PointSav product) — see [[five-stage-supply-chain]] and [[scaling-coordinated-development-totebox-archives]] for the resolved cases. **Flagged, not resolved** for this specific article. A platform that routes all inference work through the highest-capability model available regardless of work shape spends significantly more per output than necessary. Model tier discipline is the routing discipline implemented by the [[service-slm-operationalization-plan|compute routing architecture]] through the [[doorman-protocol|Doorman service]]. A platform with no guidance on model selection leaves each contributor to make independent choices that may be inconsistent, cost-inefficient, or both. Model tier discipline is the structured approach that matches work shape to model capability, routes appropriate work to lower-cost tiers, and makes the routing decision explicit and reviewable.