Best-fit conditions
An AI feature, RAG system, copilot, reviewer, or agent is approaching production, enterprise review, or a consequential expansion.
Not a fit when
- No bounded AI use case, system state, or decision owner has been named.
- Representative inputs, domain reviewers, or access to the current workflow are unavailable.
- The buyer expects formal certification, legal advice, penetration testing, or a guarantee of accuracy.
- The request is primarily 24/7 operations, incident response, or unbounded implementation support.
What the buyer receives
- AI use-case, system, model, vendor, and data-source inventory
- Current-state architecture and data-boundary diagram
- Representative golden, edge, adversarial, refusal, and access cases
- Baseline evaluation results and failure taxonomy
- Human-review, escalation, override, and blocked-action matrix
- Release criteria, unresolved-risk register, and 90-day plan
- Technical system card and executive readout
- AI system intake and release decision record suitable for continued lifecycle review
Delivery sequence
- Frame the use case, decision owner, system boundary, and failure consequences.
- Inventory the application, data, models, prompts, vendors, users, and authority paths.
- Build and execute representative evaluation cases against the agreed system state.
- Separate retrieval, grounding, access, workflow, cost, latency, and human-review failures.
- Define release, remediation, rollback, and evidence-retention conditions.
- Deliver the evidence package and an explicit proceed, narrow, remediate, or stop recommendation.
Decision value
- A shared picture of the system and its authority boundaries
- A measured baseline rather than demo impressions
- Known failure categories and unresolved questions
- Explicit human-review and escalation responsibilities
- A release decision with acceptance and rollback criteria
- Reusable technical evidence for leadership and procurement review
Client responsibilities and scope assumptions
Client responsibilities
- Name a business decision owner and a technical owner
- Provide public-safe discovery context before secure access is established
- Provision approved access to representative system artifacts and test environments
- Provide domain reviewers for case selection and result calibration
- Review deliverables and identify disputed or unknown behavior promptly
Scope assumptions
- One named decision owner and one named technical owner
- A bounded system or workstream with timely access to representative evidence
- Public-safe qualification before confidential material is exchanged
- Client reviewers available for domain questions, disputes, and acceptance
Explicit exclusions
- Full product redesign or unlimited remediation
- Production deployment outside the agreed scope
- 24/7 operations, on-call support, or incident response
- Penetration testing, formal bias audit, legal advice, or certification
- A guarantee of accuracy, compliance, procurement approval, or threshold achievement
Acceptance and commercial boundary
Acceptance: Accepted when the named artifacts are delivered for the agreed system state and the final review is completed. Acceptance is not contingent on a future release, audit, sale, or business outcome.
Commercial boundary: The starting investment assumes one bounded use case, one primary system path, representative evidence, and timely client access. Additional systems, regulated-data handling, extensive remediation, or custom implementation require a written change or separate statement of work.
Public commercial starting investment only. Government and subcontract pricing depends on the solicitation, labor structure, flow-downs, security requirements, and negotiated scope.