C.01Title
Four dimensions of “local”
One model shows why “we run AI locally” answers a quarter of the trust question. The other three quarters are lineage, configuration, and policy definition.
C.02Custody record
| Base model | DeepSeek-R1, developed in China | Evidence verified |
| Post-training | Perplexity, to reduce refusals and political bias on China-sensitive topics | Supplier-declared |
| Distribution | Ollama library; local inference feasible: 70B ≈ 43 GB, 671B ≈ 404 GB | Evidence verified |
| Data egress when run locally | Depends on runtime, network and logging configuration, not on the model name | Review required |
| Resilience-policy status | Depends entirely on whether the policy’s definition includes base-model lineage | Review required |
Source: Ollama: r1-1776
C.03Four questions
Four questions that look like one
- Is it de-censored? Post-training changed refusal behavior on China-sensitive topics. That is a behavior property. It says nothing about where the model came from or where your data goes.
- Is it local? The weights can run on your own hardware. Locality is a deployment property. A locally run model with telemetry enabled still leaks, and a hosted model under contractual controls may leak less.
- Does data leave? A configuration property of the runtime, network and logs. Verifiable per installation, never assumable from the model name.
- Does it meet the resilience policy? That depends on a definition the buyer must make explicit. If base-model development origin and weight lineage are in scope, r1-1776 cannot auto-pass (its base is DeepSeek-R1), no matter who post-trained it or where it runs.
Boundary
Nothing here rates r1-1776 as good or bad. It is a documented example of why a model inventory must record base developer, weight source, post-training organization, runtime and data configuration as five separate fields. A policy that cannot answer question four for this model is not yet a policy.