Product Engineering · Applied AI Workflow
Intake Desk
An Evidence-Linked Client Intake Review Workflow
I am building a human-reviewed intake workflow for a fictional five-person employment law office. It turns a synthetic inquiry into a structured record, shows the exact source words behind every field, flags missing or conflicting details, and requires approval before anything is written.
Status: Build Starting
A five-week build, starting now. The repository is public but holds only its README so far. The scope, workflow, and evaluation plan are written, and nothing is built yet, so this page describes the plan and reports no results. It will be updated with the live demo, code, and measured evaluation as they exist.
The Problem
Lakefront Legal is a fictional five-person employment law office in Chicago. New inquiries arrive by website form and email. An intake coordinator copies the details into a CRM, checks whether important information is missing, looks for obvious name conflicts, and prepares a record for an attorney.
That is repeated review and re-entry work, and the risks are specific: a missing contact detail, an urgent date nobody noticed, a name that overlaps with a current client. The interesting question is not whether a model can read the message. It is how a person can trust and verify what it proposes.
I am treating the time cost as a hypothesis to test, not a number to claim.
The Workflow
Version one is one narrow workflow, start to finish:
The interface has three screens: a review queue, the review workspace, and the demo CRM. The timeline lives inside the review context instead of becoming a separate platform.
What It Does Not Do
These boundaries belong in the interface, the README, and the demo narration:
- •It does not give legal advice or judge the merits of a matter
- •It does not establish an attorney-client relationship or decide whether someone becomes a client
- •It does not perform a definitive conflict check. A name overlap is only ever labeled a possible conflict
- •It does not accept or reject a prospect automatically, and it never contacts the prospect
Version-One Scope
What ships in the first release, and what is deliberately cut:
Ships
Five fictional scenarios, a React and TypeScript review interface, a FastAPI workflow service, strict structured extraction, exact evidence, deterministic checks, editable human review, server-enforced approval and rejection, a simulated CRM, and a persisted run timeline.
Cut on purpose
Automatic customer replies, email inbox ingestion, real CRM credentials, file uploads, background queues and retries, real-time updates, authentication, multi-tenancy, an agent framework, and vector search.
Cutting those protects the five-week deadline and the core proof: one workflow, finished and measured, is worth more than several half-built ones.
Design Decisions
A proposal, not a decision
The model proposes values. A person decides. Only an explicit approval can change the destination.
Exact evidence beside every value
Each proposed field carries the verbatim source words behind it, and the server checks that the quote really exists in the source.
Deterministic checks for known risks
Missing fields, urgent dates, and possible name matches are computed by ordinary code, so the same input always gives the same warning.
Approval enforced on the server
The decision controls are not trusted to the browser. The server owns the state transitions and blocks a second decision.
A real audit trail
The timeline renders events that were persisted as the workflow ran, not an animation of what should have happened.
Preset fictional inputs only
The public demo accepts only server-owned scenarios, so nobody can paste real legal information and the API budget stays protected.
Architecture
One web application and one API, with no microservices:
How I Will Evaluate It
The evaluation is part of the product, not a last-day addition. It uses 50 hand-labeled, fictional cases:
- •15 complete cases to establish normal extraction quality
- •15 incomplete cases to measure missing-information detection
- •10 conflicting or ambiguous cases to test abstention and escalation to a human
- •5 urgent-date cases to test deadline surfacing
- •5 adversarial cases with instructions hidden in the source text
The initial targets are: 98 percent exact match on email and phone, 90 percent matter-type accuracy, 90 percent missing-field recall, full recall on possible conflicts and urgent dates in the synthetic set, 100 percent valid evidence quotes, no incorrect fields on the adversarial cases, and zero external side effects. These are targets, not results.
Actual numbers will be published even if they miss, with the failure patterns and a representative example for each. A synthetic set does not establish production performance, and the page will say so.
What Done Means
Version one is finished only with all of this evidence:
- •A live URL and a tagged repository release
- •A real 50-case evaluation result and a documented failure pattern
- •A passing end-to-end approval test, and a passing rejection test that proves nothing was written to the destination
- •A keyboard-accessible, inspectable review experience
- •A case study that separates measured results from hypothetical business value
Tradeoffs
Exact evidence
Benefit: it is auditable and easy to verify. Cost: paraphrases and inferences are not represented well.
Exact-string conflict matching
Benefit: it is transparent and testable. Cost: it misses aliases and can flag unrelated names.
Synchronous processing
Benefit: it is simple to build and inspect. Cost: it is not resilient to long processing or restarts.
A simulated destination
Benefit: a safe public demonstration. Cost: it does not prove a vendor-specific CRM integration.
Scope and Limits
This is an independent portfolio project. Every person, organization, date, and legal matter in it is fictional, and the destination CRM is simulated. It is not a client deployment, it does not provide legal advice, and the public demo does not accept real information.
Before any real pilot it would need authentication, durable background jobs with retries, a real CRM sandbox, data-handling review, and an evaluation on real, permissioned data.