Section pages
TRUST
Clear boundaries are part of the product.
Reusable context needs source permissions, clear review state and careful data handling. This page explains the boundaries behind PRAXIS and the questions to resolve before a team evaluation or cross-tool handover.
Local demonstration data stays in this browser.
The briefing checks, method-interview answers and imported JSON are processed in browser JavaScript. Saved examples use this origin’s localStorage; exports create local files. No model or external worker receives those inputs. This is separate from ordinary page/asset requests and optional analytics. Clear the demo library in Save & hand over; clearing it cannot recall downloaded copies.
Restricted-source export conservatively omits text, locators and free-text derivatives. That omission can prevent independent review. Metadata does not enforce source permissions, establish recipient identity or grant a license. Hosted PRAXIS and the local compiler have their own data flows and deployment-specific checks.
Before a first evaluation
- Start with public or non-sensitive material and confirm permission to use it.
- Choose the question, intended audience and person who will review the work.
- Inspect the dated workflow evidence and distinguish operation from analytical quality.
- Agree access, provider processing, retention and exit requirements before institutional use.
Website contact and analytics are separate from PRAXIS document and conversation processing. Website privacy · Recorded product scope.
Current checks, concepts and commitments
The Example Advisory landscape and workspace are fictional teaching material. The full team assignment screen is labeled Concept preview / Product direction. It is not evidence of delivered team controls, automatic change review or analytical accuracy.
Dated product captures identify the build and tested scope. Reference formats and architecture responsibilities describe design work. Institutional access, permissions, confidentiality and support require a scoped discussion. Read the recorded product checks · Capability status.
Default application path and open questions
The PRAXIS application notice identifies Firebase authentication and Google Cloud services, including document storage and Vertex AI, with United States infrastructure by default. Its recorded acceptance journey used private synthetic material. Those operations do not establish suitability for confidential or regulated records.
Confirm the enabled model and document providers, training settings, processing locations, retention schedule, deletion and backup behavior before uploading institutional material. These deployment-specific commitments are not established by this website. Application privacy · Provider inventory · Retention posture.
Two principles we are building around.
Human judgment in the loop, by design
Our design separates model proposals from accepted context. A reviewer should be able to approve, qualify, or reject a proposed change and preserve the reason for that decision. Review records, permissions, and export behavior need testing together before a team can rely on the resulting audit trail.
Context that can move between tools
Our goal is a versioned, inspectable format that preserves context across tools. Reference artifacts illustrate the design, but PRAXIS export/import is not yet lossless: document and workspace references need further work. Source permissions, review state, and graph meaning must survive a round-trip before we claim interoperability.
Security and data-handling considerations
Data residency
The project website runs on Google Cloud. Customer-selectable residency and replication are not established product capabilities. Agree the deployment and data-flow requirements before an institutional pilot.
Encryption
Hosted services use HTTPS. Encryption configuration, key management, retention, and customer-managed key requirements must be reviewed for the proposed deployment; no enterprise key-management feature is promised here.
Tenant isolation
PRAXIS uses authenticated ownership and access checks. Isolation still requires authorization testing, including capsule references, imports, and agent tools. We do not claim that cross-tenant failures are impossible.
Data handling
A pilot should define permitted sources, model-provider processing, access, retention, and deletion before data is uploaded. Use public or non-sensitive examples while those requirements are being agreed.
Compliance roadmap
We do not claim SOC 2 certification, HIPAA eligibility, or a completed enterprise compliance program. Contractual and regulatory requirements need a scoped review before a deployment is offered.
Open-source auditability
Published reference code and ontology documents can be inspected on GitHub. Their scope and license are repository-specific; open reference work does not constitute an audit of the hosted application.
FOUNDER NOTE
“I built TACITUS to keep sources, political context and review decisions connected across analytical work. We are testing that approach in public. I have spent nearly a decade analyzing conflict for institutional decision-makers. I know what ‘careful’ means in this domain, not just technically, but operationally. TACITUS was designed under that constraint from the first commit.”
PILOT DEPLOYMENTS
Start with a scoped evaluation.
Agree a question, an appropriate source set, and evaluation criteria before work begins. Duration, confidentiality, pricing, support, and exit terms belong in the engagement agreement. A useful evaluation should make clear what worked, what failed, and what would need to change before wider use.
Pilot inquiryHOSTING AND PROCESSING
Services to include in a data-flow review.
This overview distinguishes this website from the PRAXIS application. It is not a complete contractual subprocessor register. Before a pilot, confirm the providers, regions, retention terms, and change-notification arrangements for the specific workflow.
| Name | Purpose | Region |
|---|---|---|
| Google Cloud | Project website hosting; PRAXIS cloud infrastructure is separately configured | Website: us-central1 |
| Analytics integrations | Optional Google Analytics and Plausible, loaded after permission; configured inquiry delivery uses Resend | Provider-dependent |
| Model and document providers | PRAXIS processing depends on the enabled workflow; request a deployment-specific inventory | To be confirmed for the pilot |