Concepts

9thSense is built from six primitives that compose into complete verification workflows. Understanding how they fit together makes everything else easier to reason about.

---

Document Types

A Document Type is a pre-built extraction configuration. It knows what a document looks like, what fields to pull out, and how to validate them.

Each Document Type has:

• context_id — unique identifier used in API calls (e.g., kyc_pan_card, fin_bank_statement)
• display_name — human-readable name (e.g., "PAN Card", "Bank Statement")
• category — one of 7 categories
• output_schema — the typed fields that extraction produces, with descriptions
• validation_rules — post-extraction checks (format, checksum, range, cross-field)

40+ pre-built Document Types across 7 categories:

Document Types are config-driven — no code changes required to add or update one. Editing a Document Type auto-snapshots the previous version so you can roll back at any time. You can also create custom Document Types for your own forms and contracts from the dashboard.

---

Checks

Checks are the verification capabilities that decide whether evidence can be trusted. Where extraction reads a document, checks interrogate it — and the person presenting it.

Every check returns a structured verdict with a confidence score and is recorded as an Execution (see below). Checks run automatically as part of an agent's workflow; which ones run, and what confidence they must reach, is policy — defined by Goal Rules.

---

Goal Rules

Goal Rules are the declarative policy checklist attached to every agent. A case cannot complete until every rule passes.

Rules come in three kinds:

• Deterministic comparators — field formats and ID checksums, date validity, numeric thresholds, cross-field consistency. Same input, same answer, every time.
• Verdict thresholds — minimum confidence on check results: liveness ≥ 0.9, face match ≥ 0.85, deepfake risk below ceiling.
• Custom rules — policy written in plain language that the AI evaluates against extracted data.

Each rule declares a severity (hard_stop denies immediately; require allows resubmission) and an on_deny block controlling retries and reviewer messaging. Rules are versioned with the agent and snapshotted into every case.

---

Agents

An Agent is an orchestration unit. It defines a verification workflow as a JSON configuration — what to collect, which checks to run, and what Goal Rules gate completion.

Agents support three intelligence modes:

Key Agent properties:

{
  "goal": "kyc_individual",
  "name": "Individual KYC Agent",
  "tenant_id": "your_tenant",
  "version": "1.0.0",
  "allow_cloud": true,
  "deployed": true,
  "definition": {
    "persona": "...",
    "goal_rules": [...],
    "checks": [...]
  }
}

allow_cloud: false routes all inference through your self-hosted model endpoint — no document data leaves your infrastructure.

Agents auto-snapshot on every save. When a Case is created, the exact agent version used is captured as an agent_snapshot so the audit trail is immutable. You can view version history and redeploy any previous version from the dashboard.

---

Cases

A Case is the unit of work. It represents one verification run for one subject.

A Case has a lifecycle:

collecting → processing → review → completed

• collecting — Documents are being uploaded. The agent may be in conversation with the user.
• processing — Extractions and checks are running.
• review — Automated processing is done; a human reviewer has been flagged.
• completed — A final decision has been made.

A Case contains:

• Documents — uploaded files with their extracted data and check results
• Messages — the conversation thread (for Guided and Autonomous agents)
• Agent snapshot — the exact agent version frozen at case creation time
• Goal progress — which Goal Rules have been satisfied, which are outstanding, and which failed

Cases are created against a specific Agent. The agent's definition at that moment is captured in agent_snapshot — a future change to the agent (or its rules) does not affect the audit record of any existing case.

---

Executions

An Execution is the recorded run of one processing step — an extraction, a check, a webhook delivery — within a case or a direct API call.

Each Execution captures:

• status — pending, running, completed, failed
• result — the structured output: extracted fields, or a check's verdict and confidence
• latency_ms — wall-clock time for the invocation
• from_self_hosted — whether inference ran on your infrastructure or the cloud

Executions are the basis for the audit log, analytics, and cost reporting. Every extraction, check verdict, rule evaluation, and webhook delivery has a corresponding Execution record.

---

How They Fit Together

A typical KYC verification flow:

The agent definition, its Goal Rules, document type schemas, and all execution records are versioned and immutable. Six months later you can reconstruct exactly what happened in any case.

---

Further reading