Verified in source

Security & governance

Vira's control plane uses scoped behavior authority, permission-checked mutations, versioned revisions, runtime evidence, and explicit fallback/fail-closed paths.

• Behavior authority is resolved through explicit scope and revision identity.
• Governed mutations use project-scoped authorization and distinct capabilities.
• Runtime explanation uses server-owned receipt evidence where that evidence exists.
• Stale or mismatched optimized artifacts are not treated as new authority.

Read the technical security model

Verified in source

Privacy controls

Vira separates public marketing measurement from authenticated product data and carries explicit privacy, retention, legal-hold, and subject-request primitives.

• Public analytics and advertising paths are consent/configuration gated.
• Studio is kept outside the public advertising tracking boundary.
• Application privacy modes and privacy-governance records are explicit source primitives.
• Privacy request execution now records identity verification and a bounded execution scope.

View the technical privacy summary

Conditional

Architecture summary

The source deployment contract separates public/docs/studio surfaces from API and worker services, defines PostgreSQL as authoritative state, Redis as disposable cache/queue state, and object storage for artifacts.

• This is an architecture contract, not proof of a specific live provider account or region.
• Model-provider calls are route/configuration dependent.
• Residency claims remain blocked until deployed regions, backups, and provider routes are verified.

Review pending

Subprocessors

Vira maintains an internal source-backed vendor inventory, but the public subprocessor list is not represented as reviewed or complete yet.

• Exact contracting legal entities, locations, transfer posture, and DPA evidence remain approval gates.
• Vendor additions are required to pass technical, security, privacy, and applicable legal/commercial review.

See the review-pending subprocessor route

Not published

Availability & status

Vira does not publish an SLA or public availability commitment from source alone.

• Internal readiness and recovery controls exist.
• A public SLA requires reliable uptime measurement, incident response, support coverage, and approved commercial remedies.
• No public status-page claim is made here without an operational status source.

Conditional

AI & customer data handling

Model-provider data flow is mapped by execution path, but Vira does not publish a universal no-training or zero-retention promise without exact provider and product-policy evidence.

• OpenAI and Anthropic routes exist for specific compiler, evaluation, demo, and optimization paths when configured.
• Teach-AI uses a configurable OpenAI-compatible endpoint and sends store:false, which is not treated as a legal zero-retention guarantee.
• Vira-controlled customer-content training/product-improvement policy remains an explicit approval decision.

Not published

Incident & vulnerability contact

The repository intentionally does not publish security.txt until a monitored security reporting channel and reviewed disclosure process exist.

• Incident/privacy response runbooks exist.
• Engineering incident severity is kept distinct from legal breach determination.
• No unstaffed security mailbox is presented as an operational reporting channel.

Review pending

Legal documents

Privacy and Cookies are technical summaries; Terms, DPA/Data Processing, AI Usage, Subprocessors, Acceptable Use, and Legal Security remain review-pending and noindex.

• No AI-generated legal draft is treated as approved policy.
• Legal routes become indexable only after owner review, operational verification, version/effective-date metadata, and publication approval.

Open the privacy summary