> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dabarai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Policy Engine

> The Policy Engine is what makes DABAR auditable by regulators — organizations codify how the AI must reason before it answers, not just what it can access. No competitor has this.

The **Policy Engine** is the core differentiator of DABAR. Instead of trusting an AI model to behave correctly because of a well-written prompt, you **codify the rules** your organization must follow — and DABAR enforces them on every answer.

## Why a policy, not a prompt

Prompts are suggestions. In regulated work, suggestions are not defensible:

* They're invisible to auditors.
* They drift when the model changes.
* They collapse under adversarial input.

A **Policy** is a structured, versioned, auditable artifact. You define it once, DABAR enforces it forever — across every project that uses it and every agent built on top.

## What a Policy contains

Every Policy in DABAR is composed of:

<ResponseField name="name" type="string">
  Human-readable identifier.
</ResponseField>

<ResponseField name="description" type="string">
  The intent of the policy — what it's meant to analyze or enforce.
</ResponseField>

<ResponseField name="rules" type="Rule[]">
  The reasoning constraints DABAR must follow. Each rule has a `name` and a `description`.
</ResponseField>

<ResponseField name="knowledgeFiles" type="File[]">
  Reference documents the policy is authoritative against (regulations, guidelines, playbooks).
</ResponseField>

<ResponseField name="outputFormat" type="object">
  Optional JSON schema describing the shape DABAR must return.
</ResponseField>

See [Create politics](/api-reference/politics/create) for the full API.

## How rules are enforced

Every time DABAR produces an output under a policy, the engine:

1. **Grounds** the answer in the policy's authoritative sources.
2. **Scores** every claim against the rule set.
3. **Labels** each claim as `CONFIRMED`, `NOT FOUND`, or `ESTIMATED`.
4. **Rejects** outputs that violate a rule, instead of silently degrading.

This is why DABAR can be used in contexts where a generic assistant cannot — the enforcement is deterministic and inspectable, not probabilistic.

## Writing good rules

Good rules are **specific, testable, and short**. They describe *how* DABAR should reason, not *what* the answer should be.

<AccordionGroup>
  <Accordion title="Good: Scope">
    > "Only evaluate loan applications above 50,000 USD. For any lower amount, respond with `OUT_OF_SCOPE`."
  </Accordion>

  <Accordion title="Good: Evidence">
    > "Every finding must cite the exact source document and page number. Claims without citation must be labeled `ESTIMATED`."
  </Accordion>

  <Accordion title="Good: Tone">
    > "Respond in formal Spanish. Never use colloquialisms or abbreviations."
  </Accordion>

  <Accordion title="Bad: Vague">
    > "Be careful and accurate."

    This is a vibe, not a rule. DABAR can't enforce it.
  </Accordion>
</AccordionGroup>

## Policies are reusable

A Policy is written once and applied to many Projects. The same "Credit Risk Policy" can run against:

* Monday's batch of applications.
* A single loan under review.
* A live agent the committee queries in real time.

Change the Policy and every downstream Project and Agent reasons under the new rules — no retraining, no reprompting.

## Next

<CardGroup cols={2}>
  <Card title="Primary Sources" icon="database" href="/concepts/primary-sources">
    What kinds of sources a Policy can draw from.
  </Card>

  <Card title="Create a Policy" icon="plus" href="/api-reference/politics/create">
    The full API reference for creating politics.
  </Card>
</CardGroup>