# Sovereign AI Workstation: Comparison and Acceptance Kit

Version: October 5, 2026

Companion article: https://jwatte.com/blog/sovereign-advantage-dedicated-ai-workstation/

This worksheet helps you compare an existing workstation, an office server, a cloud VM and a dedicated server. It is not an installer, an assurance of lower costs, or permission to migrate production before testing.

## 1. Describe the actual workload

Record the tasks that matter, how often they run, how long they take, and which may run together. Include the browser, model inference, source indexing, code builds, database work, backup and any scheduled automation. A count of installed tools is not a concurrency test.

| Workload | Frequency | Typical input | Completion target | Consequence of failure |
|---|---|---|---|---|
| Local extraction or retrieval | | | | |
| Interactive coding | | | | |
| Browser work | | | | |
| Build and preview deployment | | | | |
| Backup and restore | | | | |
| Scheduled job | | | | |

## 2. Compare real offers

Record exact CPU model, physical and logical cores, assigned VM resources, memory, usable storage after mirroring, network terms, location, support lifecycle, setup costs and minimum commitment. For a VM, record whether it is burstable and what happens when credits are exhausted. Do not infer those properties from the word cloud.

For a local machine, include power, cooling, internet upload capability, remote access, update policy, replacement cost and downtime arrangements. A machine you already own has different economics from one you must buy.

For rented hardware, include subscriptions, external API usage, encrypted backup storage, taxes, setup fees and administration time. Compare the same workload and billing period. Do not describe local inference as free merely because no model API is charged.

## 3. Record model fit and response quality separately

Record the exact model and quantization, weight file size, runtime version, context allocation, maximum output, parallel requests, CPU quota, actual CPU affinity and available memory. File size is not peak request memory. A requested thread count is not pinning.

Test a short task, a realistic document, a missing value, a contradiction, an unsupported question and an embedded instruction attempting to change the task. Keep a set of cases that you do not use while tuning prompts.

For each run, retain total latency, loading time, prompt tokens, output tokens, generation duration, peak resource use, result validation and the supporting source. Label cold and warm runs. Repeat combined browser, build and model workloads before claiming they coexist without degradation.

## 4. Establish data and billing routes

| Route | Allowed material | Credential type | Budget or allowance | Failure behavior |
|---|---|---|---|---|
| Local model | | Local service access | Server capacity | |
| Native interactive subscription | | Provider supported account login | Account limits | |
| External model API | | Restricted gateway and provider keys | Explicit API budget | |
| Image generation | Generic approved creative brief | Provider API | Explicit generation budget | |

A provider fallback needs separate approval for its data destination, capabilities and cost. Honor rate limits. Do not transfer subscription tokens into an API gateway. Do not assume a noninteractive script uses the same billing category as an interactive native session.

## 5. Make knowledge traceable

Preserve the original documents and a transfer manifest. Create a separately screened retrieval copy. Record source path, hash, extraction method, version, chunk boundaries and redactions. Keep credentials out of the searchable material.

Compare imported note paths with indexed note paths. Count actual notes, not a transfer manifest accidentally indexed alongside them. List every exclusion and review it. An excluded document may need safe redaction rather than permanent removal from the knowledge workflow.

Give current operational records precedence over older copies when answering current state questions. Keep historical notes for historical questions. Show evidence and a missing information state instead of inventing an answer.

Document whether search is lexical, semantic or combined. An installed vector database is not proof that the application uses embeddings.

## 6. Design resumable work

Use a durable operation identifier for actions that must not repeat. Record accepted, running, completed, interrupted and failed states. A browser disconnect should not determine whether a server job continues.

Distinguish safe retries from repeated side effects. Preserve the last successful step, honor retry timing, bound attempts and show any provider change. Never turn a failed command into a successful status simply because an old homepage still returns HTTP 200.

## 7. Verify remote access

Test unauthorized access, the real owner sign in, account expiry, app switching, phone lock, orientation changes, keyboard input, copy and paste, file destination and reconnect. Keep a separate recovery path. Do not expose browser debugging or internal model administration ports publicly.

Shared application credentials are not universal provider SSO. Test the actual browser profile and native client account separately. Preserve browser sandboxing.

## 8. Prove recovery before retiring the old environment

Back up sources, required configuration, database exports and the relevant persistent application data to an independent encrypted destination. Keep the recovery key accessible without the machine being retired.

Restore a file and database into an isolated location. Verify content and application use, not merely that an archive can be listed. Test backup recurrence, retention, failure reporting and the saved work maintenance procedure.

Keep source recovery gaps and untested scheduled jobs visible. Retire the old environment only after its remaining dependencies are removed and the owner makes a separate decision.

## 9. Completion record

| Item | Result | Date | Evidence | Still open |
|---|---|---|---|---|
| Hardware and billing comparison | | | | |
| Model response and source checks | | | | |
| Combined workload test | | | | |
| Native accounts and API routes | | | | |
| File transfer and knowledge coverage | | | | |
| Duplicate safe recovery | | | | |
| Mobile and external login acceptance | | | | |
| Independent restore | | | | |
| Final migration decision | | | | |

Use PASS, FAIL, NOT TESTED or BLOCKED with a reason. Preserve failures and their later corrections. Never add unrelated test counts together and present them as a single system accuracy score.

## Reference material

* Recorded article evidence: https://jwatte.com/downloads/sovereign-advantage-evidence.json
* Foundation: https://jwatte.com/downloads/sovereign-ai-setup-guide.md
* AWS CPU behavior: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
* Ollama configuration: https://docs.ollama.com/faq
* LiteLLM reliability: https://docs.litellm.ai/docs/proxy/reliability
* Claude Code plans: https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan
* Claude Agent SDK plans: https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan
* Codex plans: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

This kit contains no provider secrets, private account records, customer documents or executable deployment steps. Verify current product documentation and the actual account before implementation.