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

# Security Model

> How Parmana protects execution integrity

Parmana protects execution integrity through a small set of layered properties, rather than a single mechanism:

* **Immutable domain objects** — no artifact in the trust chain (Authority, Intent, Decision, Execution, Verification, Receipt, Execution Trust Record) supports an update operation.
* **Append-only evidence** — corrections and later activity are recorded as new artifacts (see [Override](/docs/concepts/override)), never as edits to history.
* **Cryptographic hashing** — every Execution Trust Record carries a `trustRecordHash`, recomputed as the record evolves.
* **Digital signatures** — Receipts are signed attestations (see [`crypto`](/docs/packages/crypto)).
* **Replay verification** — outcomes can be independently re-derived from recorded inputs; see [Replay](/docs/concepts/replay).
* **Deterministic execution** — identical policy and inputs always produce identical decisions, which is what makes both verification and replay meaningful.
* **Independent verification** — a party verifying a record does not need access to, or trust in, the original runtime that produced it.

## Trust artifacts are never modified after creation

This is the load-bearing guarantee behind everything else in this list. If corrections were applied in place, replay and independent verification would both become meaningless — there would be no way to know whether the record you're checking is the one that was originally produced. Instead, corrections are represented by additional immutable artifacts appended to the record.

## Cryptographic architecture

Every Execution Trust Record is designed to support:

* Canonical serialization
* SHA-256 hashing
* Digital signatures
* Cryptographic receipts
* Independent verification

Algorithm choices are treated as an implementation detail behind the `crypto` package's interfaces rather than a fixed part of the domain model — see [Cryptographic Agility](/docs/reference/glossary#cryptographic-agility) in the glossary. This is what allows future support for post-quantum algorithms without an architectural change.

## Related

<CardGroup cols={2}>
  <Card title="crypto package" href="/docs/packages/crypto">Signing, hashing, and receipt generation implementation.</Card>
  <Card title="Error Model" href="/docs/api/error-model">How failures are reported without leaking internal detail.</Card>
</CardGroup>