TFD-0006: Request Type Routing Model
TFD-0006: Request Type Routing Model
Date: 2026-03-18 Status: Accepted Decided by: Board of Directors Facilitated by: Oscar (CEO) Consulted: Oscar, Pablo, Camille, Dana
Context
The board asked "how do we test the production line?" with a real STM request: "capture requirements and produce design spec for Azure Dataset." This exposed a fundamental gap — the request was not a factory request at all. It was work for the deployed talent to do, not the factory.
The factory builds digital talents. Deployed digital talents do work for clients. These are different things with different routes.
Decision
Four request types, each with a distinct routing path:
| Type | Description | Route |
|---|---|---|
| Type 1 | New talent, new client | Full 9-stage pipeline |
| Type 2 | New talent, existing client | 9-stage pipeline, abbreviated intake (client context already known) |
| Type 3 | Enhancement to deployed talent | Lightweight pipeline — delta only (requirements, build, QA, deploy) |
| Type 4 | Work request for deployed talent | Goes directly to the talent, NOT the factory |
Client Context Registry
To support Type 2 (abbreviated intake) and track deployed talents per client, a client registry is established at production-lines/clients/{client-slug}/:
profile.md— Company profile, contacts, systems, methodology, toolsdeployed-talents.md— Registry of deployed digital talentshistory.md— Engagement log
Type 4 Clarification
When a client says "capture requirements for Azure Dataset," that is the deployed EA talent doing its job — using its /ea-exigences-intrant skill. The factory is not involved. The factory only activates for Types 1-3.
Consequences
- Factory pipeline now handles 3 request types (1, 2, 3) with clear routing
- Type 4 requests are explicitly out of scope for the factory
- Client context persists across engagements, enabling abbreviated intake for returning clients
- Enhancement pipeline (Type 3) template deferred until first Type 3 request arrives