Client journey & architecture · June 2026

How a client works with Plica

For investors, compliance, counsel, and enterprise pilots. What we sell, how a document reaches verification, how the client gets results, where data lives — with honest shipped / roadmap / out-of-scope status on every line.

01 What we sell

PLICA is an independent forensic layer for images and PDFs in regulated file workflows.

We do

We don't

Prove whether a file was tampered with (metadata, PDF structure, OCR vs text layer, pixel / GAN)

Hosted KYC / liveness / camera session

Return evidence: JSON, PDF report, hash, policy hooks

AML / sanctions / registry screening

Embed into your onboarding, claims, underwriting

Replace Sumsub, Onfido, LexisNexis

Chain of custody from the moment of intake at the API

Prove the document was authentic before it reached you

Product boundary: we answer "is this file technically forged or synthetic?" — not "does the company exist and is the invoice true in the real world?" The latter belongs to your registries, issuer systems, and manual review.

02 Client journey (B2B)

┌──────────────┐ ┌──────────────────┐ ┌────────────────┐ ┌──────────────────┐ │ Pilot / │ ─► │ API integration │ ─► │ Production │ ─► │ Audit / dispute │ │ trial /try │ │ + webhook/DPA │ │ auto-policy │ │ PDF + hash │ └──────────────┘ └──────────────────┘ └────────────────┘ └──────────────────┘

Stage	Actions	Artifacts
1. Access	API key (sandbox → prod), optional `/try` for demo	API key, trial limits
2. Integration	Call from CRM / KYC portal / bot / back office	`POST /api/v1/verify` (sync) or `POST /api/v1/jobs` (async batch)
3. Decision	Route by `policy_actions`: reject / HITL / approve	Webhook into your queue
4. Audit	Retain forensic record per DPA	PDF, `analysis_id`, verify URL, hash

The user is the client's compliance / fraud / ops team or their system (API-to-API). A bank's end customer works in the bank's UI, not in a separate "Plica banking app."

03 How a document reaches verification

The primary channel is the API (not a desktop client, not a separate retail upload portal):

Upload: multipart — JPEG, PNG, HEIC, WebP, PDF (up to server limit)
URL: public image_url / file_url (SSRF-protected)
Context: document_type, customer_id, additional_info (case JSON), product_source
Async batch: POST /api/v1/jobs/batch — up to 20 files, shared batch_id, poll or webhook_url

Typical entry points: client uploads a PDF into their onboarding → their backend → Plica API · operator in the back office → their UI → Plica API · AI agent / bot → API (agent_fast for accelerated PDF).

04 How the client gets results

Channel	Contents	Status	Purpose
JSON (sync)	`verdict`, `fraud_score`, `analyst_summary`, `forensic_view` (`claim_lists`, `risk_signals`), `policy_actions`	Shipped	Automation, CRM, rules engine
JSON (async)	`POST /jobs` → poll `GET /jobs/{job_id}` → `GET /jobs/{job_id}/result`	Shipped	Bulk triage, slow PDFs, worker queues
PDF	Forensic Authenticity Report + verify link + hash	Shipped	MLRO, counsel, regulator, disputes
Policy webhook	`plica.policy.enforcement` on critical `policy_actions`	Shipped	HITL queue, auto-reject
Job webhook	`plica.analysis.completed` per `webhook_url` on job	Shipped	Push when batch file finishes
Batch export	CSV / zipped PDFs by `batch_id`	Roadmap	One-click compliance export

requires_manual_review and HITL are a signal into your process — not a separate "Plica lawyer queue." On a definitive reject (e.g. Tampered 85/100) the report gives one enforcement path — Reject — with no contradictory "mixed signals."

05 Applications — what exists and what's planned

Surface	Status	Role
REST API	Prod	The core product (`/verify`, `/jobs`)
Trial `/try`	Shipped	Pilot, demo, manual single-file check
PDF report	Shipped	Compliance, audit trail
B2B console (keys, usage, history, retention)	Roadmap	Self-serve management
Desktop / mobile SDK	Not in scope	Clients don't want another client; KYC sits with vendors

Stance: API-first. The web surface is for trials and light review — not a replacement for the client's corporate portal.

06 Data storage

Type	Where	Principle
Analysis metadata	PostgreSQL / SQLite	Scores, verdict, structured JSON
Files (optional)	`data/verify_images/` or object storage	Per DPA: retention, region (EU), right to deletion
Cache	Redis	Performance, not a long-term archive
Reports	On-demand + preview cache	PDF + hash for independent verification

Privacy by design (enterprise):

Tenant-scoped — no shared cross-tenant fraud database holding PII
Configurable retention: hash + forensic record only, no raw file kept after analysis
Encryption in transit (TLS) and at rest — per contract

For counsel: we retain proof of what was examined at intake, in the scope agreed in the DPA — not a perpetual archive of every passport scan.

07 Batches and multiple subjects

Document batches — shipped: POST /api/v1/jobs/batch (up to 20 files) returns a shared batch_id and one job_id per file. Poll GET /api/v1/jobs?batch_id=… or each GET /api/v1/jobs/{job_id}; fetch full JSON at GET /api/v1/jobs/{job_id}/result. Pass customer_id and additional_info (e.g. case_ref) — echoed in the report, not used in scoring.

Purpose: bulk triage — which files are suspicious — before manual review of the critical fields.

"By registries" — not core, orchestration possible:

Company registries, LexisNexis, credit bureau — the client's subscription and integration
Plica doesn't compete with data vendors: we catch the file forgery, they establish the truth about the counterparty
Optional later: webhook "forensic FAIL → skip the KYB call" or "PASS → continue your pipeline"

08 Content validation — the report's boundary

In the report today

Not in scope without a separate contract

Arithmetic in the text (PASS / FAIL)

Existence of the address, vendor, or account in real registries

OCR vs machine-readable text layer (the classic amount-swap pattern)

"Common-sense" content against external authoritative sources

Barcode / MRZ cross-check (for IDs)

This doesn't diminish the forensics: a tampered utility bill with 16% OCR similarity and amount drift is caught before any LexisNexis lookup.

09 Typical integration architecture

[End customer] │ ▼ [Client portal: onboarding / claims / CRM] │ upload / subject_id ▼ [Client backend] ── sync: POST /api/v1/verify │ async: POST /api/v1/jobs/batch ──► [PLICA API] │ │ │◄── JSON / job_id + poll ───────────┘ │ ├──► auto-reject (policy_actions) ├──► client HITL queue (webhook) └──► PDF + hash archive (compliance)

Neighbors in the stack (complementary, not replaced): Sumsub / Onfido (identity), LexisNexis / registries (KYB), core banking. Plica sits between the file at intake and the decision.