Trust model

A capsule proves two things: that its contents have not changed since it was sealed, and which key sealed it. It does not prove the contents are true. That boundary is deliberate, and it is why the review is deterministic rather than generated.

What the signature covers

The Ed25519 signature is over the canonical manifest. The manifest lists every data file with its SHA-256 and size. So the signature transitively covers every byte of evidence: the review, the commit records, the patches, the scope index. Change one byte anywhere and verify fails.

What the signature does not cover

• Whether the commits in the capsule are the commits in your remote. The capsule records what the observer saw locally, stamped observed.
• Whether notes and decisions are accurate. They are declared by whoever typed them.
• Who the person behind the key is. The signing key is generated per repository by init and is not bound to an identity. Identity comes from the cloud account that uploaded the capsule, not from the key.

Trust levels

Every piece of evidence carries one of five levels: verified (confirmed by an external system), observed (collected directly from Git or the local process), declared (typed by a person), inferred (derived by heuristics), unsupported. In 0.2.0 commits are observed and notes, decisions, and risks are declared; nothing is marked verified because no external attestation is integrated yet.

Local verification

patcharc verify runs the seven checks with no network. Anyone with the file and the CLI can do it; the public key is inside the capsule.

Cloud verification

On share, the cloud:

1. Requires the upload's SHA-256 to match what the CLI declared before it will store the body.
2. Re-verifies the signature and every file hash with an independent implementation.
3. Publishes only on success; a failure is terminal and visible in the capsule's status.

A published ArcLink therefore means: this exact capsule was uploaded by this account, and it verified. It does not mean PatchArc vouches for the claims inside it.

Keys

• Signing key: .patcharc/keys/arc-signing.ed25519, mode 0600, directory 0700, gitignored. init --force rotates it.
• Cloud credentials: ~/.patcharc/credentials.json, mode 0600, outside the repository. Refresh tokens are stored server-side as SHA-256 hashes and rotated on every use.
• BYOK provider keys: envelope-encrypted inside the key broker; see AI summaries and BYOK.

Threats this design addresses

• A shared capsule edited after the fact: detected by verify.
• A server that publishes something other than what you uploaded: prevented by hash matching on upload and re-verification before publish.
• A stolen credentials file: limited by rotation (the stored refresh token is replaced on first use) and by patcharc logout.

Threats it does not address yet

• Secrets inside patches: the redaction engine is not applied automatically. See Redaction.
• Private links: private and team visibility are accepted but have no browser viewer; links you want people to open must be public or capability.
• Binding a capsule to a build: no in-toto or SLSA predicate is emitted.