Privacy and inference
“Local,” “private,” and “attested” are different claims.
SkyTwin makes the reasoning location explicit. It does not silently switch a local request to a hosted provider, and it does not call an external trust portal proof that SkyTwin itself made a confidential request.
The three routing choices
| Route | What happens | What it does not prove |
|---|---|---|
| On-device / loopback | Embedded runtime or source-qualified local Ollama operates locally. Managed model setup is a separate user action. | It does not guarantee device encryption, model availability, or that a user-managed local artifact was registry verified. |
| Configured hosted provider | A user deliberately selects a provider and supplies its configuration. The request crosses a network boundary under that provider's terms. | HTTPS, an API key, a provider name, or a receipt do not independently establish confidential computing. |
| Verified-private remote route | TrustedRouter is available for explicit interactive calls only when its pinned adapter verifies the exact call. Every other provider is rejected in this mode; NEAR AI remains unavailable. | A successful provider login, general trust portal, or signed receipt alone does not establish the full SkyTwin boundary. |
What “local” means here
The managed local-model flow can recommend a pinned model artifact and validates it after the user starts the download. A compatible llama.cpp runtime remains a prerequisite. A manually configured local model is still local, but SkyTwin does not label it as artifact-verified. If the local route cannot run, it remains unavailable rather than falling back to a network provider.
Local execution also has a storage boundary: turn on FileVault, BitLocker, or LUKS as appropriate. See the project privacy disclosure for the current at-rest encryption details and limits.
Configured providers are explicit network choices
Hosted providers are not prohibited; they are named as a network route. Review the provider's endpoint, account, retention, terms, and the precise data you permit to leave the device. In the decision pipeline, email addresses are masked only in the raw-event and episodic-memory fragments before those fragments reach a provider; other prompt fragments are not covered by that specific masking. That is a narrow statement, not a broad redaction guarantee.
How verified-private inference fails closed
For TrustedRouter, SkyTwin's pinned adapter verifies issuer, audience, freshness, workload image, nonce, certificate, and TLS-exporter binding on the live request connection before prompt transmission. It then withholds the full response until an exact-byte, nonce-bound receipt verifies the request and response hashes, selected model, and tee-verified upstream tier. Dynamic route pricing is not yet persisted as an expiring exact price, so the hard spend gate blocks unattended use; explicit interactive calls and connection tests remain available.
What remains unavailable
NEAR AI is visible as verification-pending but is rejected by Settings, API, database compatibility gates, and runtime admission because its reviewed public evidence does not pin the dynamically selected model/proxy workload. Any TrustedRouter verification, authentication, model, receipt, timeout, or socket failure also ends that call without a conventional-provider retry.
A practical review checklist
- Choose and record the intended reasoning location before a task starts.
- For local, verify the runtime/model location and protect the device storage.
- For hosted, inspect the provider contract and configure it knowingly; do not call it confidential inference.
- For remote attestation, require request-bound verification produced by SkyTwin's own admitted path; otherwise leave it off.
- Review the canonical confidential-inference document when implementing or auditing this boundary.