Policy Import: from prose to proof¶
You already have policies. They live in system prompts, in your agent platform's configuration, in a compliance document, in a Confluence page. None of them are enforced before an agent acts, and none of them produce evidence that they held. Policy Import takes that text and returns an enforceable, backtested Charter, with a plain statement of the gap between a policy the model is asked to follow and one that is enforced and proven.
What it does¶
Open the Charter and choose Import policies. Paste the document and click Analyse. In about thirty seconds you get one row per policy statement:
| Column | Meaning |
|---|---|
| Your policy | The statement as you wrote it, and the single outcome sentence it was turned into (amounts, thresholds and approvers kept exact) |
| Enforceable as | How it can be enforced: a deterministic rule checked before execution, a semantic judgement against the statement, a hold for a named approver every time, or a mix |
| Backtest | Replayed against this workspace's recorded decisions: how many actions it would have held or refused, and how many of those went through unchecked at the time |
| Gap | What a prompt-level version of this policy cannot do that the enforced version does |
Statements that are tone or general advice ("be polite", "answer in the customer's language") are listed separately as Guidance only. They belong in the prompt; they cannot be enforced or evidenced on a specific action, and the report says so rather than pretending.
Tick the statements you want and choose Adopt selected in shadow to add them to the Charter without affecting production, or Adopt selected and enforce to make them live. Adopted statements are ordinary Mandates: you can backtest, promote, recompile or disable them like any other.
How it works¶
- Split. The document is divided into atomic statements, one control each. Compound sentences become several statements; guidance is set aside.
- Compile. Each statement goes through the mandate compiler, which grounds action names in the action types this workspace has actually seen, so the resulting rules match your real traffic rather than invented names.
- Backtest. Each compiled statement is replayed over up to the last 30 days of decisions (deterministic rules over up to 500 records, semantic ones over a sample), exactly as an existing mandate's backtest runs.
- Classify and explain. The mix of primitives decides the enforceability class, and the gap text follows from it.
Nothing is created until you adopt. The analysis itself is recorded in the audit log (charter.import_analysed), and adoption as charter.import_adopted.
Whose traffic is the backtest against¶
The backtest uses the decisions already recorded in the workspace. If you are evaluating Xybern with a demo workspace, the numbers describe the demo traffic. To get numbers that are yours, connect one agent in observe mode (see Connect your first agent), let it run for a few days, then import the same policies again: the same statements, replayed over your own agents' actions.
The compile step and the gap analysis do not depend on traffic: they show whether each policy can be enforced and evidenced, which is the point of the exercise.
API¶
POST /api/sentinel/enforcement/mandates/import
{"workspace_id": "...", "text": "<policy document>", "days": 30}
Returns rows (one per statement: source, outcome, category, enforceable_as, label, gap, compiled, backtest), guidance, and totals (statements, enforceable, deterministic, semantic, approval, mixed, not_enforceable, would_have_caught, would_have_triggered). Up to 12 statements are analysed per call; paste a long document in parts.
POST /api/sentinel/enforcement/mandates/import/adopt
{"workspace_id": "...", "status": "shadow" | "active",
"items": [{"outcome": "...", "compiled": {...}, "source": "..."}]}
Creates the mandates (workspace owner or admin only) and returns created and failed.
Requirements¶
Splitting and compiling use the deployment's configured model (XYBERN_LLM_PROVIDER). On a Sovereign install with no model configured the button reports that a model is needed; the rest of the Charter is unaffected. The backtest and the gap analysis run without a model.
A useful habit¶
Run Policy Import before a policy review, a regulator visit or a new agent launch: paste the current policy text, read the gap column, adopt what is missing in shadow, and watch the shadow results for a week before promoting. It turns a document nobody can verify into a Charter everybody can.