> ## 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. # Policies Define Evidence, Not Inputs > Why autonomous systems must govern facts instead of user interfaces. One of the first questions organizations ask when building autonomous systems is: > What information should we collect from the customer? At first glance, this appears straightforward. A customer wants to transfer money. The system needs information. The system asks questions. The process seems simple. But this question hides a deeper problem. Who decides which questions should be asked? And more importantly: > Why are those questions being asked in the first place? The answer reveals an important distinction between information and evidence. As autonomous systems become capable of executing actions, that distinction becomes critical. ## The Temptation To Start With Inputs Most systems begin by defining inputs. For example: * Transfer amount * Beneficiary name * Beneficiary account * Source account The system collects these inputs and sends them through a workflow. This approach feels natural because inputs are visible. Customers provide them. Forms collect them. APIs transmit them. But inputs are not the thing we actually care about. What we care about is whether an action should be executed. The information required to make that decision is evidence. Not inputs. ## Inputs Are Claims Consider a beneficiary transfer. A customer provides: * Beneficiary name * Beneficiary account These are inputs. They are claims. They are not verified facts. The customer cannot provide: > beneficiary\_verified = true Only the banking system can determine that. Likewise, a customer cannot provide: > identity\_verified = true or > available\_balance = true or > fraud\_score = 12 These are not inputs. These are verified facts. This distinction is fundamental. Claims enter the system. Facts are established by the system. Policy enforcement should operate on facts. Not claims. ## Signals Versus Verified Signals Signals are claims entering the system. Examples: * beneficiary\_account * beneficiary\_name * transfer\_amount Signals are not trusted facts. They represent information provided by customers, applications, APIs, or AI systems. Verified signals are facts produced by trusted systems. Examples: * beneficiary\_verified * identity\_verified * available\_balance * fraud\_score Verification transforms claims into facts. Policy enforcement operates on verified signals, not raw signals. Verified signals are facts produced by trusted systems. Examples: * beneficiary\_verified * identity\_verified * available\_balance * fraud\_score The role of verification is to transform signals into verified signals. The role of policy enforcement is to evaluate verified signals. These are different responsibilities. Confusing them creates ambiguity. Separating them creates trust. ## The Mistake Of Putting Inputs In Policies A common idea is: > Why not define customer inputs directly inside the policy? At first, this seems reasonable. A policy requires beneficiary verification. Why not specify exactly which customer information is required? The problem is that verification is organization-specific. Consider the verified signal: > beneficiary\_verified Different organizations may establish this fact differently. Bank A may require: * beneficiary account Bank B may require: * beneficiary account * beneficiary name Bank C may require: * beneficiary account * beneficiary name * OTP confirmation All three ultimately produce the same verified fact: > beneficiary\_verified = true The policy should not care how the fact was established. The policy should care only that the fact exists. This leads to a critical principle: > Policies should define evidence, not inputs. ## Policies Define Evidence A policy should answer one question: > What verified facts must exist before this action can be evaluated? For example: * identity\_verified * beneficiary\_verified * available\_balance * fraud\_score * transfer\_amount These are evidence requirements. Not user interface requirements. Not workflow requirements. Not implementation requirements. The policy does not dictate how those facts are obtained. The policy dictates that those facts must exist. This distinction makes policies portable across organizations, systems, and customer experiences. ## The Task → Policy → Schema Model Organizations do not think in policies. Customers certainly do not think in policies. They think in tasks. Examples include: * Transfer Money * Add Beneficiary * Issue Refund * Approve Vendor Payment A customer chooses a task. The organization maps that task to a policy. The policy defines a schema. The schema defines required verified signals. The resulting architecture becomes: ```text theme={null} Customer Chooses Task ↓ Task ↓ Task → Policy Mapping ↓ Policy ↓ Policy Schema ↓ Required Verified Signals ↓ Signal Verification ↓ Verified Signals ↓ Policy Evaluation ↓ Decision ↓ Execution ``` This structure creates deterministic enforcement. 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. ## The Trust Boundary This architecture creates a clear separation of responsibilities. **Customer** Provides information. **AI** Collects information and assists interaction. **Operational Systems** Verify information and establish facts. **Parmana** Evaluates verified facts against policy. **Execution Systems** Execute approved actions. This separation is important because it prevents policy enforcement from depending on AI reasoning. AI can help gather information. AI can assist workflows. AI can improve user experiences. But AI does not determine truth. Verification determines truth. And policy enforcement operates on verified truth. ## Evidence Is The Stable Interface Customer experiences change. AI systems change. Verification systems change. Organizations change workflows. Policies should not. A policy should define the evidence required for evaluation. How that evidence is collected is an implementation detail. How that evidence is verified is an operational concern. Policy enforcement begins only when verified facts exist. This separation allows policies to remain stable while systems evolve around them. ## Why This Matters The future will contain increasingly autonomous systems. The challenge is not merely collecting information. The challenge is establishing evidence. Inputs are claims. Verified signals are facts. Policies define the facts required for evaluation. Verification establishes those facts. Policy enforcement determines whether execution is allowed. As autonomous systems become more capable, organizations will need a reliable mechanism to ensure actions remain subject to human-defined rules. That mechanism cannot depend on user interfaces. It cannot depend on workflows. It cannot depend on AI reasoning. It must depend on evidence. Because autonomous systems should be governed by facts, not forms. And policies should define evidence, not inputs.