Skip to main content

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.

​
Overview

Organisations governing AI decisions today use one or more of five approaches. Each has genuine strengths. Each has specific limits. Understanding those limits is the starting point for choosing the right governance architecture. This page analyses each approach honestly — what it proves, what it cannot prove, and what the residual risk is.

​
Approach 1 — Audit Logs

​
What it is

Every AI decision is written to a log. Logs are stored in a database, object storage, or SIEM. Auditors query the log to reconstruct what happened.

​
What it proves

✅ A record of the decision exists
✅ The decision was recorded at a point in time
✅ The record can be queried and reported

​
What it cannot prove

❌ The record has not been altered since it was written
❌ The decision actually followed the stated policy
❌ An independent party can verify the decision
❌ The same inputs would produce the same decision again
❌ The inputs recorded are the inputs actually used

​
The residual risk

Logs are mutable. Anyone with database write access can alter a log record. Even append-only logs can be truncated or replaced at the storage layer. When a regulator asks “prove this decision followed your credit policy” — a log entry says the decision was X. It does not prove X was correct or unaltered.

​
When it is sufficient

Audit logs are sufficient when:
  • The risk of log alteration is low (internal controls)
  • The regulator accepts operational evidence
  • No cryptographic proof is required
For most Indian NBFCs today, audit logs are sufficient for day-to-day operations. They become insufficient when a decision is disputed and the counterparty challenges the integrity of the log.

​
Approach 2 — Rule Engines

​
What it is

Business rules are codified in a rule engine. The AI system calls the rule engine with input signals. The rule engine evaluates rules and returns a decision. The decision is logged. Common implementations: decision tables, DMN, Drools, built-in rule engines in core banking systems.

​
What it proves

✅ Rules were evaluated at decision time
✅ The decision followed the rules that were loaded
✅ Rule changes can be versioned and tracked

​
What it cannot prove

❌ The decision is cryptographically signed
❌ An independent party can verify the decision
❌ The rules that were loaded are the rules that should have been loaded
❌ The inputs have not been altered before reaching the rule engine
❌ The same inputs will produce the same decision on a different system

​
The residual risk

Rule engines evaluate rules correctly. They do not produce cryptographic proof of the evaluation. The audit trail is: “the rule engine was called with these inputs and returned this decision.” This is operationally useful but not cryptographically provable. A sophisticated dispute could challenge:
  • Were these actually the inputs provided?
  • Was this actually the policy version that was active?
  • Could someone have changed the rule engine configuration?
None of these can be answered by the rule engine alone.

​
When it is sufficient

Rule engines are the right tool for:
  • Real-time decision making at scale
  • Complex business logic with many conditions
  • Policy management with version control
They become insufficient when cryptographic proof of individual decisions is required — for example, when a loan applicant challenges a rejection and demands proof that the policy was followed correctly.

​
Approach 3 — Model Monitoring

​
What it is

A monitoring layer observes AI model inputs and outputs over time. It detects drift, bias, and performance degradation across populations of decisions.

​
What it proves

✅ The model's behaviour is tracked over time
✅ Statistical drift from baseline is detected
✅ Fairness metrics across demographic groups are measured
✅ Model performance against ground truth is measured

​
What it cannot prove

❌ Any individual decision was correct
❌ Any individual decision followed the stated policy
❌ Any individual decision can be independently verified
❌ The inputs to any specific decision were accurate
❌ Any specific decision cannot be altered retroactively

​
The residual risk

Model monitoring operates at the population level. It answers “is this model behaving correctly on average?” It cannot answer “was this specific decision correct?” When a borrower in Mumbai disputes their loan rejection, population-level statistics are not evidence. The regulator wants to know what happened in that specific case with those specific inputs. Model monitoring cannot answer this question for any individual decision.

​
When it is sufficient

Model monitoring is essential for:
  • Detecting model degradation over time
  • Ensuring fairness across demographic groups
  • Triggering retraining when performance drops
  • Regulatory reporting on model behaviour
It is not a substitute for per-decision governance proof. The two approaches are complementary — not alternatives.

​
Approach 4 — Blockchain

​
What it is

Decisions are recorded on a distributed ledger. Multiple validators confirm each record. Records are immutable once confirmed. Any party can verify any record using the public ledger.

​
What it proves

✅ The record cannot be altered once confirmed
✅ Multiple independent parties validated the record
✅ Any party can verify any record independently
✅ The record is timestamped by network consensus

​
What it cannot prove

❌ The decision followed a specific policy
❌ The inputs to the decision were accurate
❌ The same inputs would produce the same decision

​
The practical constraints

