# Trust

Source: https://www.primust.com/trust
HTML title: Trust — Primust
Meta description: How Primust keeps governed content out of the signing path, what metadata it stores, how offline verification works, and what analytics run on the marketing site.

← Primust · Trust
# Designed so Primust cannot see what you are _governing_.

The data boundary is part of the product design. Signing requests contain commitment hashes and execution metadata, not the underlying content being governed.

§ 01 — Boundary

## Designed so Primust does not need to see what you are governing.

What leaves your environment

⊢

Commitment hashes for the governed input, output, or artifact.

⊢

Identifiers for the declared checks, policies, or bundles that ran.

⊢

Execution metadata such as timestamps, environment labels, run IDs, and proof level.

⊢

Declared gaps when a required check did not run or produced incomplete evidence.

What stays with you

Prompts, source content, uploaded documents, model outputs, or code diffs do not need to leave your environment.

Primust does not need your raw governed data in order to issue a credential.

Verification can be done later from the credential, the public key, and the verifier.

§ 02 — Operations

## Store only the information needed to run the service and verify the credential.

Trust Boundary

Account and service metadata

Primust stores standard account information, authentication state, billing records, and service telemetry needed to operate the dashboard and API. That is separate from governed content.

Trust Boundary

Signing metadata

Signing requests contain commitment hashes and related execution metadata. By default, signing metadata is retained for 90 days for service operation, abuse prevention, and support.

Trust Boundary

Open verification

A relying party can verify issuer, signature, proof level, bundles, and declared gaps with the open-source verifier and Primust public keys. Verification does not require calling Primust.

Trust Boundary

Key distribution

Public verification keys are published through the Primust well-known key endpoint. That lets counterparties validate a credential independently and archive the trust material they rely on.

§ 03 — Disclosure

## Marketing analytics are limited to the public site and are not part of the proof path.

Public website

The marketing site uses Vercel Analytics and Vercel Speed Insights to measure page traffic and page performance. Those scripts are limited to the public website. They are not part of the dashboard, API, signing flow, or offline verification flow.

Product proof and website analytics are separate systems.

Primust does not use business-visitor identification on the marketing site, and the verifier does not depend on Primust analytics infrastructure.

Read The Boundary

## Start with the verifier and the policy docs, not marketing promises.

The strongest trust claim on the site should be one you can test yourself.

Read the VPEC spec Read privacy details