> ## Documentation Index
> Fetch the complete documentation index at: https://docs.manthan.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Trust Portability

> Any independent party can cryptographically verify every authority verification outcome from the attestation alone.

## What trust portability means

The fundamental promise of Parmana is not just that authority verification outcomes are made correctly - it is that **any independent party can reproduce and verify the exact same decision from the same inputs**.

This is what separates governance infrastructure from governance theater.

A system that works locally but cannot be independently verified is an internal audit tool. A system where any third party - a regulator, a counterparty, an auditor with no access to your infrastructure - can take an attestation and mathematically prove it is authentic and unchanged - that is externally verifiable governance infrastructure.

## The test

For every authority verification outcome, ask:

> Can an unrelated third party, with only the attestation and the public key, independently verify this decision?

If yes - you have portable trust.
If no - you have a local audit log dressed up as governance infrastructure.

## What makes trust portable

Five properties must hold for trust to be portable.

### 1. Canonical serialization

The same data must produce the same bytes on every system, in every language, on every platform.

This requires:

* **Sorted keys** - `{b:2, a:1}` and `{a:1, b:2}` must canonicalize identically
* **Compact form** - no optional whitespace that varies by implementation
* **Unicode NFC normalization** - `�` as one character vs `e` + combining accent must produce the same bytes
* **One implementation** - multiple canonicalize functions with different behavior destroys the guarantee

Without canonical serialization, verification is environment-dependent. An attestation signed on Linux may not verify on Windows.

### 2. Content-addressed fingerprints

The `execution_fingerprint` must be determined entirely by the content of the signals - not by key insertion order, runtime engine, or serialization library.

```typescript theme={null}
// Wrong - order-dependent and incomplete
const fingerprint = sha256(JSON.stringify(signals));

// Correct - content-addressed and policy-bound
const fingerprint = sha256(canonicalize({
  policyId,
  policyVersion,
  signals,
}));
```

Without content-addressed fingerprints that include the policy identity, a third party computing the fingerprint from the same signals may get a different value.

### 3. Exact schema version resolution

An attestation records which schema version governed the decision. A third party must be able to load the exact same schema version and reproduce the exact same evaluation.

Silent fallbacks - "requested 1.5.0, silently used 1.0.0" - mean the attestation does not accurately describe what happened.

### 4. Deterministic signed payloads

Nothing non-deterministic may appear inside a signed payload.

The most dangerous violation: wall-clock time inside signed content.

```typescript theme={null}
// Wrong - unverifiable after the millisecond it was created
const signature = sign({ decision, approver, approved_at: new Date() });

// Correct - verifiable forever
const signature = sign({ decision, approver });
// approved_at exists as metadata, outside the signature
```

An override signed with a timestamp in the payload can only be verified in that exact millisecond.

### 5. Semantically distinct identifiers

| Field                   | Purpose                                | Must be                                                                      |
| ----------------------- | -------------------------------------- | ---------------------------------------------------------------------------- |
| `executionId`           | Which specific execution event         | Random - `crypto.randomUUID()`                                               |
| `execution_fingerprint` | What was the content of this execution | Deterministic - `sha256(canonicalize({ policyId, policyVersion, signals }))` |

If these are the same value, replay protection, deduplication, and audit lineage all break simultaneously.

## The verification model

A properly portable attestation can be verified by any party following this process:

```typescript theme={null}
import { verifyAttestation, LocalVerifier } from "@parmanasystems/verifier";

// Only the attestation and public key - nothing else needed
const verifier = new LocalVerifier(publicKey);
const result   = verifyAttestation(attestation, verifier);

console.log(result.valid);   // true
console.log(result.checks);
// {
//   signature_verified: true,
//   runtime_verified:   true,
//   schema_compatible:  true,
//   governed:           true,
// }
```

This process works:

* Five minutes after signing
* Five years after signing
* On any platform
* In any language
* By any party with the public key

## Trust portability in practice

**Regulatory audits** - a financial regulator can verify every authority verification outcome made over the past year without access to your infrastructure. They only need the attestations and the public key.

**Counterparty verification** - a business partner can independently verify that a decision affecting them was made according to the agreed governance rules - without trusting your audit logs.

**Cross-jurisdiction compliance** - an attestation created in one regulatory jurisdiction can be verified by authorities in another, because verification requires no proprietary infrastructure.

**Long-term archival** - attestations stored for seven years remain verifiable at retrieval time, because the signed content is deterministic and the canonical form is stable.

## What breaks trust portability

| Failure                                 | Effect on verification                                               |
| --------------------------------------- | -------------------------------------------------------------------- |
| Multiple canonicalize implementations   | Signing and verification use different formats - all signatures fail |
| No Unicode NFC normalization            | Different platforms produce different hashes for identical content   |
| Order-dependent hashing                 | Third parties compute different fingerprints for the same signals    |
| Wall-clock time in signed payload       | Signature unverifiable after the millisecond it was created          |
| `executionId === execution_fingerprint` | Cannot distinguish event identity from content identity              |

## The single rule

> If a property of the signed payload can differ between the moment of signing and the moment of verification, trust is not portable.

Every design decision in Parmana follows from this rule.

## See also

* [Portable Verification](/architecture/portable-verification) - the full verification model
* [Deterministic Governance](/architecture/deterministic-governance) - why determinism is the foundation
* [Governed Signals](/architecture/governed-signals) - how inputs are canonicalized
* [Attestations](/concepts/attestations) - what a signed decision looks like