Product roadmap

What's built, and what's next

ClaimLens is built on one principle: fast for honest claims, careful with suspicious ones, and accountable for every decision.Here's what's live today and where it's headed.

Shipped & verified Planned (Phase 2)

Shipped

Foundation & security

Multi-tenant isolation enforced in the database (Hibernate @TenantId), not by convention
JWT auth with server-side, per-request RBAC (permissions resolved from roles, not the token)
Brute-force protection — sign-in is rate limited per client, shared across instances via Redis
Append-only audit trail across state changes
Refresh-token rotation with theft detection

Claim lifecycle

Three-step intake — create draft, upload documents, submit — resumable by design
Hard vs soft validation: reject only what's certainly invalid; everything else is a fraud signal
Policy version pinning — a claim is judged against the terms the customer actually bought
Two-way information requests — an investigator asks for a document, the customer uploads it from the portal, and the claim automatically re-opens, reprocesses and re-notifies
Full lifecycle through assignment, investigation and an approve/reject decision

Document AI (OCR)

Google Cloud Vision OCR, swappable behind an interface (Tesseract offline)
Per-document processing with structured field extraction (registration & policy numbers)
Document versioning — re-uploads keep the full history

Image fraud forensics

Perceptual-hash duplicate detection across a tenant's claims (top motor-fraud pattern)
ORB feature-matching for lightly-edited reuse
Three-state EXIF — only genuine inconsistency counts; missing metadata is never suspicion
Synthetic / AI-generated image soft signal

Fraud engine

Config-driven rules engine with per-rule scoring — every score is explainable
Risk levels (high / medium / low) surfaced to investigators
Exactly-once fraud job that settles on terminal state, so one bad file can't hang a claim

AI policy intelligence (RAG)

Plain-language coverage answers grounded in the policy wording, with citations
Retrieval scoped to the claim's pinned version and to the tenant (no cross-tenant leak)
Gated pgvector + HNSW option for scale; in-Java cosine everywhere else
Graceful degradation — falls back to an offline answer if the AI provider is unavailable

Portals

Customer self-service portal — file, upload, submit and track your own claims
Ownership scoping below the tenant, so one customer can never see another's claim
Cross-tenant platform console — analytics, tenant lifecycle, and impersonation

Performance & platform

Redis caching of role→permission resolution (Caffeine in dev, Upstash Redis in prod)
Provider-agnostic cache — the same code runs on either backend, switched by profile
A cache outage degrades to a database read; it can never take the service down
Pluggable object storage — local filesystem in dev, S3-compatible (Cloudflare R2) in production
Tuned HikariCP connection pool sized for a managed Postgres (Neon)
Containerised end to end: Docker images for all three services plus a Render blueprint

Product & experience

Branded HTML claim emails with an attached PDF report — stats, decision, investigator, and the uploaded photos
Email via a swappable sender (Resend in production; logs offline)
One-click demo logins for every role; responsive UI with light/dark themes
MDX blog and this roadmap

Next — Phase 2

Deliberately deferred, not forgotten — each was a scope decision, sequenced behind a solid V1.

Observability

Metrics (Micrometer → Prometheus/Grafana) and structured JSON logs carrying trace / tenant / user context. The deployment path — Docker images, a Render blueprint, Neon, R2 storage and auth rate limiting — is already built.

Vector search tuning

pgvector with an HNSW index already ships (opt-in). What's next is tuning that index and a backfill path so retrieval stays fast as the policy corpus grows.

More claim types

Health and property lines on the same engine — the product is already claim-type-agnostic by construction.

Real-time notifications

WebSocket / SSE push so investigators and customers see updates without refreshing.

Outbox event worker

The outbox table ships today; the async publisher/consumer is the next step for reliable event delivery.

Per-document reprocessing

The resubmission loop is live end-to-end; the next refinement is re-OCRing only the document that changed rather than re-running the whole claim's pipeline.

Claimant mobile experience

A phone-first flow for filing a claim and uploading damage photos at the roadside.

Analytics date ranges & export

Tenant and platform dashboards ship today, but report over all time. Next is filtering by date range and exporting to CSV / PDF.