Each prospect company gets its own workspace, and every procedure, background job and entry route is scoped to exactly one workspace. Staff need a product role (BD, Finance reviewer, Knowledge owner or Admin) plus staff membership of that specific workspace. A seller is attached to exactly one workspace as a plain member holding the seller role, and nobody can promote a seller to admin or owner. The people list shows a seller only their own company's people, never staff accounts.

Only the people and procedures the product allows. Each prospect company gets its own workspace with two dedicated AES-256-GCM data keys, one for uploads and one for derived content. Every file is sealed with that workspace's uploads key and processed in the background for that workspace only. Workspace keys and sealed tables are reachable only through Volaris PIR's own procedures, never through generic data surfaces such as the REST API, MCP server or AI chat tools. No generic tool can list or export them.

Each workspace gets two AES-256-GCM-wrapped data keys, one for uploads and one for derived content. The platform's managed key service wraps those keys. Every content payload is written through a seal/unseal envelope, and tests cover round-trip, tamper and plaintext-marker cases. Unwrapped keys stay in memory for at most five minutes. Destroying a workspace's keys crypto-shreds its data. The wrapped keys and sealed tables are reachable only through the product's own procedures. Generic surfaces such as the REST API, the MCP server and AI Worker controllers cannot reach them, so no generic tool can list or export them.

Volaris PIR is built for crypto-shredding. Each workspace's data keys are wrapped by the platform's managed key service. Unwrapped keys stay in memory for at most five minutes. Destroying a workspace's keys leaves its sealed content unreadable. For the full deletion workflow and retention details, details are available on request.

Sellers can upload any number of files of any type by drag and drop, file picker or phone camera. Files over 25 MB get a plain message asking them to send the file to their BD. BDs and Admins can upload on the prospect's behalf, and those files are tagged 'Added by <name>'. Each file is sealed with the workspace's uploads key and processed in the background for its own workspace only. Pasted file-sharing links are listed for the BD. For current limits on staff uploads, details are available on request.

Staff hold product-wide roles: BD, Finance reviewer, Knowledge owner or Admin. For workspace actions, they also need staff membership of that specific workspace. The server enforces a permission matrix across these roles and the Seller role, with an automated test for every cell. A seller is attached to exactly one prospect workspace and can never be promoted to admin or owner. Sellers see only their own company's people, never staff accounts. Staff actions are recorded in a staff-only audit log that never appears in a seller's activity history.

Before any seller-facing text is shown, or handed to a BD to send, it passes a wording guard. The guard checks the text against a product-wide internal-terms list of 31 default terms in six groups, and only the Knowledge owner can edit that list. It rejects exclamation marks, urgency and blame. If generated text fails, an AI model rewrites it once. If the rewrite still fails, the text is held for a BD to review. Tone rules T1–T5 are enforced by an automated test over every registered seller string.

Sellers can upload any number of files of any type by drag and drop, file picker or phone camera. Files over 25 MB get a plain message asking the seller to send them to their BD. BDs and Admins can upload on the prospect's behalf, and those files are tagged 'Added by <name>'. If a seller pastes a file-sharing link, it is listed for the BD to follow up.

A product-wide knowledge registry holds rules, reference mappings, definitions, question wording and Q&A flags. Each entry has a code, statement, example, source, confidence and a draft or approved status, and every edit is versioned. Only the Knowledge owner can approve, edit or reject entries. Every rule application records the rule it used, and any use of a draft rule is flagged for review until that rule is approved. Plain-language definitions written in the founder's language must pass the wording guard, and sellers see them through 'What do we mean?'.

Not if the wording guard catches it. Before any text is shown to a seller or handed to a BD to send, it is checked against an internal-terms list of 31 default terms in six groups, which only the Knowledge owner can edit. The guard rejects exclamation marks, urgency and blame. It rewrites AI-generated text once, and anything that still fails is held for a BD to review. Tone rules T1 to T5 are enforced by an automated test over every registered seller string.

Yes, staff actions are audited. They are recorded as staff-only audit entries that never appear in a seller's activity history. Permissions follow a server-enforced action-by-role table, and each cell of that table has its own automated test. A separate coverage test fails if any procedure lacks a matrix action. Uninvited or role-less users are sent to a single page saying 'Your Volaris contact will send you an invitation'.

Volaris PIR keeps a knowledge registry of rules, reference mappings, definitions, question wording and Q&A flags. Each entry has a code, statement, example, source, confidence and draft/approved status, and every edit is versioned. Every rule application records its rule ID. Any use of a draft rule is flagged for review until the Knowledge owner approves that rule. Plain-language definitions reach sellers through 'What do we mean?' only after passing the wording guard.