Diligence Desk
Inspiration
I built Diligence Desk to accelerate my own workflow.
As a Chief Legal Officer, I have worked on many acquisitions from inside the deal team. The hardest part of due diligence is not simply collecting documents. It is determining whether the latest delivery answers the request list, reconciling conflicting information, identifying what is missing, and making sure every conclusion can be traced back to its source.
Traditional document review turns senior lawyers (particularly in small teams) into workflow engines. I wanted to build the workflow engine instead, one that accelerates review without pretending to replace professional judgment.
What it does
Diligence Desk is an autonomous, evidence-first M&A due-diligence pipeline rather than a chatbot.
An administrator begins with a guided scoping questionnaire. The system proposes a tailored request list from a server-controlled 52-item taxonomy, but the administrator reviews and approves every request before it becomes the deal’s coverage baseline.
Documents can then arrive through:
- Secure browser upload
- Direct cloud storage ingestion
- A deal-specific email address
From arrival, Diligence Desk validates each file, performs OCR, classifies the document, reconciles its contents against the request list, identifies supported issues, routes them to the appropriate workstream, and updates the review workspace.
Every finding must include a verified citation. The system resolves the quotation against canonical OCR output and displays the source page, exact excerpt, bounding box, and content fingerprint. The model may propose a finding, but it cannot invent the evidence shown to the reviewer. If a claim cannot cite a real page, it cannot pretend that it did.
Invalid or hostile files, such as encrypted, malformed, empty, oversized, or incorrectly typed documents, are quarantined with safe error codes and audit records. One bad file does not stop the rest of the batch.
Once review is complete, Diligence Desk can compose three deliverables from a frozen evidence snapshot:
- A diligence status report
- A red-flag deal memo
- A seller follow-up list
Reviewers can download these as PDFs. The export service has no operation for sending email, sharing files, or inviting attendees, making those unsafe actions structurally unavailable.
How I built it
Google ADK 2.7 workflow graphs orchestrate the model work. The document workflow contains 13 nodes with parallel analysis stages, joins, and durable checkpoints. Gemini 3.7 Flash runs through Vertex AI for classification, reconciliation, issue analysis, scoping, and deliverable composition.
Prompt-injection detection uses three independent layers:
- A deterministic scanner over canonical OCR segments
- Rules inside the primary analysis model
- A specialized Gemma detection model that examines complete page text
The application runs as six least-privilege Cloud Run services covering arrival, processing, email intake, administrative control, review, and Google Workspace exports. The services communicate asynchronously through Pub/Sub. Firestore stores operational state and sanitized review projections, while Cloud Storage holds immutable source documents and derived artifacts. Document AI provides the canonical OCR record used to verify citations.
The review interface is a React 19 application served from the same origin as its FastAPI backend. Role-scoped accounts separate administrators from evidence-only reviewers.
I also built a fully synthetic, watermarked evaluation corpus and executable release gates for security, retries, IAM, factual quality, citation resolution, performance, and cost. In three deployed benchmark runs, the system processed 120 documents without duplicate deliveries. Each 40-document, 339-page run completed in under five minutes.
Challenges I faced
Establishing one source of truth for citations
The original design treated OCR as a fallback. Real testing showed that this made citation behavior depend on which extraction path happened to run. I changed the architecture so every accepted PDF receives canonical Document AI extraction. All page images, excerpts, hashes, and citation checks now derive from that single record.
Making asynchronous processing reliable
Cloud delivery is inherently retryable, so the same event can arrive more than once. I had to design durable checkpoints, leases, version fences, idempotent commits, and a transactional outbox so retries could recover interrupted work without duplicating findings or external effects.
Handling hostile documents safely
A data room may contain malformed files, misleading text, or (in the worst case) instructions aimed at the model. The pipeline needed to detect those conditions without allowing one file to crash the deal. It also needed to distinguish between “all detection layers passed” and “one detection layer was unavailable,” rather than silently presenting the two results as equivalent.
Restricting powerful integrations
Google Workspace permissions are broader than the product actions I wanted to permit. For example, Gmail’s compose scope can also enable sending. Instead of relying only on prompts or policy checks, I created a separate broker whose command schema contains draft creation but no send operation (and I even limited that the administrators). The strongest permission boundary became the absence of the capability itself.
Measuring the real system
A green unit-test suite initially concealed skipped emulator tests and even unreachable features. I added gates that turn unexpected skips into failures and verify that important workflows are actually constructed and reachable. I also learned to report quality with explicit denominators. For example, reconciliation is evaluated using precision, recall, and
$$ F_1 = 2\frac{\text{precision}\cdot\text{recall}} {\text{precision}+\text{recall}}, $$
rather than a context-free “accuracy” percentage.
What I learned
The biggest lesson was that reliable AI systems are built as much from boundaries and evidence as from prompts. (Also I must add that I was particularly impressed with how well Flash 3.7 managed the operations.)
I learned that:
- Tests that provide their own inputs can validate code that production never reaches.
- A safety-critical capability should be structurally unavailable when it is not permitted.
- Model-generated citations are not evidence until a server independently resolves them.
- An unavailable safety layer must be visible; degraded protection should never look like full protection.
- Evaluation results need explicit denominators, frozen inputs, repeatable runs, and release identities.
- Human approval belongs at consequential boundaries: defining scope, accepting evidence, and creating external artifacts.
While not a new learning, the process did emphasize that autonomy does not mean removing the professional from the process. Diligence Desk automates document chasing and evidence organization so the lawyer can spend more time making the judgment that the system should never make alone.
What's next for Diligence Desk
With a few more refinements, including dual models such as Gemini Pro on memo preparation, I feel that this software can be a valuable tool in deal teams everywhere. I intend to keep developing this product and launch it soon. I was pressed for time to finish (I do have a day job as a CLO after all!), but I see potential here and want to take it to the next level. Overall, I've very much enjoyed my first successful hackathon! Thank you very much for allowing me to participate.
Log in or sign up for Devpost to join the conversation.