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.
What a Policy contains
Every Policy in DABAR is composed of:Human-readable identifier.
The intent of the policy — what it’s meant to analyze or enforce.
The reasoning constraints DABAR must follow. Each rule has a
name and a description.Reference documents the policy is authoritative against (regulations, guidelines, playbooks).
Optional JSON schema describing the shape DABAR must return.
How rules are enforced
Every time DABAR produces an output under a policy, the engine:- Grounds the answer in the policy’s authoritative sources.
- Scores every claim against the rule set.
- Labels each claim as
CONFIRMED,NOT FOUND, orESTIMATED. - Rejects outputs that violate a rule, instead of silently degrading.
Writing good rules
Good rules are specific, testable, and short. They describe how DABAR should reason, not what the answer should be.Good: Scope
Good: Scope
“Only evaluate loan applications above 50,000 USD. For any lower amount, respond with OUT_OF_SCOPE.”
Good: Evidence
Good: Evidence
“Every finding must cite the exact source document and page number. Claims without citation must be labeled ESTIMATED.”
Good: Tone
Good: Tone
“Respond in formal Spanish. Never use colloquialisms or abbreviations.”
Bad: Vague
Bad: Vague
“Be careful and accurate.”This is a vibe, not a rule. DABAR can’t enforce it.
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.
Next
Primary Sources
What kinds of sources a Policy can draw from.
Create a Policy
The full API reference for creating politics.