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 execution integrity?
An attestation proves that a governance decision was made correctly — that signals were evaluated against a policy, that the runtime was valid, and that the result was signed. But it does not prove that the real-world action that followed actually matched the decision. Execution integrity bridges that gap. After your system acts on a governance decision — disbursing a loan, sending a payment, deploying code — you callconfirmExecution to produce a cryptographic proof that the action matched the authorization. This proof is independently verifiable and tamper-evident.
How it works
confirmExecution does the following:
- Verifies the attestation signature — confirms the authorization was legitimately issued
- Checks the replay store — prevents double-confirmation of the same execution ID
- Computes an
integrityHash—sha256(canonicalize({ authorizationId, execution_fingerprint, executedAction })) - Evaluates match criteria — checks action type, payload consistency, and time window
- Signs the proof — produces a signed
ExecutionIntegrityProofunderPARMANA_AUDIT_V1domain
Usage
ExecutedAction
The description of the real-world action that was performed:ExecutionIntegrityProof
The signed proof returned byconfirmExecution:
MatchDetails
Breakdown of whymatch is true or false:
match is true only when all three conditions are met:
| Check | What it tests |
|---|---|
actionTypeMatch | executedAction.type contains or is contained by decision.action (case-insensitive) |
payloadConsistent | payload.action (if present) is consistent with decision.action; payload.policyId (if present) matches attestation.policyId |
withinTimeWindow | The time between executedAt and the moment of confirmation is within timeWindowSeconds |
match: false proof is still a valid, signed record. Store it — it documents that execution occurred outside the authorized bounds.
Error conditions
| Error | Cause |
|---|---|
INTEGRITY_INVALID_ATTESTATION | The attestation’s signature is invalid — the authorization was tampered with or came from the wrong signer |
INTEGRITY_ALREADY_CONFIRMED | This executionId has already been confirmed — prevents double-confirmation |
Use Cases
Loan disbursement proof
AfterexecuteFromSignals returns an approve attestation for a personal loan, the disbursement service transfers the funds and immediately calls confirmExecution with type: "LOAN_DISBURSED" and the amount. The resulting ExecutionIntegrityProof proves — in a tamper-evident, signed record — that the disbursement happened within the 5-minute window following the governance authorization. If match: false, the insurer or regulator can see exactly which check failed.
Insurance claim settlement
After a motor insurance claim is approved (claim_amount: 18500, policy_active: true), the claims system sends the settlement payment and confirms it: type: "CLAIM_SETTLED", payload: { amount: 18500, claimId: "CLM-2024-001" }. The integrity proof is stored alongside the original attestation. Auditors get both — the authorization and the confirmed execution — linked by authorizationId.
Catching action/authorization mismatches
A governance decision approves a personal loan for ₹15,000. Due to a bug, the disbursement service sends ₹150,000. WhenconfirmExecution is called with the actual amount in the payload, payloadConsistent may return false if the payload contradicts the authorization. Even if match: false, the signed proof records the discrepancy — giving the audit trail evidence that the execution deviated from the authorization.
Via HTTP
The@parmanasystems/server exposes this as POST /confirm-execution. See the Server Package for the request/response schema.
See also
- Attestations - the authorization that confirmExecution validates against
- API Reference - full
confirmExecutionsignature - Server Package -
POST /confirm-executionendpoint