The Business-to-AI Translation Matrix

“Deltas deploy our software platforms to customers… their mandate is to achieve technical outcomes for our customers.”

Related source material Anthropic: agent evals, Awesome FDE Roadmap, and Open-source Matrix repository.

Customers rarely describe work in system-design language. They say things like, "we need an AI agent for complaints" or "this must cut cycle time in half". The FDE job is to decode that into data paths, permission models, non-goals, rollout slices, and measurable proof.

That translation layer is where many otherwise-strong engineers fail. They either jump straight to models and prompts, or they stay too vague and never force the business ask into something that can survive enterprise constraints.

What the matrix is for

• Turn executive or operator requests into a concrete AI delivery plan
• Separate what should be LLM-driven from what must stay deterministic
• Map business KPIs into engineering SLOs and evaluation gates
• Defend scope before a PoC collapses under hidden legacy complexity

The translation spine

1. Deconstruct the workflow - shadow the real operator, locate the actual bottleneck, and find the system of record
2. Decide AI vs deterministic logic - classify, summarize, extract, and retrieve with AI; keep financial, compliance, and state transitions deterministic
3. Map KPI to SLO - convert adoption, speed, safety, and ROI claims into latency budgets, eval thresholds, and rollout gates

Client discovery: 10 questions that matter on day one

1. Can I watch 3 real tasks done manually before we discuss architecture?
2. Where is the system of record today: API, DB, Excel, PDF, email?
3. What is the cost of a wrong answer: annoyance, legal exposure, or financial loss?
4. What latency budget is real: sub-second, 3 seconds, or async?
5. What user groups require strict permission isolation?
6. Is deployment public cloud, VPC, private link, or fully air-gapped?
7. Who owns the system on Day 2 after handoff?
8. What single metric decides whether the PoC is successful?
9. Which legacy systems must support writes, not just reads?
10. What is explicitly out of scope for phase one?

The matrix

KPI to SLO mapping

• “The AI cannot make reckless promises.” - enforce guardrail pass rates, faithfulness checks, and output-schema validation
• “Users will not wait.” - define TTFT and end-to-end latency budgets, then route simple tasks to smaller models
• “The ROI must work.” - set token budgets, cache strategy, and per-task cost ceilings before rollout

PoC success criteria should be written before code

The fastest way to lose control of an enterprise AI deployment is to let the PoC operate on implied success. Before building, write down the core objective, the test set, the in-scope systems, the out-of-scope legacy traps, and the thresholds that convert a demo into a production decision.

# PoC Scope & Success Criteria

## Project

- Customer:
- Lead FDE:
- Timeline:
- Core workflow:

## Objective

Describe the narrow phase-one outcome in one paragraph.

## Quantitative success criteria

- Quality threshold:
- Latency target:
- Automation-rate target:
- Safety constraints:
- Cost ceiling:

## In scope

- System A:
- Persona:
- Workflow:

## Out of scope

- Legacy write path:
- Additional personas:
- Long-tail exception handling:

## Day-2 ownership

- Customer owner:
- Runbook location:
- Escalation path:

You can also download the lightweight Markdown playbook or fork the open-source templates on GitHub.

Where this fits on FDE Hub

Use this page with the readiness assessment, the skills matrix, and case / decomp prep. Those pages test whether you can recognize the tradeoffs; this playbook shows how to document and defend them.