What is Parmana

​

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

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

---

​

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