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 Parmana proves
| Claim | Proof mechanism |
|---|
| Decision was made according to specific rules | Ed25519 signature over canonical attestation |
| Decision cannot be altered after signing | Signature fails on any field change |
| Decision can be verified by anyone with the public key | Portable verification — no runtime access needed |
| Same inputs would always produce the same decision | Determinism invariants + sealed execution scope |
| No other execution with the same signals ran first | Replay protection — INV-013 |
| Reported downstream action was recorded | confirmExecution → ExecutionIntegrityProof |
What Parmana does not prove
| Claim | Reality |
|---|
| The input signals were accurate | Signals are supplied by the caller — Parmana validates their type and schema, not their truthfulness |
| The downstream execution happened at all | confirmExecution records what was reported, not what hardware did |
| The reported execution was the only execution | No observer on downstream systems |
| No other execution was authorized elsewhere | Parmana governs decisions — other systems may have their own authorization paths |
Why this gap exists
Parmana is a pure software governance layer running in a standard Node.js process. It can prove what decisions were made and signed. It cannot observe what happens in downstream systems, hardware, or other processes.
This is not a bug. Closing this gap fully requires:
- Trusted Execution Environment (TEE) — Intel SGX, AWS Nitro Enclaves, or equivalent hardware that attests what code ran and what data it processed
- Blockchain or append-only ledger with independent observers — external parties verify execution records in real time
- Independent reconciliation — a separate system compares authorization records to action records and reports discrepancies
Each of these adds significant operational complexity and cost. For most regulatory and business requirements, they are not necessary.
What closes the gap in practice
For regulatory proof-of-decision (RBI, IRDAI, SEBI, FCA)
Regulators require proof that a decision was made according to a specific policy by a specific system at a specific time. Parmana provides all of this:
- The attestation proves the decision
- The bundle hash proves the policy version
- The runtime hash proves the software version
- The signature proves integrity
Regulators do not typically require hardware execution proof for software decision systems.
For operational assurance
Use confirmExecution to produce a signed record of the reported downstream action:
const proof = await confirmExecution(
{
attestation,
executedAction: {
type: "LOAN_DISBURSED",
payload: { amount: 15000, accountId: "acc-42" },
executedAt: new Date().toISOString(),
executedBy: "disbursement-service-v2",
},
},
signer,
verifier,
replayStore
);
// proof.match — true if action type matches the authorization
// proof.integrityHash — SHA-256 linking the authorization to the action
// proof.signature — Ed25519 over the complete proof record
ExecutionIntegrityProof is a signed record of what was reported. It does not independently verify that the action occurred — it records and signs the claim.
Build reconciliation on top of this: periodically compare your ExecutionAttestation records to your system action logs. Discrepancies (authorizations with no matching confirmed action, or actions with no matching authorization) are your audit signal.
For high-assurance systems
| Layer | What it provides |
|---|
| Redis replay store | Persistent, atomic, auditable replay protection across processes |
confirmExecution | Signed record of reported execution, bound to authorization |
Attestation storage in @parmanasystems/audit-db | Queryable, tamper-evident decision history |
| Reconciliation job | Detects authorization/action mismatches |
The honest positioning
Parmana is authorization governance infrastructure. It makes AI and automated decisions provable.
It is:
- The strongest pure-software governance layer for AI decision systems
- A cryptographic audit trail for all decisions
- A compliance-ready proof-of-decision system
- Independently verifiable by any party with the public key
It is not:
- An execution enforcement layer (it cannot stop downstream systems from acting)
- A hardware security module (it runs in standard Node.js)
- A blockchain (it does not have independent observers)
- A guarantee that the reported execution is truthful
Signal provenance addresses the most significant remaining gap: signal accuracy.
When signals are attested — verified as coming from authoritative sources before they enter Parmana — the governance chain becomes significantly stronger:
Before: Caller-supplied signals → Governed decision → Reported execution
After: Verified signals → Governed decision → Reported execution
↑ e.g. CIBIL API ↑ cryptographic proof ↑ confirmExecution
@parmanasystems/provenance with three ready-made signal source adapters:
accountAggregatorProvenance — verified bank data via the RBI-regulated Account Aggregator framework (trustLevel: "verified")documentProvenance — signals extracted by AI or OCR pipelines from documents (trustLevel: "claimed")voiceTranscriptProvenance — signals extracted from voice call transcripts (trustLevel: "claimed")
The extractSignalValues() function is the determinism boundary: it strips provenance metadata before signals enter the evaluation engine. Policy evaluation never sees provenance — only values. Two executions with identical signal values but different provenance records produce identical decisions, identical fingerprints, and identical attestations.
Signal provenance closes the input gap. When signals are verified at source, the governance chain is:
Verified inputs + Governed decision + Reported execution = Fully attested end-to-end
See Signal Provenance for the complete API reference and adapter usage.
Use Cases
Regulatory proof-of-decision for an RBI inspection
An RBI inspector asks an NBFC to demonstrate that a batch of personal loan decisions were made according to the approved policy personal-loan v1.2.0. The NBFC provides the attestation records. The inspector verifies each attestation’s bundleHash against the hash of the approved policy bundle on file, confirms runtimeVersion against the certified runtime, and verifies the Ed25519 signature using the NBFC’s public key. All three checks pass without access to the NBFC’s infrastructure. This is what Parmana proves — the gap it cannot close is whether the input signals (monthly_income, credit_score) were accurate, only that they were evaluated correctly.
An NBFC closes the signal accuracy gap for income signals by wrapping them with accountAggregatorProvenance before calling executeFromSignals. The AA framework provides cryptographically signed financial data directly from the borrower’s bank, so sourceVerified: true and trustLevel: "verified". The validateProvenance call confirms all signals meet minimumTrustLevel: "verified" before execution proceeds. The resulting audit trail chains: AA consent → raw data hash → derived income signal → governed decision — covering both the input and decision gaps.
Using confirmExecution to record a disbursement
After approving a home loan, the NBFC disburses ₹4,200,000 and immediately calls confirmExecution with type: "LOAN_DISBURSED" and the actual amount. The resulting ExecutionIntegrityProof is stored alongside the original attestation, linked by authorizationId. If match: false (e.g. the disbursed amount differs from what the policy authorized), the proof still records and signs the discrepancy — giving auditors a tamper-evident record that the execution deviated from the authorization. This is what confirmExecution proves: a signed record of what was reported, not independently verified hardware execution.
Reconciliation job detecting authorization/action mismatches
A fintech runs a nightly reconciliation job that compares ExecutionAttestation records (governance authorizations) to ExecutionIntegrityProof records (confirmed actions). Attestations with no matching confirmed action within 24 hours are flagged as unconfirmed. Confirmed actions where proof.match === false are flagged as execution deviations. This reconciliation layer — built on top of Parmana’s signed records — is how the remaining gap between authorization and action is detected operationally.
See also
