1. Use-case framing
Purpose, scope, and design intent for this phase.
This page documents a proposed approach for the fictional GreenBox portfolio. Decisions and outcomes are illustrative until validated against business requirements, source data, security constraints, and measured implementation results.
Design area 01
Start with bounded questions
Candidate use cases include explaining a KPI change, summarising delivery exceptions, finding inventory risks, and answering questions about approved metric definitions. These are explorations, not claims of an implemented AI system.
Design area 02
Architecture pattern
User question → identity and authorisation → approved semantic metrics or curated retrieval source → controlled query/tool execution → validation and grounding → response with metric definition, time period and source context.
Design area 03
Guardrails
Respect existing access controls; do not expose raw sensitive records unnecessarily; restrict tools and query scope; use allowlisted metrics and dimensions; validate generated SQL; apply query limits; log tool calls and outcomes.
Design area 04
Grounding and trust
Answers should state the metric definition, time window, filters, and data freshness. If the question cannot be answered from approved data, the system should say so rather than inventing a result.
2. Implementation considerations
Controls and decisions to make the design supportable, explainable, and testable.
Evaluation
Create a test set of representative business questions with expected answers, SQL/metric checks, permission tests, ambiguous-question cases, and adversarial prompts. Evaluate correctness, groundedness, latency, cost and refusal behaviour.
Human oversight
Financial or operational decisions should retain appropriate human review. AI summaries must not silently redefine KPIs or substitute for approved business processes.
Risks and mitigations
Incorrect interpretation: use governed metrics and clarifying questions. Unauthorised disclosure: enforce permissions at the data layer. Hallucinated explanations: require evidence and source context. Cost/latency: bound queries and monitor usage.
Acceptance criteria
A bounded prototype answers an agreed test set using approved metrics; respects user permissions; shows definitions and freshness; logs activity; handles uncertainty safely; and has documented limitations.
3. Acceptance criteria and handoff
Evidence required before this phase should be considered complete.
Step 10
Final outcome
A coherent enterprise data architecture from business discovery through governed reporting to a carefully controlled AI-consumption pattern.
- Requirements and assumptions are documented and traceable.
- Business owners and technical owners are identified where applicable.
- Security, quality, and operational implications are considered.
- Validation evidence is captured; proposed designs are not presented as implemented outcomes.
← Project roadmapPrevious: Step 9 · Governance, Quality & Operations