Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.complyhat.ai/llms.txt

Use this file to discover all available pages before exploring further.

ComplyHat’s report flow follows a deliberate split: hosts compose, the user approves, ComplyHat stores, and the compliance memory accumulates from approvals. Every document your team finalizes compounds into one master markdown document the host agent reads on the next draft. Your accumulated compliance posture lives in one place instead of scattering across PDFs. Signing and regulator submission happen in your GRC workflow outside ComplyHat. A finalized report is a “good draft” with a sha256 integrity hash; your signer (DocuSign, Adobe Acrobat, or a human reviewer) takes it from there.

​
The three stages

1

Start a draft

Your host agent calls reports.start_draft with the models in scope and the template you want.
{
  "tool": "reports",
  "arguments": {
    "mode": "start_draft",
    "model_ids": ["8e1f…"],
    "template_slug": "sr_26_2",
    "name": "Q2 SR 26-2 Validation"
  }
}
ComplyHat returns:
  • The template structure (sections to fill).
  • Fresh structured evidence: bias tests, drift snapshots, explainability runs, adversarial results, model cards, and the model rows themselves.
  • Compliance memory: your whole master document of accumulated approved positions. Prior thresholds, prior methodology choices, prior framework interpretations come back as building blocks.
  • A host_instruction directive telling the host how to use the bundle and which audit tags ([EXTRACTED], [INFERRED], [AMBIGUOUS]) to apply.
A reports row is created. There is no status column; the row simply exists, awaiting finalization.
2

Compose the prose in the host

The host agent drafts the document inside your conversation. The user iterates: tighten this paragraph, add a citation, soften that conclusion. ComplyHat is not in this loop; the prose lives in your host until it’s ready.
3

Finalize the approved version

When the user is satisfied, the host calls reports.finalize with the final prose.
{
  "tool": "reports",
  "arguments": {
    "mode": "finalize",
    "report_id": "9a72…",
    "approved_content": "# Q2 SR 26-2 Validation\n\n## Executive summary\n…",
    "approved_content_format": "markdown"
  }
}
ComplyHat persists the prose, computes a sha256 content hash for tamper detection, writes approved_at + approved_by, appends an approved-positions block (report name, frameworks, models, content hash) to your compliance memory automatically, and returns the new memory_version.Approval is immutable: a second reports.finalize on the same row returns 409 ALREADY_APPROVED. Create a new draft to record an updated version.

​
After finalization

No follow-up call is needed: the approved-positions block is already in your compliance memory. To add more detail — methodology rationale, a regulator’s clarification, an internal policy excerpt — the host calls wiki.read, edits the master document, and wiki.writes it back (or wiki.appends a block). On the next reports.start_draft, the whole updated document comes back, so each new report inherits the positions you already took. Sending the document to a signer (DocuSign, Adobe Acrobat, internal legal review) and uploading it to a regulator’s portal happens in your GRC workflow outside ComplyHat. The finalized record stays in your dashboard as the evidence trail.

​
Why this shape

Hosts own prose synthesis

ComplyHat never calls an LLM. Your host brings the reasoning; we return structured citations with audit tags so the prose stays accountable.

The wiki compounds

Every approval improves the next draft. Switching costs grow with every report: a customer with 50 approved reports has 50 reports’ worth of context their agent can reuse.

Counsel signs off externally

The user approves the prose inside ComplyHat; signing and regulator submission happen in DocuSign, Adobe Acrobat, or the regulator’s own portal. We store the evidence trail and integrity hash.

Per-tenant by construction

Wiki pages, structured evidence, and approved content are scoped to your organization_id with Row Level Security. Nothing leaks across customers.

​
Finalization signal

A report is finalized when approved_content IS NOT NULL. That single condition gates DOCX download (GET /api/reports/<id>/docx) and the wiki seeding trigger on reports.finalize. There is no separate status enum.

​
Downloads

Finalized reports download as DOCX via GET /api/reports/<id>/docx. The renderer produces a Word document with headings, lists, approval stamp (approver + sha256 + approved_at), and a per-page footer. Counsel and auditors edit + sign the DOCX in their office suite; if a PDF is required at submission time (regulator intake requirement, archive policy), users export to PDF directly from Word / Pages / LibreOffice via File → Export. The content_hash (sha256 of approved_content) is the immutable-record property: both DOCX and any downstream-rendered PDF re-render deterministically from the same approved bytes, so the hash is what the audit trail verifies, not the file format.
Last modified on May 29, 2026