Service Lines
The four service lines the factory delivers. Each has a standard production process, deliverable contract, and publishing target. Pick the right line at request creation — everything downstream follows.
Consulting / Process Review
ActiveAudit, redesign, or formalize a client's (or the factory's own) **process** — not build a talent, not catalog architecture, but improve how work is done.
Enterprise Architecture
ActiveTake a client's existing IT/business landscape (or planned transformation) and produce a structured **LeanIX-aligned catalog** + **interactive HTML diagrams**, **published directly to the client's website (JCT portail)** by the EA digital talent itself.
R&D / Evaluation
ActiveTake a candidate (tool, framework, MCP server, plugin, market trend, methodology) and produce a **structured evaluation** with a Go / No-go / Hold decision.
Talent Factory Build
ActiveTake a client's specific need ("we want an AI that does X for our team Y") and **manufacture a digital talent** through the 9-stage production line, ending with a deployable package the client runs themselves.
Service Lines
The Talent Factory delivers four distinct service lines. Each is its own standardized product with a defined intake form, production process, deliverable contract, and publishing target. Pick the right line at request creation — everything downstream (template, assignee, methodology, publishing) follows.
| Line | One-liner | Primary deliverable | Lead role | Status |
|---|---|---|---|---|
| Enterprise Architecture | Catalog + diagram a client's IT/business landscape using LeanIX methodology, publish to JCT portail. | LeanIX CSV catalog + interactive HTML diagrams | Edward (Enterprise Architect, agent-ea) | Mature — reference pattern |
| Talent Factory Build | Build a new custom digital talent for a client's use case (e.g., a PLB-specific extraction agent). | Deployed digital talent package | Production line operators | Active — 3 talents shipped |
| Consulting / Process Review | Process audit, lifecycle design, methodology work on the client's own operations. | Process design memo + decision record | Philippe (Process Consultant) | Active — REQ-CONS pipeline |
| R&D / Evaluation | Evaluate a tool, framework, market, or trend for adoption — internal or for client. | Eval scorecard + Go/No-go decision | Riley (R&D Analyst) | Active — RD pipeline |
How a request maps to a service line
When a request lands (intake via REQ-CONS-006 lifecycle):
- Camille (intake) classifies which service line it belongs to using the One-liner / Primary deliverable column above.
/request-createis invoked with the matching template (--service=ea,--service=talent,--service=consulting,--service=rd).- The request folder is scaffolded with the line-specific structure (inputs, process, output expectations).
- The lead role for that line is auto-assigned.
- Production follows the service line's standard process.
- Publication follows the service line's standard target.
Why this matters
Without standard service lines, every request is bespoke — we re-decide structure, process, and publishing for each one. With them:
- Clients get predictable deliverables (they know what they're buying).
- The factory gets repeatable production (we know how to build it).
- The intranet renders consistent views per line (Architecture catalog, Talent spec, Process review, Evaluation card).
- New requests pick a line and inherit everything.
See also
/request-create— scaffolds a new request, asks for service line first- TFD-009 — request/order folder standard
- TFD-017 — JCT portail architecture (publishing target for EA + Talent lines)
- REQ-CONS-006 — intake lifecycle design (governs how requests reach a service line)