---
title: "Discovery decision package | YPAI"
url: https://ypai.ai/ai-implementation/discovery-and-architecture/decision-package/
description: "What a YPAI discovery engagement delivers: the eight records of the architecture decision package, how they are produced and how the cost is modelled."
source: "src/copy/routes (route /ai-implementation/discovery-and-architecture/decision-package/)"
---

# The decision package: eight records

> What a YPAI discovery engagement delivers: the eight records of the architecture decision package, how they are produced and how the cost is modelled.

One control document for the build.

- Each engagement produces a decision package that product, engineering, security, legal, finance and operations teams can use to approve, build, test or reject an implementation.

## What each team receives

### Product and operations

- The operating workflow specification and the implementation roadmap: users, actors, triggers, inputs, decisions, outputs, exceptions, handoffs, the current baseline and the intended business outcome; the pilot boundary, production sequence, work packages and decision owners.

### Engineering

- The system and integration architecture, the data and knowledge readiness record and the evaluation plan: channels, identity, models, routing, context, memory, tools, APIs, events, source systems, error handling and human checkpoints; sources, permissions, quality, coverage and identified gaps; the representative task set, metrics, thresholds, graders and regression gates.

### Security, legal and finance

- The automation and authority boundary, the security and governance controls and the unit economics: what the system may retrieve, recommend, generate, decide, execute, approve, escalate or never perform autonomously; threat model, access boundaries, policy enforcement, logging, oversight, incident handling, rollback and change control; expected demand, model consumption, infrastructure cost, operating effort and cost per accepted outcome.

## Decision-ready outputs

- The implementation roadmap carries scope ready for a statement of work: work packages, dependencies, decision owners and handoff requirements.

## What your team can build from

- The workflow specification, architecture record, evaluation plan, control model and implementation backlog are designed to support handoff.
- The architecture record can also be handed to your internal team or another implementation partner.
- Discovery does not require a downstream build commitment.

## What will be built, and what will not

- The package states what will be built and what will not. The authority boundary records what the system may never perform autonomously; the roadmap records the pilot boundary and what depends on shared infrastructure.

## Operating workflow specification

- Users, actors, triggers, inputs, decisions, outputs, exceptions, handoffs, current baseline and intended business outcome.

## Automation and authority boundary

- What the system may retrieve, recommend, generate, decide, execute, approve, escalate or never perform autonomously.

## Data and knowledge readiness

- Sources, ownership, permissions, rights, quality, coverage, structure, freshness, residency, retrieval suitability and identified gaps.

## System and integration architecture

- Channels, identity, models, routing, context, memory, tools, APIs, events, source systems, error handling and human checkpoints.

## Evaluation and acceptance plan

- Representative task set, edge cases, adverse cases, metrics, thresholds, graders, human review rules and regression gates.

## Security and governance controls

- Threat model, access boundaries, policy enforcement, logging, oversight, incident handling, rollback and change control.

## Unit economics and capacity model

- Expected demand, throughput, latency, model consumption, infrastructure cost, operating effort and cost per accepted outcome.

## Implementation roadmap

- Pilot boundary, production sequence, dependencies, work packages, decision owners, handoff requirements and scope ready for a statement of work.

Every major decision is recorded with its rationale, assumptions, dependencies, rejected alternatives and conditions for reassessment.

The architecture record becomes the control document for the build.

## Inspect the real operating environment.

Depending on scope, YPAI may review:

- workflow documentation and standard operating procedures

Working sessions resolve open decisions and validate findings.

## What the finished system will cost to run.

- Token price alone does not describe whether an AI system is economically viable.
- YPAI models the cost of the full operating path:
- The primary economic unit is tied to the workflow, such as cost per accepted document, resolved case, completed request, approved action or successful customer interaction.
- Architecture alternatives are compared against both performance and cost per accepted outcome.
- A cheaper model that creates more failures, review work or retries is not necessarily the lower-cost system.

## Frequently asked questions

### What happens when required data is missing?

YPAI identifies the gap and specifies the collection, sourcing, annotation, curation or evaluation work needed. That work can be delivered separately through AI Data & Evaluation or connected to the implementation engagement.