Process: Feasibility Assessment

Owner: Client Intake Manager (Camille) Type: Manual Frequency: Per new client engagement (after requirements gathering)

Purpose

Determines whether the factory can deliver what the client needs — before making any commitment. Prevents the factory from accepting work it cannot complete on time, within budget, or to the required quality standard. The feasibility assessment is a gate: production does not begin until feasibility is confirmed.

When to trigger

• After the requirements document is substantially complete (Sections 1-8 of the requirements template filled in)
• Before any scope commitment or client agreement is signed
• When a client's request changes significantly during intake (re-assess)

Steps

1. Technical feasibility — consult CTO (Clara)

Question: Can the factory technically build what the client is asking for?

Check with Clara:

• Are the requested capabilities achievable with current LLM technology?
• Are there known technical limitations that would prevent delivery?
• Does the request require capabilities outside the factory's current tooling?
• Are there security or compliance requirements that affect the technical approach?

Record:

• Verdict: Feasible / Feasible with conditions / Not feasible
• Conditions (if any): what needs to change or be added
• Technical risks identified

2. Pattern availability — consult Agentic Pattern Designer (Ada)

Question: Do we have established patterns for the requested capabilities?

Check with Ada:

• Do patterns exist in the catalog for the primary capabilities?
• Are the requested interactions (multi-step, tool use, conversation, etc.) covered by known patterns?
• Would new patterns need to be designed? If so, how much effort?

Record:

• Patterns available: list matched patterns
• Gaps: capabilities with no existing pattern
• Effort estimate for new patterns (if needed)

3. Architecture assessment — consult Enterprise Architect (Elena)

When: Required for complex requests. Skip for straightforward, single-purpose digital talents.

A request is complex when:

• It requires integration with 3 or more external systems
• It involves multi-agent coordination
• It has strict security or compliance requirements
• It requires a novel architecture not previously built

Check with Elena:

• Does the request fit within a known architecture pattern?
• Are the integration points feasible and well-understood?
• Are there architectural risks (scalability, reliability, data flow)?

Record:

• Architecture assessment: Standard / Complex / Novel
• Risks identified
• Recommendations for production

4. Timeline feasibility — consult Production Line Architect (Pablo)

Question: Can the factory deliver within the client's timeline?

Check with Pablo:

• Does an appropriate production line exist for this type of digital talent?
• What is the estimated production time?
• Are there current capacity constraints (other engagements in progress)?
• What is the realistic delivery date?

Record:

• Production line: existing / needs creation
• Estimated production time
• Capacity: available / constrained
• Realistic delivery date vs. client requested date

5. Compile feasibility report

Combine all findings into a single feasibility report.

Report structure:

# Feasibility Report — [Client Name]

**Date:** [date]
**Assessor:** Camille (Client Intake Manager)

## Summary verdict

[Feasible / Feasible with conditions / Not feasible]

## Technical feasibility
- Verdict: [pass/conditional/fail]
- Notes: [findings from Clara]

## Pattern availability
- Verdict: [pass/conditional/fail]
- Available patterns: [list]
- Gaps: [list]
- New pattern effort: [estimate]

## Architecture assessment
- Verdict: [standard/complex/novel]
- Risks: [list]
- Recommendations: [list]
(or: Skipped — straightforward request)

## Timeline feasibility
- Client requested: [date]
- Realistic estimate: [date]
- Verdict: [on track / tight / not achievable]
- Capacity: [available / constrained]

## Overall risk assessment
| Risk | Severity | Mitigation |
|------|----------|------------|
| | | |

## Recommendation
[Clear recommendation: proceed / proceed with conditions / decline]
[If conditions: list what must be true before commitment]

6. Act on the verdict

• Feasible: Proceed to scope definition (Step 5 of intake process)
• Feasible with conditions: Communicate conditions to the client. If client accepts conditions, proceed. If not, re-scope or decline.
• Not feasible: Communicate honestly to the client. Explain why. Suggest alternatives if possible (e.g., reduced scope, different timeline, referral to another provider). Close the intake.

Quality gate

A feasibility assessment is complete when:

• Technical feasibility checked with Clara
• Pattern availability checked with Ada
• Architecture assessed (or explicitly skipped for simple requests)
• Timeline feasibility checked with Pablo
• Feasibility report compiled with clear verdict
• Recommendation is actionable (proceed / conditions / decline)
• Client informed of outcome

Turnaround target

Feasibility assessment should be completed within 1 business day of having a substantially complete requirements document. This supports the overall < 2 day intake turnaround target.