Platform Overview

PLICA is an evidence-first forensic layer for images and PDFs in regulated onboarding workflows. It plugs into your existing KYC stack — it does not replace identity vendors.

Scope boundary: Chain of custody from API intake forward — not proof the file was authentic before it reached PLICA. Outputs are decision-support; your team (or policy agent) owns approve / deny / escalate.

June 2026 — document scan & PDF updates: Flat JPEG/PNG uploads with preserve_exif=true run Layer 1 local inconsistency maps (field-sized edit regions). PDF verification combines container forensics + embedded raster pixel analysis (largest raster by default, not “first image in file order”). Forensic PDF reports for PDF intake show metadata only — no embedded raster thumbnail in “Analyzed Evidence”.

Architecture

Forensic scoring and lineage run in parallel after ID extraction. Lineage hits can elevate analyst_summary.verdict_tier to review even when individual file score is clean.

graph TD
  A[Client app / agent] -->|multipart or URL| B[PLICA API]
  B --> C{File type}
  C -->|Image| D[PhotoVerifier]
  C -->|PDF| E[PDF Forensics + embedded rasters]
  D --> X[Extract XMP IDs
DocumentID · InstanceID]
  E --> X
  X --> I[(Lineage index
your corpus + platform
salted client_ref_hash)]
  I -->|lookup| L{Prior fingerprint
in corpus?}
  L -->|cross-client / repeat| S[Lineage signals
XMP_ID_CROSS_CLIENT · REPEAT_SOURCE]
  L -->|no match| S2[No lineage tag]
  D --> F[Deterministic detectors + fraud_score]
  E --> F
  S --> F
  F --> M[analyst_summary
generation_rule · verdict_tier]
  S --> M
  M -->|lineage hit on clean file| HITL[HITL escalation
requires_manual_review]
  F --> G[Evidence lifecycle manifest]
  S --> G
  M --> H[policy_actions]
  HITL --> H
  H --> W[Webhooks · Slack · n8n · agents]

  style S fill:#F5EDE4,stroke:#8B5E3C
  style I fill:#EFEDE6,stroke:#1A3A3A
  style HITL fill:#E8F0EF,stroke:#1A3A3A
  style H fill:#E8F0EF,stroke:#1A3A3A

Read the diagram: technical IDs never skip forensic analysis — they enrich the manifest and can override silent auto-approve via policy_actions, not auto-deny.

What PLICA does

Document forensic check

EXIF/XMP metadata, intrinsic pixels, PDF container phase-1, embedded image analysis.

Structured decision support

analyst_summary, risk_tags, reason codes — not a black-box score alone.

Evidence lifecycle

intake_hash, decomposition manifest (PDF), custody status labels.

Policy hooks

Typed policy_actions and webhook dispatch for agentic workflows.

XMP lineage partial

Internal corpus correlation → review escalation, not auto-deny. No external fraud blacklist.

XMP Lineage — why partial is intentional

For CISO / MLRO conversations: We deliberately label this layer partial because we do not operate an external “black database” of fraud UUIDs — that model conflicts with GDPR minimisation and DORA proportionality expectations.

Lineage runs deterministically inside your accumulated corpus and the platform’s cross-client salted tenant hashes (never raw PII). Each submission strengthens the signal for your ecosystem — a moat single-file detectors cannot replicate.

Lineage hit → review escalation · Not evidence of fraud · Not auto-deny. A clean fraud_score does not suppress HITL when lineage fires.

What PLICA is not

Not a hosted KYC flow (no consumer liveness UI, no dossiers/sessions)
Not AML / sanctions screening
Not an external fraud-UUID blacklist
Not regulatory compliance by itself — you remain controller for End User decisions

Forensic modules (shipped)

Layer	Images	PDF
Metadata / EXIF	✓ editing tools, timestamps, camera hints	✓ Creator/Producer, XMP IDs
Container forensics	—	✓ Phase 1 (incremental updates, OCR/text layer, XObjects…)
Embedded rasters	—	✓ extract + pixel forensics
Intrinsic / GAN	✓ CFA, noise, frequency	✓ on embedded images
Layer 1 edit maps	✓ sterile document scans (`preserve_exif=true`)	—
Content credentials	✓ C2PA / SynthID where present	limited
Barcode (ID PDFs)	—	✓ when `document_type` set

Endpoint lineup — two paths, one engine

`POST /api/v1/verify`

Compliance & analyst depth. Full presentation layer: analyst_summary, forensic_view, evidence_lifecycle, lineage → HITL. Default for regulated onboarding, audit trails, and human review queues.

`POST /api/v1/verify-unified`

Agents & microservices. One contract for image + PDF, unified fraud_score envelope, detector_breakdown, optional customer_id. Built for runtime decision loops — route on tier, not raw score alone.

	`/verify`	`/verify-unified`
Primary buyer	Compliance, fraud ops, forensic analysts	AI agents, orchestration, microservices
Evidence lifecycle	✓ full manifest	via nested result; richest on `/verify`
Lineage → HITL	✓	✓ (verdict floor + recommendations)
Response shape	Rich forensic object	Single unified JSON envelope

Other endpoints

Endpoint	Use when
`POST /api/v1/jobs` · `/jobs/batch`	Async verification — bulk triage, worker queues (docs)
`GET /api/v1/health`	Liveness / deployment check

Verdict model (summary)

Engine verdict + separate analyst_summary.verdict_tier for presentation. Typical fraud_score bands:

< 30   → low signal (REAL band)
30–49  → MANIPULATED band
50–74  → SUSPICIOUS — manual review
≥ 75   → high fraud signal (AI_GENERATED band)

Lineage and conflict rules may force HITL even on low scores. See Response format.

Integration path

API-only today: Bearer token or trial X-API-Key. No mobile SDK or hosted verify redirect.

Request trial access at /api-trial
Send first file via /try or curl — Getting started
Wire policy_actions to Slack / n8n (optional)