> ## 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. # What is Parmana > Execution governance infrastructure — what it is, what it governs, and what it is not ## The problem AI systems produce recommendations. Automated pipelines act on them. The gap between recommendation and execution is where accountability breaks down. When an AI agent approves a \$50,000 insurance claim, denies a patient's medication request, or modifies production infrastructure, you need to be able to answer: * What policy governed that decision? * What inputs were evaluated? * Which runtime version produced the outcome? * Can this be proven to a regulator, an auditor, or a counterparty — without access to your systems? Log entries and audit tables cannot answer these questions. A log entry records what happened; it does not prove it. An attestation proves it. *** ## What Parmana governs Parmana governs **execution authority** — whether a proposed action is allowed to execute. The inputs are called **signals**: structured data your system collects and passes to the governance runtime. Signals might be credit scores, claim amounts, fraud flags, patient vitals, account balances, or any other business-relevant data. The runtime evaluates signals against a **policy** — a compiled, signed set of rules. The policy produces a **decision**: approve, reject, or require human override. The decision is wrapped in an **attestation**: a cryptographically signed record of the exact inputs, policy, runtime, and outcome. That attestation is the proof. *** ## The execution model ```mermaid theme={null} sequenceDiagram participant S as Your System participant R as Parmana Runtime participant P as Policy Bundle participant A as Attestation participant V as Verifier S->>R: POST /execute { executionId, policyId, signals } R->>P: Load signed bundle P->>R: Policy rules R->>R: Evaluate signals against rules R->>R: Hash canonical inputs → execution_fingerprint R->>R: Issue governance token R->>A: Sign token → ExecutionAttestation A->>S: Return attestation S->>V: POST /verify attestation V->>S: { valid: true } ``` Every step in this chain is auditable. The attestation binds together: * The `executionId` — your business transaction identifier * The `execution_fingerprint` — a SHA-256 hash of the canonical signals (the semantic identity of this specific decision) * The `policyId` and `policyVersion` — exactly which policy governed the decision * The `decision` — approve, reject, or override-required, with reason and matched rule * The `runtimeVersion` and `runtimeHash` — which runtime produced the decision * The `bundleHash` and `manifestHash` — the content identity of the policy bundle * The `signature` — an Ed25519 signature over the canonical payload *** ## Core properties **Same input, same decision** The same `policyId`, `policyVersion`, and signals always produce the same decision. The policy evaluation engine contains no randomness, no timestamp dependence, and no external calls. Two independent runtimes evaluating the same inputs produce identical attestations (modulo the signature key). **No AI in the evaluation path** Parmana's decision engine is a rule evaluator, not a model. AI systems may generate signals or propose actions. Parmana's evaluation path is fully rule-based. **Fail-closed** If the governance runtime is not configured correctly — missing signer, missing verifier, missing replay store, missing Redis — execution is blocked. There is no fallback path that allows unverified execution. **Replay-safe** Every execution is keyed by `executionId`. The replay store (Redis in production) prevents the same `executionId` from executing more than once. Replay attempts throw `[INV-013@replay]`. **Independently verifiable** Verification requires only the attestation JSON and the public key. No database access, no runtime access, no network connection to your infrastructure. This is by design — the verifier is stateless. *** ## What Parmana is not | Not this | Because | | ---------------------------- | ------------------------------------------------------------------------------- | | An AI observability platform | Parmana does not monitor model behavior or trace inference | | A workflow engine | Parmana governs individual decisions, not process flows | | An LLM framework | Parmana has no LLM integration; signals come from your system | | A monitoring platform | Parmana does not collect metrics or trace requests | | An orchestration system | Parmana does not sequence or coordinate multi-step operations | | A SaaS platform | Parmana is deployed in your own infrastructure; nothing leaves your environment | *** ## When to use Parmana Use Parmana when: * A decision must be **provable** after the fact to a party that wasn't present * An action must be **auditable** against the exact rule set that governed it * A decision must be **reproducible** — you need to re-derive the same outcome from the same inputs * A human must be able to **override** an automated decision, with that override recorded cryptographically * Regulators, auditors, or counterparties must be able to **verify** decisions without infrastructure access Typical domains: insurance claim processing, financial transaction authorization, healthcare prior authorization, infrastructure change approval, access control decisions, compliance gate enforcement. *** ## Next steps Docker stack running in under 5 minutes Walk through the full request → attestation → verification flow Execution ID, execution fingerprint, and what constitutes authority