Latency:
  Block confirmation: 2-15 seconds (public chains)
  Permissioned chains: 1-5 seconds
  Real-time AI decisions require: <100 milliseconds
  → Blockchain latency is incompatible with real-time governance

Cost:
  Public chains: gas fees per transaction
  At scale (1 million decisions/day): significant cost
  → Operational cost is a barrier at volume

Privacy:
  Public chains: all records are public
  Permissioned chains: all validators see all records
  Financial decisions contain sensitive data
  → Privacy requirements conflict with blockchain design

Infrastructure:
  Blockchain requires validator infrastructure
  Validator onboarding for each new participant
  Ongoing node operation and maintenance
  → Significant operational overhead

​
When it is the right choice

Blockchain is the right tool when:
  • Multiple organisations who do not trust each other need to agree on shared truth
  • Records must be public and universally accessible
  • Decentralisation is a requirement not a preference
  • Latency requirements allow seconds not milliseconds
For a single organisation proving its own AI decisions were governed correctly — blockchain adds infrastructure complexity without adding governance capability.

​
Blockchain and Parmana together

Parmana attestations can be published to a blockchain. This combines:
  • Parmana: millisecond governance proof, private, cheap
  • Blockchain: immutable public record, multi-party verifiable
For cross-party verification (regulator + regulated entity, two banks in a transaction) this combination is powerful. For single-organisation governance, Parmana alone is sufficient.

​
Approach 5 — Cryptographic Governance

​
What it is

Every AI decision produces a cryptographically signed attestation. The attestation binds the decision to the exact policy version, the exact inputs, and the exact runtime that produced it. Any party with the public key can verify any attestation independently — without access to the original system.

​
What it proves

✅ Decision followed exactly this policy version
✅ Inputs used are exactly what was fingerprinted
✅ Decision cannot be altered without detection
✅ Same policy + same inputs → same decision always
✅ Execution was not replayed
✅ Runtime that produced this decision is identified
✅ Any party can verify independently

​
What it cannot prove

❌ Inputs accurately reflect reality
❌ Execution happened as reported
❌ No other action occurred outside the system

​
The honest limits

Cryptographic governance is strong software-layer proof. It does not extend to hardware execution or physical reality. To close remaining gaps:
  • Signal provenance: trace where inputs came from
  • Source attestation: verify inputs were signed by the source
  • TEE integration: hardware-proved execution
  • Independent reconciliation: compare authorizations to outcomes
These are extensions — not replacements — for cryptographic governance.

​
When it is the right choice

Cryptographic governance is appropriate when:
  • Individual decisions must be provably correct
  • An independent party may need to verify any decision
  • Regulators require non-repudiable audit evidence
  • The same inputs must deterministically produce the same decision
  • Decisions must be tamper-evident without blockchain infrastructure

​
Choosing the Right Approach

These approaches are not mutually exclusive. The right governance architecture for most regulated Indian fintechs combines several: 
Audit logs          → operational visibility
                      fast, cheap, queryable

Rule engine         → real-time policy evaluation
                      complex conditions, versioning

Model monitoring    → population-level health
                      drift detection, fairness

Cryptographic       → per-decision proof
governance          → independent verifiability
                      regulatory evidence

Blockchain          → cross-party verification
(optional)          → public immutable record
                      only when multi-party trust needed

​
The sequence for Indian regulated fintechs

Stage 1 — Foundation (most fintechs are here)
  Audit logs + rule engine
  Sufficient for operations
  Insufficient for disputed decisions

Stage 2 — Governance proof (where Parmana adds value)
  Add cryptographic governance per decision
  Every decision is independently verifiable
  Regulators can verify without system access

Stage 3 — Provenance (signal traceability)
  Add signal provenance
  Trace every input to its source
  AA consent → income signal → governed decision

Stage 4 — Cross-party (for multi-institution workflows)
  Optionally publish attestations to shared ledger
  Regulator + regulated entity share verifiable record
  Two banks in a joint lending arrangement

​
Summary

ApproachTamper-evidentPer-decision proofIndependent verifyReal-timePrivate
Audit logs❌❌❌✅✅
Rule engines❌❌❌✅✅
Model monitoring❌❌❌✅✅
Blockchain✅❌✅❌❌
Cryptographic governance✅✅✅✅✅
No approach in the table is wrong. Each is appropriate in its context. The question is whether per-decision cryptographic proof is required for your regulatory environment and risk profile. For lending, insurance, and capital markets in India — where individual decisions can be disputed by borrowers, reviewed by ombudsmen, and audited by regulators — per-decision proof is increasingly the right answer.