Frontier Inference Without Frontier Custody

The distinctions that keep the model honest

Inference is not retention.

Retention is not training.

Training is not disclosure.

Local execution is not necessarily local inference.

Local source custody does not necessarily mean zero data egress.

No-training commitments do not necessarily mean zero retention.

Deleting a chat is useful hygiene, not the primary privacy boundary.

Sanitization must address combinations of facts, not merely direct identifiers.

Model output may be more sensitive than model input.

Approval to reason does not authorize deployment, merge, publication, external communication, regulated action, or Production change.

Provider approval applies to a specific processing path, not to a provider in the abstract.

Evidence should prove the controls without creating another uncontrolled copy of the sensitive corpus.

These distinctions prevent a familiar category error. A local program can read a repository, select a few passages, and call a remote model. The repository remained local, but selected content crossed the boundary. A provider may promise not to train on that content while retaining it for another bounded period. A session may be deleted while logs, abuse-monitoring records, memory, connectors, or derived outputs follow separate rules. None of those conditions is necessarily unacceptable. They are different conditions, and the architecture must name them precisely.

Public-site privacy boundary

Assessment answers remain in transient browser memory for the current page only. The guide stores no assessment answers in cookies, local storage, session storage, IndexedDB, URL parameters, hidden form fields, or persistent history. It transmits no assessment answer through requests, analytics, embeds, third-party scripts, beacons, or error reporting.

The page requires no login, accepts no file upload, connects to no repository, requests no organization or project names, requests no source content, requests no provider credential, and contains no hidden assessment telemetry. Reset clears every answer and returns focus to the first question. Native controls preserve keyboard operation. The result and full guide can be printed without JavaScript.

The global SharePlane theme preference is separate shell state. It records only the reader’s light or dark presentation choice and contains no assessment answer.

Re-identification and sensitive inference

Removing names does not prove anonymity.

Review combinations of dates, ranges, roles, geography, exact values, technology combinations, event sequences, searchable phrases, terminology, public information, industry knowledge, insider knowledge, provider account context, prior sessions, memory, and connectors.

The review has five outcomes:

• Acceptable — no unresolved critical risk and remaining combination risk is within the approved threshold.
• Acceptable with controls — the task may proceed only with named compensating controls, an owner, and an expiry.
• Additional reduction required — the package must be changed and reviewed again.
• Local inference required — the reasoning task may proceed only inside the controlled environment.
• Stop and escalate — classification, approval, regulated authority, retention, or re-identification risk remains unknown or unacceptable.

A single critical risk overrides any aggregate score. Unknown is not Low.

Model output receives an independent review. Ordinary facts can produce a sensitive ranking, diagnosis, legal conclusion, vulnerability path, strategic conclusion, or identity inference even when no single input looked sensitive.

Provider and endpoint assessment

Evaluate the exact path:

Provider + Product + Endpoint + Model + Account type + Feature configuration + Region + Retention profile + Processing purpose + Information classification

For every provider-specific claim, record the provider, product or feature, account type, authoritative source, source date, retrieval date, applicable claim, and review due date. Treat provider terms, features, retention, regional availability, memory, connectors, logging, abuse monitoring, and training posture as current evidence that can change.

A provider is not approved in the abstract. A specific processing path is approved for a specific purpose, data class, architecture, configuration, and period.

This guide contains no provider ranking, leaderboard, universal approval label, or “safe” badge. The toolkit provides an empty assessment record. An organization must populate it from current primary sources and its own authority before use.

Engineering controls

An approved architecture must fail closed.

Test that the local agent cannot read denied files, inherit unapproved credentials, exceed file or context ceilings, send to an unapproved network destination, enable an unapproved connector, persist assessment data, or perform a Production action. Test that an unavailable endpoint does not cause silent remote fallback. Test that the exact outbound preview matches the approved package hash. Test that logs and receipts prove the control result without containing source content.

Keep approval layers separate:

• approval to inspect source;
• approval to construct a minimum reasoning package;
• approval to send that exact package through one processing path;
• approval to use the output for a bounded purpose;
• approval to merge, deploy, publish, communicate externally, or take regulated action.

Passing one layer does not pass the next.

Evidence

Stable doctrine and current provider evidence remain separate.

The architecture, classification, precedence, operating sequence, privacy boundary, and controls in this Work are stable owner authority under Issue #214. Provider-specific behavior is not frozen into that doctrine. The toolkit’s provider assessment is intentionally empty. Each use must gather current primary evidence for the exact product path, record its dates, and set a review due date.

Validation evidence proves the artifact’s code and package behavior. It does not certify an organization, provider, endpoint, workload, legal conclusion, privacy program, security posture, or regulatory compliance.

Full thesis

The choice is not between frontier reasoning and privacy. The choice is between an uncontrolled custody surface and an engineered processing path.

The strongest pattern keeps authoritative source custody under organizational control, classifies everything the system can reach, reduces the source set, sanitizes locally, tests combinations for re-identification, constructs the minimum reasoning package, approves the exact endpoint and features, bounds the local agent mechanically, previews and hashes outbound context, validates output locally, and closes the loop.

Sometimes the correct result is local inference. Sometimes it is a minimized remote package. Sometimes an approved enterprise environment or cloud-hosted agent is justified. Sometimes the only defensible action is to remove prohibited information or stop and escalate.

The architecture is credible only when it names what remains local, what may cross, what may persist, what can be inferred, what the system can change, who must approve, and what evidence remains.

Privacy is not achieved by refusing to reason. It is achieved by controlling what the reasoning system receives, where it operates, what it retains, what it can infer, what it can change, and what evidence remains.