Trust
Private by route evidence. Governed by design.
TARX is built around Computer-first execution, explicit Supercomputer routing, Vault boundaries, private memory, policy, evidence, and deployment control.
Computer-first execution
TARX begins on the user's Computer. Supercomputer 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 permissioned power. Enterprise deployments should define when work stays on Computer, routes to 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.