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

# Glossary

> Canonical terminology from the monorepo's GLOSSARY.md

Adapted from `GLOSSARY.md` at the monorepo root (version 0.1.0). Per that document: "Unless explicitly stated otherwise, these definitions are normative." Where a term has its own dedicated page in this documentation, this glossary links to it rather than restating its full field model.

<Note>
  A few terms below use slightly different words than their corresponding [Concepts](/docs/concepts/overview) pages (e.g. `ExecutionTransaction` here vs. `BusinessTransaction` in the implemented code, `Verification Report` here vs. the implemented `Verification` type). The glossary is the specification-level vocabulary; the Concepts section and API reference describe what's actually implemented under those names today. Both are included because they don't always use identical nouns.
</Note>

## Authority

The entity responsible for initiating or approving an execution. Answers: *who decided?* See [Concepts → Authority](/docs/concepts/authority).

## Intent

The explicit description of the desired outcome. Answers: *what should happen?* See [Concepts → Intent](/docs/concepts/intent).

## Authorization

The decision permitting or denying execution. Answers: *was execution allowed?* See [Concepts → Authorization](/docs/concepts/authorization).

## Execution

The actual realization of the authorized intent. Answers: *what happened?* See [Concepts → Execution](/docs/concepts/execution).

## Evidence

Immutable artifacts describing execution. Evidence enables replay, audit, and verification.

## Verification

The independent evaluation of an execution record. Answers: *can the recorded execution be trusted?* See [Concepts → Verification](/docs/concepts/verification).

## Execution Trust

The architectural property established when an independent verifier can demonstrate that execution faithfully reflects authorized intent using immutable evidence. Execution Trust is the primary objective of Parmana.

## ExecutionTransaction

The immutable aggregate root representing a single execution lifecycle: Authority, Intent, Authorization, Execution, and Evidence. In the implemented code, this role is filled by [`BusinessTransaction`](/docs/concepts/business-transaction) plus the artifacts aggregated onto its [Execution Trust Record](/docs/concepts/execution-trust-record).

## Runtime

The subsystem responsible for orchestrating execution. The Runtime produces execution records. The Runtime does not establish trust. See [`runtime` package](/docs/packages/runtime).

## Runtime Pipeline

An ordered sequence of Runtime Components that transform an immutable `ExecutionTransaction`. See [Runtime → Runtime Pipeline](/docs/runtime/runtime-pipeline).

## Runtime Component

A deterministic execution stage participating in the Runtime Pipeline. Each component accepts an immutable transaction and returns a new immutable transaction.

## Verification Engine

The subsystem responsible for independently evaluating execution records; consumes immutable transactions and produces verification reports. The monorepo ships a real, dedicated [`verification` package](/docs/packages/verification) matching this description, but it isn't currently invoked by the API — see that page for what runs instead.

## Verification Report

The immutable result produced by the Verification Engine; summarizes the outcome of verification without modifying the execution record. Implemented as [`Verification`](/docs/concepts/verification).

## Replay

The deterministic reconstruction of execution semantics using preserved execution records and evidence, used to validate that execution can be reproduced from recorded facts. See [Concepts → Replay](/docs/concepts/replay) and [Guides → Deterministic Replay](/docs/guides/deterministic-replay) for how this compares to what `POST /replay` currently does.

## Deterministic Execution

Execution in which equivalent recorded inputs produce equivalent observable results — required for replay and independent verification.

## Append-Only Evidence

An evidence model in which historical artifacts are never modified or deleted; new information is represented by appending additional evidence rather than altering existing records. See [Architecture → Security Model](/docs/architecture/security-model).

## Cryptographic Agility

The architectural principle that cryptographic algorithms are replaceable implementation details rather than fixed domain concepts. See [`crypto` package](/docs/packages/crypto) for the concrete SHA-256/Ed25519 defaults this currently resolves to.

## Platform Guarantee

A behavior that every conformant Parmana implementation must preserve — for example, deterministic execution, immutable records, and independent verification.

## Conformance

The property of satisfying the Parmana Specification and Platform Guarantees, demonstrated through implementation behavior rather than implementation details.

## Reference Implementation

The official implementation maintained by the Parmana project — this monorepo. It demonstrates one correct realization of the specification but is not the specification itself.

## Specification

The normative set of documents that define Parmana's architecture, behavior, and contracts (the root-level `.md` files: `SPECIFICATION.md`, `PROTOCOL.md`, `ARCHITECTURE.md`, and this glossary, among others). Implementations conform to the specification rather than to a particular codebase.

## Related

<CardGroup cols={2}>
  <Card title="Concepts Overview" href="/docs/concepts/overview">The implemented model these terms map onto.</Card>
  <Card title="Error Codes" href="/docs/reference/error-codes">The equally normative error-code vocabulary.</Card>
  <Card title="Architecture Overview" href="/docs/architecture/overview">Where these terms fit together.</Card>
</CardGroup>