tenantplaneBook a demo Illustrative example. This is a fictional planning scenario, not a customer case study, a tested architecture, or a completed Tenantplane deployment.
The requirement
A B2B document-assistant vendor has a customer requesting deployment inside its cloud account. The application currently calls an external model API. The customer asks that inference, document processing, retrieval, and associated logs stay inside the agreed environment.
The assessment covers one application and one target account. It does not assume that substituting an open-weight model will preserve task quality. That question requires representative evaluation in a pilot.
Architecture and dependencies
| Component | Proposed location | Decision still needed |
|---|---|---|
| Application API | Customer environment | Supported installation target and ingress |
| Model inference | Customer environment | Model license, quality, runtime, GPU availability |
| Embedding and retrieval | Customer environment | Embedding model, index storage, document permissions |
| Identity | Customer identity provider | Protocol, service accounts, role mapping |
| Model artifacts | Approved local registry/storage | Distribution rights, transfer process, version pinning |
| Logs and metrics | Agreed customer tools | Sensitive-field redaction, retention, diagnostic export |
| Updates | Versioned release artifacts | Import, validation, approval, rollback |
Every network dependency needs a decision. Model downloads, certificate validation, identity, license checks, package registries, and error reporting can all affect the boundary. An assessment should expose unresolved dependencies rather than silently assume internet access.
Responsibility matrix
This is a proposed division to review with the actual customer and software vendor.
| Work | Proposed accountable owner | Required input |
|---|---|---|
| Provision compute, storage, and networking | Customer infrastructure owner | Resource and access specification |
| Package the application and model runtime | Software vendor | Versioned application and supported dependency list |
| Approve access and outbound paths | Customer security owner | Dependency map and account permissions |
| Run installation and acceptance checks | Named implementation owner | Approved environment, workload, acceptance plan |
| Operate backups and incident response | Customer or separately contracted operator | Runbook, escalation path, service expectations |
| Approve release updates | Agreed customer change owner | Release notes, compatibility tests, recovery steps |
For each row, the final engagement records a named owner. “The team” is not specific enough for a recovery or access request.
Risks that need a pilot decision
- Model quality: the open-weight candidate may not meet the application’s existing quality baseline. Compare on a permissioned representative task set.
- Document authorization: login alone does not establish which documents an individual can retrieve. Test authorized and unauthorized cases.
- Capacity: concurrency and context length may require different hardware from a developer’s proof of concept. Benchmark the actual workload before committing to a throughput target.
- Dependencies: an external service may have no suitable replacement within the customer’s restrictions. Resolve or explicitly exclude it.
- Recovery: restoring a database and rolling back an application image may have different compatibility requirements. Test the complete recovery path.
Cost assumptions
The cost sheet separates implementation labor, infrastructure, licensing, ongoing operation, and recurring compatibility work. It identifies which party pays for each category and marks every unverified rate or capacity assumption.
An estimate without a workload profile is a planning range. It becomes a deployment budget only after hardware, provider pricing, runtime behavior, and the operating agreement have been validated. See the private deployment cost guide for a worked hypothetical example.
Pilot acceptance criteria
Each check should record the method, observed result, supporting artifact, and owner.
| Check | Proposed evidence |
|---|---|
| Reproducible installation | Clean-environment install log with exact versions |
| Application behavior | Results against an agreed representative task set |
| Access controls | Positive and negative authorization test results |
| Network boundary | Approved egress inventory and test observations |
| Update and recovery | Upgrade plus recovery rehearsal, including state |
| Operator handover | Customer operator completes a documented routine task |
The pilot scope includes one target environment. Additional clouds, versions, models, or hardware configurations expand the validation work and need an explicit decision.
What the decision should say
The written conclusion is one of: proceed with the defined pilot, resolve specific blockers first, or do not proceed under the current constraints. The value of an assessment is a grounded decision; a recommendation to deploy at any cost is not useful.
This fictional example illustrates the kinds of findings a readiness sprint can contain. It is not a client case study, an executed assessment, or a guarantee of these conclusions for another application. Review the proposed $2,500 readiness sprint and the separate private workflow implementation.