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?
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
policyIdandpolicyVersion— exactly which policy governed the decision - The
decision— approve, reject, or override-required, with reason and matched rule - The
runtimeVersionandruntimeHash— which runtime produced the decision - The
bundleHashandmanifestHash— the content identity of the policy bundle - The
signature— an Ed25519 signature over the canonical payload
Core properties
Same input, same decision The samepolicyId, 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