This skill should be used when the user asks about "local models", "custom models", "fine-tuning", "self-hosting models", "model selection", "which model should I use", "data privacy and models", "LoRA", "RAG vs fine-tuning", "Ollama", "vLLM", or wants guidance on whether to build, host, or customise their own AI models.
Scanned 5/27/2026
Install to Claude Code
npx -y skills add Habitat-Thinking/ai-literacy-superpowers --skill model-sovereignty --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Model Sovereignty?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/habitat-thinking-model-sovereignty)More formats (shields.io, HTML) on the badges page.
---
name: model-sovereignty
description: This skill should be used when the user asks about "local models", "custom models", "fine-tuning", "self-hosting models", "model selection", "which model should I use", "data privacy and models", "LoRA", "RAG vs fine-tuning", "Ollama", "vLLM", or wants guidance on whether to build, host, or customise their own AI models.
---
# Model Sovereignty
Model sovereignty is the practice of making deliberate decisions about
which models to use, where they run, and whether to create custom
models. It extends the framework's Theme #2 (Agency and Sovereignty)
into the model layer.
This skill guides practitioners through the decision framework from
cross-cutting Theme #17 and Appendix P of the framework.
## The Decision Hierarchy
Exhaust simpler approaches before escalating complexity. Each step
adds maintenance burden.
1. **Prompting + context engineering** — the default. Most teams
underestimate how far this carries them. Exhaust it first.
2. **RAG** — when the limitation is knowledge (volatile, large, or
frequently changing information).
3. **Fine-tuning (LoRA/QLoRA)** — when the limitation is behaviour
(consistent domain-specific patterns at scale).
4. **Distillation** — when the limitation is size or speed (edge
deployment, latency-sensitive applications).
5. **Local hosting** — when the limitation is privacy, cost at scale,
or independence from vendor defaults.
## The Decision Framework
Walk through these questions in order. Stop at the first "yes."
**Does your data require local processing?**
PII, regulated data, trade secrets, or data subject to residency
requirements → local hosting is non-negotiable for those interactions.
Consult `references/decision-framework.md`.
**Does knowledge change frequently?**
Information changing weekly/monthly → add a RAG layer regardless of
hosting choice. RAG updates instantly; fine-tuning requires retraining.
**Does the model need consistent domain behaviour at scale?**
Reliable format compliance, style consistency, or decision logic across
thousands of requests → fine-tune with LoRA/QLoRA. Consult
`references/technique-comparison.md`.
**Is baseline load above the break-even threshold?**
~30M tokens/day sustained → self-hosted inference is economically
justified within 4 months. Consult `references/hosting-options.md`.
**None of the above?**
Use cloud API models with good prompting and context engineering.
## The Sovereignty Test
Ask: "If my API provider changed pricing, rate-limited me, or
discontinued my model tomorrow, what would happen?"
A sovereign engineer has an answer:
- A fallback model identified and tested
- Specifications precise enough to regenerate with any capable model
- Local alternatives evaluated for critical workflows
- Data classification that determines what can route where
## Getting Started
**For data sovereignty:** Start with data classification. List every
type of data that flows through your AI interactions. Classify each
as Public, Internal, Sensitive, or Restricted. Update MODEL_ROUTING.md
with routing rules based on classification.
**For cost sovereignty:** Calculate your monthly token usage. Compare
API costs against self-hosted alternatives at your volume. The
break-even is typically 30M tokens/day sustained.
**For domain sovereignty:** Identify your three most common AI failure
modes. If failures come from missing knowledge → evaluate RAG. If
failures come from inconsistent behaviour → evaluate fine-tuning. If
failures come from reasoning capability → stay on frontier APIs with
better prompting.
**For operational sovereignty:** Identify your vendor dependency. Could
you switch providers in a week? A month? Never? The answer determines
your urgency.
## Maintenance Awareness
Custom models accumulate maintenance debt. Budget for:
- Model versioning (pin versions, test before updating)
- Retraining cadence (quarterly for fine-tuned models)
- Drift detection (monitor output quality metrics)
- Exit strategy (every custom model should have a fallback)
For detailed technique comparisons, hosting option evaluation, and
current-era model recommendations, consult the reference files.
No comments yet. Be the first to comment!