Docs authority and product state¶
This page separates the product contract a customer can rely on during onboarding from implementation evidence and the longer-term roadmap. It is the interpretation key for the rest of this site.
Customer-onboarding baseline¶
The customer-onboarding baseline is the behavior Venturi commits to for an onboarded tenant. A capability belongs in this baseline only when its prerequisites, safe failure mode, and customer verification path are documented. The baseline is the customer contract; it is not a claim that every internal implementation task or external attestation is complete.
| Baseline invariant | Customer contract | Verification |
|---|---|---|
| Read-only collection | Provider access is least-privilege and write actions are excluded or explicitly denied. | Inspect the deployed provider policy and run the connector verification. |
| Metadata-only processing | Venturi materializes allowlisted metadata fields, never prompt or completion bodies. | Review data classification and ingestion validation. |
| Fail-open traffic path | The synchronous interceptor performs a fast index lookup within a 50 ms P99 budget and forwards the request unmodified on failure. | Exercise the fail-open check and inspect the latency SLI. |
| Asynchronous attribution | Stage B trained-model inference runs in the asynchronous processor with a 20 ms call budget inside the processor’s 100 ms P99 objective; fallback preserves attribution processing. | Inspect result-source markers and the processor SLI. |
| Cohort privacy | Adoption views and exports enforce a server-side minimum cohort size of 5. | Attempt a sub-threshold query and confirm suppression. |
| Audit durability | Audit events are append-only in application behavior and written to customer-controlled object storage. Governance mode is the default lock; Compliance mode is available for deployments requiring root-resistant retention. | Inspect object-lock configuration and read back the customer audit stream. |
| Customer-controlled enforcement | Active governance emits a signed deny recommendation. A customer-controlled enforcement point decides whether to apply it; the fail-open interceptor never blocks traffic. | Verify recommendation signature and the customer’s enforcement policy independently. |
Current implementation status¶
The implementation status is evidenced separately from the baseline. During
onboarding, Venturi records each control as verified, pending, not enabled,
or not applicable in the tenant’s implementation checklist. A public page cannot
upgrade that tenant-specific evidence.
The following items require explicit implementation evidence before they are represented as active for a tenant:
- SSO-only enforcement, SCIM lifecycle enforcement, and step-up authentication.
- Uniform central authorization across routes, workers, and exports.
- Record-level tenant-isolation adversarial tests.
- Customer-approved support-access runtime controls.
- Compliance-mode object lock and its configured retention period.
- Any optional provider surface, export, or enforcement integration.
SOC 2 is not currently held. Readiness work, audit evidence, and a future report remain distinct from certification.
Post-onboarding roadmap¶
Post-onboarding roadmap items describe intended future capabilities. They are not part of the customer-onboarding baseline unless a signed order or implementation plan explicitly adds them. Current roadmap examples include broader identity enforcement coverage, additional inference-residency controls, expanded provider connectors, file import, and higher availability/support tiers.
Roadmap language never overrides the baseline or tenant-specific implementation status. When a capability moves into the baseline, its verification procedure and evidence must land with the documentation change.
Authority hierarchy¶
For customer-visible behavior, the order of authority is:
- The signed customer agreement and implementation plan.
- The deployed provider policies, configuration, and verification evidence.
- The customer-onboarding baseline on this page and the detailed product docs.
- Internal requirements and engineering specifications.
- Post-onboarding roadmap material.
If a page conflicts with a deployed policy or tenant verification result, treat it as a documentation defect and contact Support.