Compliance Overview

Turn regulatory frameworks into checkable rules and judge documents and document sets against them through /v1/compliance, with a worklist of failed checks.

The Compliance API turns a regulatory or contractual framework into rules a machine can check, then judges documents against those rules. A framework is a workspace document tagged compliance-framework: the document pipeline captures its text and fields, the platform derives editable rules from that text, and a person turns the framework ON. Every document or document set evaluated afterwards is judged against the rules of the ON frameworks, and each rule receives a verdict with a reason and a quote.

The endpoints belong to the Compliance app (catalog slug compliance) and are used in a workspace that has added the app; GET /v1/apps lists a workspace's apps by slug. All routes live under /v1/compliance and accept an API key or an OAuth token. A read needs the read scope. A write needs the write scope and a key whose person is a member or above in the workspace; switching the decider (PUT /v1/compliance/settings) needs an owner.

The surface has five working parts. Frameworks and rules hold what is checked. Evaluations judge single documents, and document sets judge documents that belong together as one whole, optionally against a named rule set that picks rules from several frameworks. The worklist (/issues) and the export collect the failed and unclear checks. Discrepancy runs compare a batch of documents for facts they state differently. A workspace can also move every model decision to its own agent through the external decider and its tasks.

Each verdict is one of pass, fail, not_applicable or unclear. A single-document evaluation judges only what that one document states, so a rule that needs another document (a declaration, a matching order) is judged on a document set instead, where every member's text goes to each call and a verdict's quote names the member it comes from. Results the platform's readings disagreed on carry needs_check: true, which marks the results a person should look at first.

Asynchronous Work and Status

Reading a framework, generating rules, evaluating and comparing all run in the background. The POST routes return at once with a row whose status is processing (or waiting, when the workspace's decider is external), and the caller polls the matching list or detail route until the status is completed or error. A row still processing after the staleness limit reads as error, which marks an interrupted run; running it again starts a fresh one. A route never blocks on a model call.

Worked Example: From a Framework Document to a Failed-Checks List

Take two documents already in the workspace: a framework document and a supplier contract to check. First make the framework document a framework. The platform starts reading its requirements and, once the reading is complete, derives its rules on its own. Frameworks start OFF.

curl -X POST "https://api.talonic.com/v1/compliance/frameworks/from-documents" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"document_ids": ["9d0c4f6e-3b1a-4c53-8f0e-2a7b6c1d5e40"]}'

Poll GET /v1/compliance/frameworks until the framework reports status: "completed" and rules_status: "ready". Review the rules with GET /v1/compliance/frameworks/{documentId}/rules, then turn the framework ON. Only an ON framework counts in evaluations.

curl -X POST "https://api.talonic.com/v1/compliance/frameworks/9d0c4f6e-3b1a-4c53-8f0e-2a7b6c1d5e40/active" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"active": true}'

curl -X POST "https://api.talonic.com/v1/compliance/evaluations" \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"document_ids": ["5b7e2a91-6c44-4d0f-9a3e-71c8d2f0b6a5"]}'

The evaluation is a row with status: "processing". When it is completed, read the verdicts with GET /v1/compliance/evaluations/documents/{documentId} (failures first), or read the failed checks of every evaluated document and set in one call with GET /v1/compliance/issues.

curl "https://api.talonic.com/v1/compliance/issues?unclear=true" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

{
  "data": [
    {
      "document_id": "5b7e2a91-6c44-4d0f-9a3e-71c8d2f0b6a5",
      "set_id": null,
      "filename": "supplier-contract.pdf",
      "display_name": null,
      "document_count": 1,
      "evaluation_id": "c2f1a7d0-84b3-47e6-9d15-0be3a6c97f21",
      "outdated": false,
      "finished_at": "2026-10-20T09:14:52.000Z",
      "results": [
        {
          "framework_document_id": "9d0c4f6e-3b1a-4c53-8f0e-2a7b6c1d5e40",
          "framework_name": "Supplier Code of Conduct",
          "rule_code": "R-07",
          "rule_text": "The supplier must report security incidents within 72 hours.",
          "verdict": "fail",
          "reason": "The contract allows 14 days for incident reports.",
          "quote": "Incidents are reported within 14 days of discovery.",
          "document_id": "5b7e2a91-6c44-4d0f-9a3e-71c8d2f0b6a5",
          "needs_check": false,
          "document_name": null
        }
      ]
    }
  ]
}