The review packet, in one place 

• Architecture documentThe data-flow and mode-boundary description on this page and in the trust center, tied to a specific build identifier.
• Repeatable boundary testThe offline / traffic-capture procedure in the verification section below — run it on your own machine.
• Source accessThe public repository under AGPL-3.0, with its licence, attribution and history.
• Data lifecycle walkthroughA guided session with the people who build Vaultr, covering import to deletion in the mode you intend to run.

Where data lives

In the application's per-matter directory on the device's local disk. No Vaultr-operated cloud store exists for matter data.

Encryption

Vaultr does not add its own at-rest encryption layer. The local store is covered by your device's full-disk encryption (FileVault on the tested macOS target) when the device has it enabled.

Telemetry

None in the product. No analytics SDK, no usage reporting, no telemetry endpoint. (This website separately uses opt-in, consent-gated pageview analytics — see the privacy notice; it is not part of the product.)

Crash reports

Off by default. When enabled by you, reports are limited to technical diagnostics — matter content is excluded.

Network defaults

Matter processing in Local Mode requires no outbound connection. The two exceptions are actions you start: the updater and model downloads.

Listening services

Matter processing does not require Vaultr to open a listening service. Anything listening on the device is your own infrastructure, not Vaultr's.

Access control

Vaultr relies on the device's own accounts and authentication. It adds no second account layer.

Multi-tenancy

None in Local Mode — each device holds its own matters. There is no shared server for cross-firm data mixing to occur in.

What an update fetches

Application updates are fetched on your explicit action, for the release channel you installed. Vaultr does not self-trigger updates while you work.

Update transparency

The repository carries the release history. What changed, and why, is checkable before you take an update.

Dependency lockfiles

The product repository commits dependency lockfiles, so builds are reproducible and every dependency version is pinned and reviewable.

Automated checks

The repository runs scripted schema-drift and workflow-freshness checks and a Playwright end-to-end suite on the supported flow.

Vulnerability management

Dependency lockfiles and automated checks are maintained in the public repository and can be inspected directly.

OpenChain self-certification

The open-source licence compliance programme is self-certified against OpenChain ISO/IEC 5230 — an officially supported conformance path, not an independent audit; the statement lives in the trust center.

Model unavailable

The run does not silently fall back to another model or to a hosted provider. The task stops with an explicit state, and nothing is sent anywhere in Local Mode.

Document cannot be parsed

The document is reported as unparseable with the reason. It is excluded from the index rather than guessed at.

Citation cannot be resolved

The finding reports not found rather than inventing a source. An answer without a resolvable span is not asserted as fact.

External endpoint unreachable

A configured endpoint that cannot be reached stops the run with an error. There is no automatic retry against a different provider.

Network-restricted operation

In Local Mode, operations that would need outbound access are the ones you started on purpose — updates and model downloads. Matter processing does not require a socket.

Unnecessary disclosure

Matter content is not transmitted in Local Mode, so it cannot be logged, retained or shared by a party you did not choose.

Unintended model-provider transmission

Model providers are selected explicitly. There is no silent fallback to a hosted model.

Uncontrolled processing

Review, drafting and interrogation run against the matter you attached, within the mode you selected.

Untraceable AI conclusions

Findings carry source spans and a decision record, so a conclusion can be walked back to its evidence.

Unreviewed automated actions

Proposed changes wait at a checkpoint. Nothing is applied without a human decision.

Included deliberately. A packet that omits this list is asking its reader to trust selectively.

1. 01No independent security audit has been commissioned.
2. 02No formal third-party penetration test has been performed or published.
3. 03No SOC 2 report exists. This product does not operate a cloud service that one would cover.
4. 04No ISO/IEC 27001 certification exists, and none is claimed.
5. 05No zero-egress verification has been independently published — the offline test procedure exists so you can produce that evidence yourself.

How to report

Send the details to the security contact below, or open a private security advisory on the public repository.

What to include

A description, the build identifier, and steps to reproduce. Do not include matter data or anything confidential to a firm.

What we commit to

Good-faith reports are acknowledged and answered. We will not pursue legal action over good-faith research that respects other people's data.

Coordinated disclosure

We ask for reasonable time to fix before public publication, and we will credit reporters who wish to be named.

Response commitment

Good-faith security reports are reviewed directly by the maintainers and prioritized according to severity and affected releases.

The packet is documentation, not assurance. The boundary test is the part of this packet you run — the procedure takes minutes and produces your own evidence instead of ours.