Compliance & policy check
What this page is — the capability that checks a document against a policy or rule set you supply, and flags each place it falls short with a severity and a concrete fix.
What it is for — so a written playbook is something documents are actually measured against, rather than a file somebody wrote in 2023 and nobody opens.
The problem it solves — policies exist on paper but nobody checks each document against them, so breaches surface in audits instead of drafts.
Route: /org/papers/documents/<document>/ai → Comply → Compliance & policy check ·
Permission: Use AI drafting/extraction/Q&A for documents. ·
Utility: papers_compliance_check · Cost: 450 credits estimated, 1,800 maximum.
1. What it is
You paste the rules; it reads the document and reports the breaches. That is the whole shape, and it is what makes this capability different from every other check in the module.
| Measures against | Who decides the standard | |
|---|---|---|
| Compliance & policy check | A policy you paste at run time | You, on every run |
| Missing clauses | A generic professional checklist | The model |
| Blind spots | Your finalised corpus | Your own past documents |
| Regulatory drift | Current law in a jurisdiction | The statute book |
| Redline grade | Your clause library's fallbacks | Your configured playbook |
The trade is explicit: this one requires you to state the standard, and in exchange it measures exactly what you asked for. Leave the policy blank and it falls back to general legal and commercial good practice for the document's type — useful, but then it is doing the same job as Missing clauses less precisely.
It flags and recommends. Confirm each flagged violation against the source clause and your own policy before relying on it.
2. Why you would use it
Most organisations have their rules written down somewhere. Almost none have a way to apply them to a specific document without a person who has memorised them.
- It makes a policy enforceable by anyone. A junior reviewer with the playbook pasted in checks as consistently as the person who wrote it.
- It handles rules no generic check knows. "Governing law must be India", "no auto-renewal beyond 12 months" — these are your rules, and nothing but this can test them.
- It doubles as a regulatory checklist runner. Paste a DPDPA or SOC 2 clause checklist and you have a per-document audit.
clause_refon every violation makes it defensible. A compliance finding that names the clause is one you can act on; one that does not is an opinion.- An empty
violations[]is a record. Run against a stated policy and returning nothing is evidence the document was checked, not evidence nobody looked.
Paste the actual rules you must meet, as specific statements with numbers in them. "Be commercially reasonable" produces nothing useful. "Liability must be capped at 12 months' fees" produces a finding you can send.
3. What you provide
| Input | Required | Notes |
|---|---|---|
| Policy / rule set | Optional | The rules to check against. Paste your playbook, a compliance checklist, or a specific standard |
Leave it blank to check against general good practice for this document type.
Internal playbook — a set of hard rules:
Liability must be capped at 12 months' fees. No auto-renewal beyond 12 months. Governing law must be India.
Regulatory checklist — a set of required elements:
DPDPA: personal data purpose stated, consent recorded, breach-notice clause present, data-retention limit defined.
Both forms work. Rules that state a threshold, a required element, or a prohibited term produce the best findings; rules that state a principle produce the worst.
4. What it reads automatically
| Read from the document | Used for |
|---|---|
| Document text — the full rendered body | The evaluation |
| Title & family — e.g. "MSA" | The fallback standard when no policy is supplied |
| Parties — everyone named | Whose obligations a rule bites on |
| Key field values — filled schema fields | Testing rules that reference amounts, terms and dates |
The last row is what lets a rule like "no auto-renewal beyond 12 months" be tested against the document's actual term field rather than against its prose alone.
5. What you get back
violations[] — each breach. Empty if the document fully complies.
| Field | Type | Values | Means |
|---|---|---|---|
rule | string | — | The rule from your policy that was breached, quoted back |
provision | string | — | What the document does instead |
clause_ref | string | — | Where in the document |
severity | enum | high, medium, low | How serious the breach is |
explanation | string | — | Plain-English account of the gap |
recommendation | string | — | The concrete fix |
Plus overall_assessment — whether the document is broadly compliant, and the most serious gaps.
And disclaimer — AI compliance guidance, not legal advice.
rule quoting your own input back is the field that makes the output auditable: you can see which
of your rules fired, and which did not.
6. Worked example
A legal operations lead checks an inbound MSA against the organisation's contracting playbook.
Input — policy / rule set:
Liability must be capped at 12 months' fees. No auto-renewal beyond 12 months. Governing law must be India.
One entry from violations[]:
severity:
highrule: "Liability capped at 12 months' fees" provision: "Clause 9 leaves liability uncapped" recommendation: "Add a cap equal to 12 months' fees paid"
What the lead does with it. The finding is a direct comparison between a rule they wrote and a clause that exists, so there is nothing to interpret — the recommendation goes into the redline verbatim.
The other two rules did not fire. The governing law is India, and the term is a fixed 12 months with no auto-renewal. That absence is the useful half of the result: three rules stated, one breached, two verified. The lead records the run as the compliance check for this document.
Had the policy been left blank, none of these three rules would have been tested — the document would have been measured against generic good practice instead, and an uncapped liability might well have been flagged, but "governing law must be India" could not have been.
7. Running it
- Open the document in Orbit Papers.
- Open the AI Assistant drawer, or go to the document's AI workspace.
- Choose Compliance & policy check under Comply.
- Paste your policy or rule set, or leave it blank for general good practice.
- The findings appear in a result tab and are saved to the document.
Because the policy is a run-time input, the saved result is only meaningful alongside the rules it was run against. When your playbook changes, previous results do not — re-run rather than trusting a cached one.
Compliance & policy check cannot be set to run automatically. It is one of four capabilities absent from the type's AI Config tab, and the reason follows from §1: its value comes entirely from the policy you paste, and an automatic run has none — it would check every document against generic good practice while appearing to check it against your rules. See the capabilities reference for the other three.
8. The admin contract
| Must be true | Where | What happens if it is not |
|---|---|---|
| Your role holds Use AI drafting/extraction/Q&A for documents. | Role editor | The AI Assistant button does not appear |
The papers_compliance_check utility is active | Orbit AI Flow → utilities | "This utility is currently disabled" |
| The utility is enabled for your organisation | /org/ai-utilities | Absent from Comply, with no error |
papers.ai_monthly_credit_cap not yet reached | System Config | "monthly AI credit cap reached: n of n credits used this month" |
| A written policy exists that people can paste | Your organisation | Every run falls back to generic good practice, and the capability's whole advantage is lost |
| The policy is kept current | Your organisation | Documents are measured against rules you no longer hold |
Unlike most of the module, the binding prerequisite here is not configuration in Papers — it is that somebody maintains the policy text and people know where to find it.
For a confidential document, auto-run is default-denied — a platform administrator must set
papers.ai_confidential_cloud to the literal allow, and the block appears only in the server log.
A manual press still works, and where a local model key is configured the run is forced on-prem and
audited on the timeline as ai_local_routed.
9. Don't confuse this with…
| Redline grade | Uses the configured clause-library playbook. This uses text you paste at run time |
| Regulatory drift | Measures against current law. This measures against your policy |
| Missing clauses | Generic professional expectation, no input needed |
| Redaction suggestions | Finds sensitive data. This finds rule breaches |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| The findings are generic | The policy field was left blank, so general good practice applied (§3) |
| A rule I stated did not fire | Either the document complies with it, or the rule was too vague to test. State a threshold |
violations[] is empty | The document complies with every rule you supplied. Check the policy actually pasted |
| The same document passed last month and fails now | The policy input changed. Results are only meaningful against the rules they were run with (§7) |
| I cannot find it in the type's AI Config tab | It is not offered for auto-run (§7) |
| A violation names a clause that reads compliantly | Verify against the source clause — it is advisory and can misread. The explanation says what it thought |
| The capability is missing from Comply | Role lacks Use AI drafting/extraction/Q&A for documents., or the utility is off for the organisation (§8). The document type does not gate it — AI Config controls auto-run only |