> ## 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.

# POST /confirm-execution

> Produce a signed Execution Integrity Proof after an action has been executed

## Endpoint

```http theme={null}
POST /confirm-execution
Content-Type: application/json
Authorization: Bearer <api-key>
```

`/confirm-execution` verifies that the action which occurred in the real world matches the action that was authorized by Parmana.

It produces a signed Execution Integrity Proof that can be independently verified by auditors, compliance teams, regulators, and external systems.

***

## Why It Exists

Authorization alone is not enough.

Organizations must also prove that the action that actually occurred matches the action that was authorized.

```text theme={null}
Verified Signals
        ↓
Policy Evaluation
        ↓
Signed Attestation
        ↓
Execution
        ↓
Confirm Execution
        ↓
Execution Integrity Proof
```

This closes the gap between authorization and execution.

***

## Core Principle

Parmana answers two different questions:

### Evaluation

```text theme={null}
Was this action authorized?
```

### Confirmation

```text theme={null}
Did the executed action match the authorized action?
```

`/confirm-execution` answers the second question.

***

## Request Body

```json theme={null}
{
  "attestation": {
    "...": "..."
  },
  "executedAction": {
    "type": "approve",
    "payload": {
      "action": "approve",
      "claim_amount": 100
    },
    "executedAt": "2026-06-14T09:27:04.176Z",
    "executedBy": "claims-system"
  },
  "timeWindowSeconds": 300
}
```

***

## Fields

| Field                       | Type                   | Required | Description                                                        |
| --------------------------- | ---------------------- | -------- | ------------------------------------------------------------------ |
| `attestation`               | `ExecutionAttestation` | Yes      | Signed attestation returned by `/evaluate`                         |
| `executedAction.type`       | `string`               | Yes      | Action that was executed                                           |
| `executedAction.payload`    | `object`               | Yes      | Executed action payload                                            |
| `executedAction.executedAt` | `string`               | Yes      | ISO-8601 execution timestamp                                       |
| `executedAction.executedBy` | `string`               | Yes      | System or user that performed execution                            |
| `timeWindowSeconds`         | `number`               | No       | Maximum allowed time difference between execution and confirmation |

***

## What Parmana Verifies

### 1. Attestation Signature

The attestation must have been signed by Parmana.

```text theme={null}
Invalid Signature
        ↓
Confirmation Rejected
```

***

### 2. Action Match

The executed action type must match the authorized action.

```text theme={null}
Authorized: approve
Executed: approve

✓ Match
```

```text theme={null}
Authorized: approve
Executed: reject

✗ Mismatch
```

***

### 3. Payload Consistency

The executed payload must remain consistent with the authorized decision.

```text theme={null}
Authorized Amount: 100
Executed Amount: 100

✓ Match
```

```text theme={null}
Authorized Amount: 100
Executed Amount: 5000

✗ Mismatch
```

***

### 4. Time Window

The execution must occur within the configured confirmation window.

```text theme={null}
Execution
      ↓
300 seconds
      ↓
Confirmation
```

Outside the allowed window:

```text theme={null}
withinTimeWindow = false
```

***

## Successful Response

```json theme={null}
{
  "executionId": "e91ea79c-225a-4ceb-8a79-b51b05c26513",
  "authorizationId": "api-test-003",
  "integrityHash": "84e1126b48fb04e404ac296466f3d86127530646184f9116d918c10986653bf0",
  "authorized": {
    "action": "approve",
    "reason": "standard_approval",
    "policyId": "claims-approval",
    "policyVersion": "1.0.0"
  },
  "executed": {
    "executedBy": "api-test",
    "executedAt": "2026-06-14T09:27:04.176Z",
    "type": "approve",
    "payload": {
      "claim_amount": 100,
      "action": "approve"
    }
  },
  "match": true,
  "matchDetails": {
    "actionTypeMatch": true,
    "payloadConsistent": true,
    "withinTimeWindow": true,
    "timeWindowSeconds": 300
  },
  "signature": "...",
  "confirmedAt": "2026-06-14T09:27:15.540Z",
  "verified": true,
  "execution_state": "completed",
  "override_applied": false,
  "attestationIssued": true
}
```

***

## Response Fields

### executionId

Unique identifier for the generated integrity proof.

### authorizationId

Original authorization identifier from the attestation.

### integrityHash

Deterministic hash linking authorization and execution evidence.

### authorized

Summary of the authorized decision.

### executed

Summary of the actual executed action.

### match

Whether execution matched authorization.

### matchDetails

Detailed matching results.

### signature

Parmana signature over the integrity proof.

### verified

Whether the original attestation verified successfully.

### confirmedAt

Timestamp when the proof was produced.

***

## Match Details

```json theme={null}
{
  "actionTypeMatch": true,
  "payloadConsistent": true,
  "withinTimeWindow": true,
  "timeWindowSeconds": 300
}
```

| Field               | Description                               |
| ------------------- | ----------------------------------------- |
| `actionTypeMatch`   | Executed action matches authorized action |
| `payloadConsistent` | Executed payload matches authorization    |
| `withinTimeWindow`  | Execution occurred within allowed window  |
| `timeWindowSeconds` | Configured confirmation window            |

***

## Replay Protection

Each attestation can only be confirmed once.

Attempting to confirm the same attestation multiple times returns:

```json theme={null}
{
  "error": "INTEGRITY_ALREADY_CONFIRMED"
}
```

This prevents duplicate execution confirmations.

***

## Error Responses

### 400 Bad Request

```json theme={null}
{
  "error": "Invalid request"
}
```

Malformed request body.

***

### 401 Unauthorized

```json theme={null}
{
  "error": "Unauthorized"
}
```

Missing or invalid API key.

***

### 422 Invalid Attestation

```json theme={null}
{
  "error": "INTEGRITY_INVALID_ATTESTATION"
}
```

Attestation signature verification failed.

***

### 409 Already Confirmed

```json theme={null}
{
  "error": "INTEGRITY_ALREADY_CONFIRMED"
}
```

Execution has already been confirmed.

***

### 500 Internal Error

```json theme={null}
{
  "error": "Confirmation failed"
}
```

Unexpected runtime failure.

***

## Example — curl

```bash theme={null}
curl -X POST https://your-runtime/confirm-execution \
  -H "Authorization: Bearer $PARMANA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @confirm-request.json
```

***

## Execution Integrity Proof

The returned proof is a signed record containing:

* The original authorization
* The executed action
* Match results
* Runtime verification outcome
* Cryptographic signature

It can be stored independently and verified later.

***

## How Confirm Execution Fits Into Parmana

```text theme={null}
Customer Request
        ↓
Verified Signals
        ↓
Parmana Evaluation
        ↓
Decision
        ↓
Signed Attestation
        ↓
Execution
        ↓
Confirm Execution
        ↓
Execution Integrity Proof
```

Parmana answers:

> Was the action authorized?

`/evaluate`

and

> Did the executed action match the authorized action?

`/confirm-execution`

Together they provide authorization verification before execution and execution integrity verification after execution.