> ## 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.

# Portable Verification

> How any party can verify any decision without accessing your infrastructure

Portable verification means that authority verification outcomes can be verified independently of the runtime that produced them - by any party, on any infrastructure, at any point in time.

## The problem with runtime-bound trust

When governance trust is bound to a specific runtime instance, verification requires access to that runtime. This creates fragile compliance evidence:

* Distributed nodes cannot verify decisions made by other nodes
* Auditors cannot independently verify historical decisions
* Long-term lineage reconstruction requires the original runtime to still be available
* Compliance evidence is fragile - it depends on infrastructure that may not exist at audit time

Portable verification eliminates this dependency. The cryptographic proof travels with the attestation.

## What an attestation contains

An attestation is self-contained - it includes everything needed for independent verification:

```json theme={null}
{
  "executionId":           "88a9db95-5f31-4f0d-84de-28a3ec9e3c83",
  "execution_fingerprint": "43258cff783fe703...",
  "policyId":              "loan-approval",
  "policyVersion":         "1.0.0",
  "runtimeVersion":        "1.0.0",
  "runtimeHash":           "4ece56164e1a8809...",
  "decision": {
    "action":            "approve",
    "requires_override": false,
    "reason":            "Credit score meets standard threshold."
  },
  "signature": "TU6LMv5NJJm1KvM2..."
}
```

Any party with the public key can verify this. No access to your infrastructure, database, or runtime required.

## The verification model

```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,   ← Ed25519 signature valid over canonical payload
//   runtime_verified:   true,   ← runtimeHash matches known runtime
//   schema_compatible:  true,   ← schemaVersion is supported
//   governed:           true,   ← all invariants hold
// }
```

This process works identically:

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

## Runtime provenance

The `runtimeHash` in every attestation pins the exact runtime that produced the decision:

* Historical attestations remain verifiable after the runtime is updated
* The runtime version that governed the decision is part of the signed proof
* Auditors can independently confirm the runtime version was known and trusted at signing time

## Long-term archival

An authority verification outcome produced today must be verifiable in seven years. This requires:

* The attestation is self-contained (no external state needed for verification)
* The `runtimeHash` identifies the exact runtime used
* The policy version is pinned in the signed payload
* The signature algorithm (Ed25519) is stable, standardized, and widely supported

Parmana attestations are designed for long-term archival. The verification algorithm does not change across runtime versions.

## Portability in practice

| Scenario                      | What portability enables                         |
| ----------------------------- | ------------------------------------------------ |
| Regulatory audits             | Auditors verify without infrastructure access    |
| Counterparty verification     | Business partners verify decisions independently |
| Distributed systems           | Each node verifies attestations from other nodes |
| Cross-jurisdiction compliance | Evidence verified by any regulatory authority    |
| Long-term archival            | Decisions verifiable years after signing         |

## 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.

Wall-clock time, session identifiers, and non-deterministic state are excluded from the signed payload precisely because they would break this guarantee.

## Portable Verification Lifecycle

```mermaid theme={null}
flowchart TD

LINEAGE[Append-Only Lineage]
REPLAY[Replay Reconstruction]
HASH[Replay Hash]
PROOF[Governance Proof Bundle]

EXPORT[Portable Artifact Export]

VERIFIER[Independent Verifier]
PUBKEY[Trust Root Public Key]

LINEAGE --> REPLAY
REPLAY --> HASH
HASH --> PROOF
PROOF --> EXPORT

EXPORT --> VERIFIER
PUBKEY --> VERIFIER
```

## See also

* [Trust Portability](/architecture/trust-portability) - the full portability model and what breaks it
* [Attestations](/concepts/attestations) - the complete attestation field reference
* [Verifier Package](/packages/verifier) - standalone verification without the full runtime
* [Deterministic Governance](/architecture/deterministic-governance) - why determinism is the foundation