Work order · Internal · Confidential · CDZ-WO-2026-0479
Claim Evidence Trail — one-day team build
A working demo that takes a real insurance claim scenario and shows, step by step, which policy version applies, which clauses support the decision, what's missing, who can approve it, and what must be re-checked when the policy wording changes. Every AI statement is checked against the source text before anyone sees it.
Assigned to
Codeaza Development Team
Track time in WebWork under this work order
Shared Slack thread with Asim for blockers, regular check-ins
Issued by
Muhammad Asim — Founder & CEO
Codeaza Technologies, Islamabad, Pakistan
Prospect: insurtech founder (name and context from Asim, verbally)
Internal document: do not share outside the team
01What the prospect cares about
The prospect turns insurance policy wordings into structured, traceable data for insurers, brokers and AI agents. From our first call and their public posts, these are the things they talk about. The demo must hit every one.
"Which version applies?" Before trusting an AI claims answer you must know which policy version, schedule and endorsements were in force.
"Which clauses support it?" And how they interact with definitions, conditions and exclusions.
"What's missing or ambiguous?" A fluent answer is not a correct one.
"Who can approve it?" AI gets bounded authority, and a named person stays accountable.
Wrong references are a real problem. The Australian complaints authority is already seeing AI-written complaints that cite clauses that don't exist.
Versioning. Their insurer customers value it most, but today they only learn about a new version when a user uploads it.
No "thin AI wrappers". They dislike AI bolted onto a workflow and called innovation. They respect hard, unglamorous groundwork.
Human in the loop. Always double-check AI output. Getting enterprise-ready this year.
The reaction we want: "I need to know more about you." They should leave thinking: these engineers understand my problem, build properly, and could build the engineering around my product.
Positioning: we are not rebuilding their product. Their core (turning wordings into structured meaning) appears in our demo as a clearly marked, swappable slot: "Interpretation source: demo extractor — replaceable with the prospect's API". Everything we show is the plumbing around it: version tracking, evidence checks, review workflow, audit trail, evaluation, integration.
02The 5-minute demo (build exactly this)
A claim comes in
One realistic cyber claim, e.g. a small business hit by ransomware, with a date of loss, policy start date and a short incident note. It's pre-loaded, so one click starts the demo.
Which version applies
A timeline of the policy wording versions with their effective dates. The system picks the version in force on the policy start / date of loss and explains why, not just the newest file.
The evidence trail
An interactive map: the cover clause, the definitions it relies on, then the exclusions and conditions that could change the outcome (e.g. notification deadline). Each node opens the exact source text, page and clause number.
Every citation checked — the "wow" moment
Each AI statement shows a green tick only if its quote is found word for word in the right version of the document. Show one AI draft line being rejected in red: "quote not found in source". That is the exact problem the prospect worries about, and we catch it.
What's missing
A short list of facts the decision still needs (e.g. "Was MFA enabled?", "Date the insurer was notified"), each linked to the clause that makes it matter.
Bounded authority & audit trail
The recommendation goes to a human. A claims officer can approve up to a set limit; above it, the system escalates to a senior assessor. Every step is written to an audit log: who, what, which version, which clauses.
The wording changes — what needs review
Click "Check for new version": a newer wording is detected and compared clause by clause. The system then flags "2 approved decisions rely on clauses that changed — review needed". This is the closer.
JSON out & quality score
A JSON tab / API endpoint with the full evidence pack, and a small quality panel: citation accuracy on a test set of questions, last evaluation run. Shows we measure, not guess.
03Team lanes
Documents & versionsFind the public policy wordings (two versions of one cyber wording from the same insurer, with effective dates). Split into clauses with page numbers and types (cover, definition, exclusion, condition). Link clauses that reference each other. Build the version timeline and clause-by-clause comparison.
clauses.json · versions.json · diff.json
Reasoning & verificationClaim scenario. Version-selection logic. Claude builds the evidence trail and "what's missing" list as structured JSON. The citation checker (exact quote match against the selected version; reject anything not found). Change-impact check: which approved decisions use changed clauses.
evidence.json · impact.json
Front endAll 8 demo screens: claim, version timeline, evidence map (React Flow or similar), source viewer with highlighted text, gaps, approval with limits, comparison view, JSON tab. Codeaza colours, calm and serious, no gimmicks.
Clickable demo
Platform, audit & QAFastAPI service serving the JSON, audit log, approval-limit rules, quality panel (10–15 test questions with expected clauses, scored), deployment behind a password. In the Check stage: reads both wordings and hand-checks every clause the demo shows.
API · audit · eval · URL
Kick-off (whole team): agree the JSON shapes for clauses, versions, evidence and impact, and commit sample files. The front end builds against the samples from minute one, so nobody waits on anybody.
04Day plan
1 · Kick-offKick-off, JSON contracts, repo set up, documents chosen
Contracts committed
2 · BuildLanes build in parallel against sample data
Check-in with Asim
3 · Wire upReal data replaces sample data, screens wired to the API
Demo runs end to end
4 · CheckHand-check of every clause and citation shown, fixes, deploy
Zero wrong citations
5 · RehearseTwo full rehearsals with Asim, final polish, backup screen recording
Signed off · 22:00 PKT
Cut order if behind: drop step 8's quality panel first, then the evidence map becomes a list. Never cut steps 2, 4 or 7. They are the reason the demo exists.
05Stack
Build
API: Python + FastAPI
PDF: PyMuPDF / pdfplumber (text + page numbers)
AI: Claude Sonnet 5.5 (claude-sonnet-5-5), structured JSON output only
Citation checker: plain code, no AI. Normalised exact-match of each quote against the selected version's text
Front end: React + Vite + Tailwind, React Flow for the evidence map
Run
Pre-computed: all demo results cached, so every click is instant. Live re-run is a bonus.
Hosting: one private URL on our Coolify / Dokploy, password-protected
Repo: new private repo in the Codeaza org, README with run steps
Backup: a 5-minute screen recording of the full demo, in case the call has trouble
Keys: our own Anthropic key from the team vault, never committed
06Done means
Must have
All 8 demo steps click through in under 5 minutes with no waiting
Real, public policy wordings; source URL and download date for each
Version choice is correct and explained
Zero wrong citations on screen, checked by a person
At least one AI line visibly rejected by the citation checker
Change step flags the right decisions for review
Nice to have
A second claim scenario (e.g. business email compromise)
Evidence pack export as PDF
Upload your own wording and run steps 2–4 live
A "drop-in" panel styled like a claims system screen, showing how it would sit inside an insurer's tools
07Ground rules
Public documents only. Real insurer wordings published openly. If no earlier public version can be found, use the real current wording plus a clearly labelled "simulated amendment" for step 7. Never pass simulated text off as real.
Hands off the prospect's product. Don't sign up to, scrape or copy their product, data, UI or wording. Don't use their product terms (e.g. "system of meaning", "ontology") in our demo.
No client IP. Build fresh. Don't copy code, prompts, data or credentials from any client repo. Reuse ideas only.
No names. Nothing in the UI, repo or demo mentions any client or prospect. The swappable slot says "the prospect's API" until Asim says otherwise.
Accuracy over features. One perfect claim beats three average ones. If a statement might be wrong, leave it out.
Not a product. Footer: "Demo · built by Codeaza on public policy wordings". No pricing, no external sign-ups.
Tone. Serious and quiet: no confetti, no chatbot as the hero. The prospect dislikes AI gimmicks. The rigour is the wow.
Blockers. Stuck for more than 30 minutes? Post in the Slack thread. Asim decides on cuts.
Sign-off
The team confirms the lanes at kick-off. Asim signs off after the 22:00 PKT rehearsal.
© 2026 Codeaza Technologies — internal work order. Confidential, not for external distribution. · CDZ-WO-2026-0479 rev 2 · Muhammad Asim, muhammadasim@codeaza.org