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

# Task → Policy → Schema Model

> The core architecture that determines required evidence before policy evaluation

# Task → Policy → Schema Model

The Task → Policy → Schema Model is the foundation of Parmana.

It determines which evidence must be collected before a policy can be evaluated.

```text theme={null}
Customer Chooses Task
        ↓
Task → Policy Mapping
        ↓
Policy
        ↓
Schema
        ↓
Required Signals
        ↓
Verified Signals
        ↓
Parmana Evaluation
```

***

## Why This Exists

Organizations authorize business actions.

Examples:

```text theme={null}
Transfer Funds
Approve Claim
Issue Refund
Create Vendor
Close Account
```

These actions are tasks.

Each task maps to a policy.

```text theme={null}
Transfer Funds
        ↓
High Value Transfer Policy

Approve Claim
        ↓
Claims Approval Policy
```

***

## Policies Define Schemas

Policies are the source of truth.

Each policy defines the signals required before evaluation.

Example:

```json theme={null}
{
  "requiredSignals": {
    "authenticated_user": "boolean",
    "available_balance": "number",
    "destination_verified": "boolean",
    "transfer_amount": "number"
  }
}
```

***

## Schemas Define Required Signals

Once a policy is known:

```text theme={null}
Policy
   ↓
Schema
```

the required signals become deterministic.

```text theme={null}
Schema
   ↓
Required Signals
```

No runtime guessing.

No hidden logic.

No AI interpretation.

***

## Verified Signals

External systems verify required facts.

Examples:

```text theme={null}
Banking System
Identity Provider
Fraud Platform
Claims Platform
CRM
```

Example:

```json theme={null}
{
  "authenticated_user": true,
  "available_balance": 5000,
  "destination_verified": true,
  "transfer_amount": 1000
}
```

Parmana evaluates verified facts.

Parmana does not verify facts itself.

***

## Evaluation Flow

```text theme={null}
Verified Signals
        ↓
Policy Evaluation
        ↓
Decision
```

Possible outcomes:

```text theme={null}
Approve
Reject
Require Override
```

***

## Separation of Responsibilities

```text theme={null}
Customer
    ↓
Chooses Task

Organization
    ↓
Maps Task → Policy

Policy
    ↓
Defines Schema

External Systems
    ↓
Verify Signals

Parmana
    ↓
Evaluates Policy

External Systems
    ↓
Execute Action
```

***

## Banking Example

```text theme={null}
Customer Requests Transfer
            ↓
Transfer Funds Task
            ↓
Transfer Policy
            ↓
Transfer Schema
            ↓
Required Signals
            ↓
Verified Signals
            ↓
Parmana Evaluation
            ↓
Decision
            ↓
Execution
```

Result:

```text theme={null}
AI Captures Request
Bank Verifies Facts
Parmana Enforces Policy
Bank Executes Decision
```

***

## Core Insight

```text theme={null}
Task
  ↓
Policy
  ↓
Schema
  ↓
Required Signals
  ↓
Verified Signals
  ↓
Decision
```

Once the task is known, the policy is known.

Once the policy is known, the schema is known.

Once the schema is known, the required evidence is known.

This makes authority verification deterministic.

***

## Related Reading

* Whitepaper: `Task → Policy → Schema Model`
* Architecture: `Policy Evaluation`
* Architecture: `Verified Signals`
* API: `GET Policy Schema`
* API: `POST /evaluate`