Trust / Data handling

Where your engineering data goes

A local workspace, a managed service and a personal provider account are different boundaries. Choose deliberately.

Updated September 24, 2026. This inventory describes implemented storage and processing, not a certification, contractual data-processing agreement or promise of geographic residency. Read it alongside the privacy notice.

Three routes, different destinations

Local project and verification work: The native application and sf-core read your selected project, maintain revision/evidence data, and invoke installed tools. Opening a project does not itself send its source to managed AI. External tools and network-enabled integrations have their own behavior; review them separately.
SiliconForge managed AI: Your authorized request passes through SiliconForge’s API and its OpenAI processing route. Prompts, relevant conversation, approved files and tool results can be necessary to produce an answer or candidate. Installation identifiers, request hashes and quota information also travel to the service. Service credentials are used, not your personal provider login.
Explicit desktop OpenAI/Codex routes: The configured client/runtime communicates with its provider using your own account. Provider costs, settings and data processing are separate from the managed subscription. “Local API key” means locally configured credentials, not an offline model. The website does not collect that key.

Data inventory

Each category below lists its purpose, destination, storage and available control. A category with no published automatic deletion schedule must not be treated as ephemeral.

Public page and download requests

Purpose and destination: deliver the website/files and protect the service. Requests reach SiliconForge’s hosting infrastructure; ordinary request metadata can include IP address, URL and time. Storage: hosting/security logs, separate from your project. Control: do not put confidential content into URLs. No optional analytics or advertising profile is created by this site; a verified hosting-log retention schedule is not published.

Application update checks

Version 0.1.1 adds an at-most-daily request to the public release metadata endpoint, with a preference to turn automatic checks off. A manual check is also available. No project files, account identifiers or installed-version telemetry are sent. Hosting infrastructure receives ordinary request metadata such as IP address and time. Checks do not install software or change your license.

Purchase and activation

Purpose and destination: Stripe handles hosted checkout and billing; SiliconForge receives checkout/customer/subscription identifiers and entitlement/payment state. Storage: service billing records, payment-event hashes and entitlement metadata; browser session storage holds checkout recovery identifiers and an activation claim. Control: manage cancellation through billing and use support for record requests. Never submit card numbers to SiliconForge support. Cancellation and browser storage removal do not erase billing history.

Installations and credentials

Purpose and destination: authenticate licensed installations, enforce device limits and revoke access. The service stores installation/device identifiers, device name, public key, token hashes and entitlement association. Storage: service database; desktop secrets use Windows Credential Manager or Linux Secret Service. Control: revoke unused or compromised devices; use a non-sensitive device name. Token expiry and rotation are access controls, not deletion of the installation record.

Managed AI content

Purpose and destination: deliver a response or candidate and recover interrupted work. Requests and authorized context go to SiliconForge and OpenAI. Storage: encrypted response/replay payloads and private job events/results in the service database. Job ownership, request hashes, state and timing remain operational metadata. Control: review context before sending, withhold sensitive files, and request information or deletion through support. The OpenAI Responses API path sets store=false; this is not a guarantee of zero provider retention or a guarantee about every Codex runtime path.

Managed runtime and thread files

Purpose and destination: preserve managed Codex conversation state and isolated candidate work between turns. Storage: private server runtime/thread directories and candidate workspaces; directory access is restricted, but these are not the encrypted database store. Control: avoid submitting designs whose handling requirements this arrangement cannot meet. There is no verified automatic purge schedule for all such state, nor a published residency guarantee. Ask about your requirements before sharing regulated or contract-restricted material.

Usage and audit records

Purpose and destination: enforce quotas and concurrency, prevent duplicate billing/use, investigate failures and record operational changes. Storage: service database with identifiers or keyed hashes, counts, timestamps, model/usage and source-version metadata. The audit writer rejects designated prompt, content, message, email and credential fields. Control: retain the receipt identifier when reporting a problem; do not assume the absence of prompt text means there is no identifiable operational metadata.

Support and rights requests

Purpose and destination: investigate the issue and contact you. Your submitted email, subject and message go to the SiliconForge support queue. Storage: email/message encrypted in the service database; subject, case identifier, status, creation time and email keyed hash are metadata. An authorized operator can decrypt a case for triage. Control: redact the subject as well as the message. Closing a case changes its status and does not erase it. The form records a case; it does not automatically send a confirmation email.

Signed desktop entitlement

Purpose and destination: first activation and online refresh verify the installation against the subscription service, which obtains the current paid period from its billing authority. Storage: an installation-bound signed lease and local entitlement/clock state on the device, plus service-side account/device and entitlement metadata. The lease contains identifiers and paid-period dates, not your RTL. It is not an engineering-project upload or an installer signature. Control: refresh before going offline, revoke a lost installation, and do not share its activation credentials. Definitive online revocation invalidates the lease; a disconnected copy cannot receive immediate revocation and expires at its signed paid-through time. Retained billing and device records are not erased by expiry.

Your computer and external-provider state

Purpose and destination: project work, revision history, conversation recovery and your chosen provider session. Storage: project files/local databases, encrypted AI records, operating-system credential storage and any configured provider-runtime files. These stores have different deletion behavior. Control: follow the recovery guide, secure device backups, and manage your provider account directly. Deleting a local conversation does not revoke material already sent to a provider.

Expiry is not complete erasure

The service has cleanup logic for expired replay/idempotency records, expired/revoked access tokens, expired concurrency leases and older rate events. That limited cleanup does not establish when every hosted record or backup is deleted. Managed jobs, runtime threads, support cases, device records and commercial records have no verified unified automatic retention schedule in this release.

For account-specific access, correction or deletion, follow the privacy-request procedure. Do not infer immediate deletion, a fixed legal retention term or a certified privacy posture from this inventory.

Confirm you have permission to send the selected material to the chosen service and provider.
Remove credentials, unrelated files and confidential third-party IP from the context.
Review the disclosed files and action scope; approving execution may disclose additional tool output.
Keep a local revision/checkpoint and review the candidate and verification evidence before applying it.
If a fixed retention period, DPA, specific processing country or certification is required, establish that separately before uploading. None is promised by this page.

Configure and use AI · Security boundaries · Ask about data handling