Enterprise use case and target architecture: understand the problem
- Source
- From the Staff AI System Design course
- By
- Sourav Banerjee
- Last updated
- 8 Nov 2026
Alice, a procurement analyst in Tenant A, needs to answer a supplier question using current internal policy, draft a reply, and reopen the saved result. Other employees and companies need the same workflow with their own permissions, documents, budgets, and approved processing regions. The twelve stages build the platform that supports this journey.
Read this orientation before T18.2. You do not need to understand every component yet. T18.1 previews the destination; T18.2 still starts with no system and builds the smallest useful drafting path. This is a hypothetical enterprise case. Requirements and numbers are teaching assumptions, and production integrations remain unverified.
The Customer and the People Using the Platform
An enterprise wants employees to use approved AI tools without copying confidential documents into unmanaged services. The course follows one supplier-assistance workflow inside a reusable multi-tenant Enterprise AI Platform. A tenant is one customer organisation with its own users, policy, data, and resource budget.
| Person or team | Job in the supplier workflow | Required outcome |
|---|---|---|
| Alice, enterprise user in Tenant A | Ask what confirmation is needed before promising a delivery date; prepare a supplier reply | A permitted, cited policy answer and a saved draft |
| Another employee in Tenant A | Use the same application with a different document permission set | Shared infrastructure does not expose Alice’s private history or restricted evidence |
| Tenant B and Tenant C | Run their own supplier-assistance workflows | Separate customer data and fair access to finite shared capacity |
| Tenant administrator and data owner | Connect approved sources and manage access, retention, and data purpose | Updated and deleted documents do not remain usable through stale indexes |
| Application team | Configure the supplier task, prompts, approved tools, and acceptance cases | Change behaviour through reviewed contracts rather than copied policy code |
| Release approver and model operations | Compare candidate prompts, retrieval settings, models, or adapters | Promote only a version with matching quality, safety, and lineage evidence |
| Platform and operations teams | Run shared services, budgets, regional recovery, and support | Diagnose failures, control cost, and preserve customer guarantees |
One Complete Customer Story
Alice asks, “What confirmation do we need before promising a supplier delivery date?” The source policy says written confirmation is required. She should receive that rule with the exact source version and passage, then use it to prepare a reply. She reviews the draft; actually emailing a supplier is outside the implemented course workflow.
The platform must distinguish three related actions. Drafting from approved supplied text needs no document search. Answering from enterprise policy requires authorised current evidence. Preparing or indexing a long document needs durable background execution so a browser disconnect does not lose accepted work. All three belong to the same supplier workflow, but have different completion contracts.
Without the platform, Alice manually copies text into a drafting tool and saves the result herself. The tool has no trusted view of enterprise permission changes, source versions, or the organisation’s approved model route.
Starting diagram. Text alternative: Alice manually finds policy, copies it into a tool, and saves a draft. There is no implemented enterprise platform at the start of T18.2.
Functional Requirements for the Destination
| Requirement | What the reader should expect the target system to do | Where the design grows |
|---|---|---|
| Authenticated drafting and saved history | Accept approved text, generate a draft, commit it, and let its owner reopen it | T18.2 and T18.7 |
| Long-running work | Persist accepted jobs, bound retries, and inspect failures or uncertain effects | T18.3 |
| Enterprise knowledge | Ingest changing sources, publish versioned passages, and retrieve current permitted evidence | T18.4 and T18.7 |
| Shared service at higher demand | Scale the application while bounding requests, tokens, queues, and tenant shares | T18.5 and T18.6 |
| Recoverable operations | Preserve operation identity and distinguish committed, stale, failed, and unknown outcomes | T18.8 |
| Controlled AI changes | Evaluate task and safety slices; approve immutable bundles; canary and roll back eligible routes | T18.9 |
| Model choice | Select an approved hosted route or assess a justified self-hosted alternative | T18.10 |
| Governed custom behaviour | Compare prompting and retrieval with a bounded tuning trial; track data-to-model lineage | T18.11 |
| Approved regional service | Keep data and processing inside tenant policy; recover only to an eligible regional cell | T18.12 |
| Reusable internal platform | Onboard applications through versioned contracts with named owners and controlled migration | T18.13 |
Non-Functional Requirements and Planning Targets
These requirements describe correctness, availability, latency, isolation, and cost rather than another product feature. The numbers below come from different teaching stages. They are workload scenarios, not simultaneous measurements of one deployment.
| Requirement or assumption | Illustrative target or rule | Source and limit |
|---|---|---|
| Pilot demand and latency | One active pilot user, 200 requests per eight-hour day, brief 0.5 requests/second peak; healthy p95 below five seconds | T18.2; a proposed target, not a measured service |
| Result durability | A completed saved-success response follows committed answer/history state | T18.2; the provider is outside the database transaction |
| Isolation and current access | Trusted services enforce tenant, user, resource access, approved egress, and audit | T18.7; model text cannot grant permission |
| Overload | Bound queues and independent request/token/concurrency budgets; apply explicit tenant shares | T18.6; scheduling cannot create provider capacity |
| Custom behaviour gate | At least 196 of 200 frozen schema cases pass, with zero known safety violations | T18.11; supplied fixture counts do not prove real model safety |
| Regional recovery | A/B content stays in approved EU cells; C has a US home; assumed RPO ≤60 seconds and RTO ≤600 seconds | T18.12; unavailable authority or unsafe promotion can miss the target |
| Recovery capacity scenario | Combined A/B peak of 60 requests/second, 1,000 tokens/request, and two-second active slots | T18.12; plan app replicas, token budget, and slots separately |
| Economics | Count failed attempts, idle reserve, storage/networking, and operating labour per successful workflow | T18.12 and 12; prices and savings are assumptions |
The 95th percentile, p95, is the latency threshold met by 95% of the defined measured population. Recovery point objective (RPO) bounds the acceptable data-loss window. Recovery time objective (RTO) bounds the acceptable restoration interval. A regional switch is incomplete until permitted customer work can succeed, not merely when a route changes.
Key Takeaways
- A tenant is one customer organisation with its own users, policy, data, budget and approved processing regions. Shared infrastructure must never expose one user's private history or restricted evidence to another user or tenant.
- Drafting from supplied text, answering from enterprise policy and preparing a long document are three paths with different completion contracts. They need supplied text, current authorised evidence and durable background execution respectively.
- The planning targets come from separate teaching workloads, not one deployment's measurements. The pilot assumes 200 requests per eight-hour day, a brief 0.5 requests/second peak and a healthy p95 below five seconds.
- RPO bounds the acceptable data-loss window and RTO bounds the restoration interval. A regional switch is complete only when permitted customer work can succeed, not when a route changes.