> ## 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 > How Parmana deterministically derives required evidence from business actions before evaluation # Task → Policy → Schema Model ## Executive Summary Parmana is built on a simple idea: > Once the task is known, the policy is known. Once the policy is known, the required evidence is known. This allows authority verification to become deterministic. Instead of asking systems to decide what information might be relevant for a decision, Parmana derives required evidence directly from policy. ```text theme={null} Task ↓ Policy ↓ Schema ↓ Required Signals ↓ Verified Signals ↓ Evaluation ``` This model ensures that policies remain the source of truth and that authority decisions are based on verified facts rather than assumptions. *** # The Problem Most systems treat authorization as an application concern. A request arrives. Developers decide: * What information to collect * What checks to perform * What rules to enforce Over time these implementations drift. ```text theme={null} Request ↓ Custom Logic ↓ Decision ``` Different teams make different decisions. Different services enforce different rules. Eventually no one can confidently answer: > What evidence was required before this action was approved? *** # Why Tasks Matter People do not think in terms of policies. People think in terms of business actions. Examples: ```text theme={null} Transfer Funds Approve Claim Issue Refund Close Account Create Vendor Approve Payment ``` These are tasks. A task represents the action someone wants to perform. The customer chooses a task. Not a policy. *** # Organizations Define Authority Organizations define authority through policies. Examples: ```text theme={null} Transfer Funds ↓ High Value Transfer Policy Approve Claim ↓ Claims Approval Policy Issue Refund ↓ Refund Authorization Policy ``` The organization decides which policy governs each task. This mapping becomes part of the organization's authority model. *** # Task → Policy Mapping The first step in Parmana is determining which policy applies. ```text theme={null} Customer Chooses Task ↓ Transfer Funds ↓ Task → Policy Mapping ↓ High Value Transfer Policy ``` This mapping can be configured by the organization. Policies can change without changing the task itself. For example: ```text theme={null} Transfer Funds ↓ Policy v1 ``` later becomes: ```text theme={null} Transfer Funds ↓ Policy v2 ``` without changing the customer experience. *** # Policies Define Schemas A policy is the source of truth. Each policy defines a schema. The schema specifies the evidence required before evaluation. Example: ```json theme={null} { "policyId": "high-value-transfer", "requiredSignals": { "authenticated_user": { "type": "boolean" }, "account_owner_verified": { "type": "boolean" }, "available_balance": { "type": "number" }, "destination_verified": { "type": "boolean" }, "transfer_amount": { "type": "number" } } } ``` The schema defines what must be known before a decision can be made. *** # Schemas Define Required Signals Once the policy is known: ```text theme={null} Policy ↓ Schema ``` the required signals become deterministic. ```text theme={null} Schema ↓ Required Signals ``` No runtime guessing. No AI interpretation. No hidden business logic. The required evidence is explicitly defined. *** # Signals Must Be Verified Signals are not decisions. Signals are facts. Examples: ```text theme={null} Account Exists Balance Available Customer Authenticated Device Verified Destination Verified ``` These facts must be verified by external systems. Examples: ```text theme={null} Banking System Fraud Platform Identity Provider CRM ERP Claims System ``` Parmana does not verify signals. External systems verify signals. *** # Verified Signals After verification: ```json theme={null} { "authenticated_user": true, "account_owner_verified": true, "available_balance": 5000, "destination_verified": true, "transfer_amount": 1000 } ``` These become verified signals. Verified signals are facts. Not opinions. Not recommendations. Not AI-generated assumptions. *** # Parmana Evaluates Policy Parmana receives verified signals. ```text theme={null} Verified Signals ↓ Parmana ``` Parmana evaluates those facts against policy. ```text theme={null} Verified Signals ↓ Policy Evaluation ↓ Decision ``` Parmana does not trust AI output. Parmana evaluates verified facts. *** # Decision Evaluation produces a decision. Example: ```json theme={null} { "action": "approve", "requires_override": false, "reason": "policy_requirements_satisfied" } ``` Or: ```json theme={null} { "action": "reject", "requires_override": true, "reason": "policy_requirements_not_satisfied" } ``` The decision is deterministic because the evidence was deterministic. *** # Attestation Every decision can be signed. ```text theme={null} Decision ↓ Attestation ``` The attestation records: * Policy * Policy version * Decision * Evidence fingerprint * Provenance * Signature This creates a verifiable authorization record. *** # Execution Execution occurs outside Parmana. ```text theme={null} Decision ↓ External System ↓ Execution ``` Examples: ```text theme={null} Bank Transfer Claim Approval Refund Vendor Creation Account Closure ``` Parmana verifies authority. External systems perform execution. *** # Execution Integrity After execution: ```text theme={null} Authorization ↓ Execution ↓ Confirmation ``` Parmana can verify that execution matched authorization. ```text theme={null} Authorized Action ↓ Executed Action ↓ Integrity Proof ``` This creates evidence that the approved action is the action that actually occurred. *** # Banking Example A customer asks an AI assistant to transfer money. ```text theme={null} Customer ↓ AI Assistant ``` The AI captures the request. ```text theme={null} Transfer ₹10,000 ``` The bank verifies facts. ```text theme={null} Customer Authenticated Account Owner Verified Balance Available Destination Verified ``` The verified signals are sent to Parmana. ```text theme={null} Verified Signals ↓ Parmana ``` Parmana evaluates policy. ```text theme={null} Approve ``` The bank executes the transfer. ```text theme={null} Bank Executes Transfer ``` The bank confirms execution. ```text theme={null} Execution Integrity Proof ``` Result: ```text theme={null} AI Captured Request Bank Verified Facts Parmana Enforced Policy Bank Executed Decision ``` *** # Why This Model Matters Without this model: ```text theme={null} Request ↓ Application Logic ↓ Decision ``` Required evidence is often unclear. Authority is difficult to audit. Policy enforcement varies between systems. With the Task → Policy → Schema Model: ```text theme={null} Task ↓ Policy ↓ Schema ↓ Required Signals ↓ Verified Signals ↓ Evaluation ``` The required evidence becomes deterministic. *** # Benefits ## Consistency Every evaluation uses the same required evidence. *** ## Auditability Organizations can prove which evidence was required. *** ## Determinism Policies define required facts explicitly. *** ## Separation of Responsibilities ```text theme={null} AI ↓ Captures Request External Systems ↓ Verify Facts Parmana ↓ Evaluates Policy External Systems ↓ Execute Action ``` Each component has a clear responsibility. *** ## Independent Verification Because evidence requirements originate from policy, auditors can independently verify: ```text theme={null} Which policy applied? Which evidence was required? Which facts were verified? What decision was made? ``` *** # Core Insight The Task → Policy → Schema Model makes authority verification deterministic. ```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 is how Parmana transforms authority verification from application-specific logic into a verifiable system.