Trust
Private by architecture. Governed by design.
TARX is built around local-first execution, explicit Supercomputer routing, Vault boundaries, private memory, policy, evidence, and deployment control.
Local-first execution
TARX begins on the user's computer. Hosted compute is optional and should be visible, approved, and governed.
Memory boundary
TARX memory stores user-approved context: preferences, projects, decisions, and workflows.
Vault boundary
Credentials, API keys, tokens, SSH keys, private keys, passwords, passcodes, client secrets, and sensitive secrets must be routed Vault-first, not stored in ordinary memory.
Supercomputer routing
Supercomputer is optional power. Enterprise deployments should define when work stays local, routes to hosted Supercomputer, or moves through private/BYO runtime.
Evidence and audit
Sensitive workflows need records: what was used, what was routed, what tools acted, what policy applied, and what approvals existed.
Enterprise controls
TARX should support SSO, access controls, deployment policy, procurement review, provider agreements, and support requirements as enterprise deployments mature.
Designed for regulated review
TARX is being built for serious enterprise and regulated environments, including SOC 2 and HIPAA-oriented control discussions. Certification and compliance status should be represented only when formally completed.
Government and operational environments
TARX can support local-first and private deployment discussions for public-sector and operational use cases. Hosted cloud use for federal agencies may require formal authorization pathways. TARX should not claim specific government certification until validated.
