Served

Served is an AI agent workspace for legal financial request: it verifies the request, pulls connected financial records, drafts the evidence package. Every release gated by human-in-the-loop review.

Comment

Served - AI that handles financial subpoenas for small businesses without legal teams

One of the letters on a small-business counter may be a financial-record request that looks official. Another may be a scam made to look official. The owner has no legal department, no HR team, and no safe way to know where to begin.

Served extracts the request, checks the referenced sample case through the docket-verification flow, and returns one of three honest outcomes: VERIFIED, CANNOT_CONFIRM, or SCAM INDICATORS. Only a supported, verified financial request can unlock the records workflow. Served then searches the business's own data using the request's displayed criteria, explains every candidate match, and keeps unrelated records outside the packet.

In the D4 demo: 28 sandbox bank transactions searched → 7 included → 2 sent to human review → 19 kept outside. Nothing is sent automatically; the owner controls the final packet.

Inspiration

Served began with a problem one of us saw repeatedly in legal work: people receive intimidating financial-record requests under time pressure and need a clear first step, not an immediate hour of legal strategy. A small business may be asked to produce payroll or payment records in an employment or wage dispute. Understanding the request is only the beginning. The owner may then spend hours searching across payroll exports, different bank accounts, monthly statements, and internal files, checking names, dates, and amounts one record at a time.

The United States has nearly 6.4 million small employer firms. A 2026 Wolters Kluwer CT analysis reported 498,000 U.S. subpoenas recorded in 2025; that figure is not limited to small businesses, but it illustrates the scale of the administrative workflow. Our goal is not to replace counsel. It is to help a business understand the request, verify what can be verified, organize a scoped candidate set, and know when human help is required.

Sources: U.S. Small Business Administration, 2026 Small Business FAQ and Wolters Kluwer CT subpoena-volume analysis.

What it does

  1. Understand the request. READER extracts the claimed court, case number, parties, dates, requested person, and requested record types.
  2. Check the evidence. CHECKER searches the configured docket-verification source and compares exact document excerpts against a sourced fraud-pattern corpus.
  3. Return an honest outcome. Deterministic application code, not a model, selects VERIFIED, CANNOT_CONFIRM, or SCAM INDICATORS. A missing docket result is never treated as evidence of fraud.
  4. Fail closed before financial access. The backend requires a saved analysis, matching ownership, a VERIFIED outcome, and a supported financial request type. Missing or ineligible conditions stay locked; frontend hiding is not the security boundary.
  5. Match only what the request names. For D4, a deterministic matcher freezes the displayed payee and date criteria, then labels every transaction INCLUDE, REVIEW, or EXCLUDE with a reason code.
  6. Keep a human at the consequential boundary. The owner can approve, keep out, or ask counsel about candidate records before exporting a reason-coded manifest. Served never sends records automatically.

The referenced demo materials use pseudonymized sample names, sample business references, and sample case-number references consistent with the GitHub specimens. The uploaded documents are watermarked training specimens. The financial data is synthetic Plaid Sandbox data for the fictional Roe's Kitchen sample flow.

How we built it with Codex and GPT-5.6

Served uses GPT-5.6 through the Responses API with structured outputs. Vision parses the uploaded document, and narrowly scoped workers gather and explain evidence. Their outputs do not directly control the final outcome or financial access.

Codex was our engineering and product-reliability partner throughout the build. We used it to inspect the evolving repository, translate the safety contract into testable boundaries, create and reconcile synthetic fixtures and gold outputs, reproduce integration failures, review UX against backend behavior, and keep the public story aligned with the implementation. The repository README contains the fuller collaboration record and the submission includes the primary /feedback Session ID.

Kathleen designed the product and safety boundaries, including deterministic verdict rules, claim quarantine, the golden regression-test contract, research fixtures, and the evidence-first UX. Yordan built the sourced corpus and independently implemented the Served-specific Grounding Guard architecture, runtime, and full-stack integrations.

The product's division of labor is deliberate: the model gathers evidence; rules decide; the outcome governs data access; a human controls what leaves.

Challenges we ran into

  • Hallucination is unacceptable in this domain. The Grounding Guard rejects unknown pattern IDs, requires exact document excerpts for fraud findings, quarantines unsupported legal quotations, and prevents docket misses from becoming scam evidence. Its 12 release vectors run in CI.
  • Authentication is not authorization. Integrating financial data was only the beginning. The harder problem was making access analysis-scoped, owner-checked, verdict-gated, and fail-closed on the backend.
  • A public demo still needs isolation. First-time visitors can run the reviewed D1-D4 fixtures without Google sign-in through a short-lived, per-visitor demo identity. That identity cannot access another visitor's analysis, personal uploads, saved history, real-bank Link, or email delivery.
  • The demo had to be deterministic. The D4 test path uses 28 seeded sandbox transactions and a gold output of 7 include, 2 review, and 19 exclude. The payment matcher is checked against those record-level expectations.

Accomplishments we're proud of

  • A three-state outcome that no model can override.
  • Twelve Grounding Guard release vectors running in GitHub Actions.
  • Real backend enforcement of verdict-gated financial access.
  • A sign-in-free sample workspace that preserves per-visitor isolation and the same authorization semantics as the authenticated path.
  • Data minimization made visible: 19 unrelated transactions stay outside the candidate packet, each with an explanation.
  • A human-review interface for ambiguous records and a standalone, reason-coded CSV manifest.
  • Guided Clerk Call support using independently sourced court contact routes, never contact information copied from the uploaded letter.
  • A demo that judges can inspect through the sample docket-verification and seeded fixture flow.

What we learned

Trust in a legal-adjacent product is an architecture problem, not a copywriting problem. Every time we replaced a model guess with a source, deterministic rule, scoped credential, or human decision, the system became easier to test and easier to defend.

We also learned that the most valuable automation happens after extraction. The product becomes useful when the verified request governs what data can be accessed, what records are surfaced, what remains excluded, and what a human must approve.

What's next

For this hackathon, we deliberately scoped the working prototype to one high-stakes workflow: financial subpoenas received by small businesses without in-house legal teams. This narrow implementation scope allowed us to build and test the difficult parts properly: evidence grounding, authorization, data minimization, deterministic gating, and human review, while establishing an architecture designed to expand into adjacent financial-document workflows.

The larger opportunity is an AI-powered financial-document preparation layer for consequential requests. With domain-specific rules, verified sources, and appropriate permissions, the same request-to-record workflow could support record collection in wage-and-hour disputes and other employment matters, divorce proceedings, small-claims cases, tax audits, mortgage applications, and immigration filings that require financial evidence. These are future applications, not capabilities claimed by the current prototype; every new domain would require its own coverage, tests, privacy controls, and professional review boundaries.

The greatest value is not simply downloading documents. It is reducing the cognitive and administrative work required to understand what a request asks for, locate the correct records, explain why they match, and keep unrelated information out. A task that can consume hours of manual searching could become a short, reviewable workflow, without allowing the model to decide what must be produced or sending anything automatically.

Next, we would add more financial and payroll connectors, packet history, permissioned adviser sharing, and source-document redaction. The long-term vision is a trusted coordination layer through which individuals, small businesses, and their chosen professionals can verify requests, assemble scoped evidence, review uncertain items, and preserve an accountable record of every decision.

Served provides document information and preparation logistics, not legal advice. It does not decide legal responsiveness, privilege, proper service, or whether production is legally required.

Prior-work acknowledgment

Kathleen introduced the Grounding Guard concept to Served by adapting a citation-verification framework she had drafted during earlier work on the HackTheLaw2026 project. For Served, she redesigned and expanded the concept through deterministic verdict boundaries, claim-quarantine rules, and a golden regression-test contract. Yordan independently implemented Served's architecture and runtime, including the sourced corpus, official-source validation, and corpus allowlisting. No source code or assets were copied from the earlier project.

The Served repository is released under the Apache License 2.0.

Try it

Open servedai.netlify.app. The reviewed D1-D4 samples run without Google sign-in. Choose the D4 payment-records request, confirm the VERIFIED result, connect the seeded sample account, and watch the system search 28 transactions, include 7, route 2 to review, and keep 19 outside. Then make the two human review decisions and export the manifest.

Google sign-in is required only for personal actions such as uploading your own document, opening saved history, or emailing an evidence brief to the verified account owner.

Docket-verification data is used only for the sample verification workflow. Financial data is synthetic and runs through Plaid Sandbox.

Appendix B - Judges' test instructions

Demo URL: https://servedai.netlify.app

Credentials: None are required for the reviewed sample path. Do not use a real bank account; the D4 flow connects only to seeded Plaid Sandbox data.

  1. Open the demo URL in a new or incognito window.
  2. Enter the Demo - reviewed fixtures workspace and choose D4, the payment-records subpoena. No Google prompt should appear.
  3. Run the analysis and confirm the VERIFIED outcome. Open the sample docket evidence view to inspect the referenced demo case.
  4. In the financial workflow, select Connect sample account. This loads the fictional Roe's Kitchen sample account with 28 seeded transactions; there is no institution picker or real-bank login on the sample path.
  5. Let matching complete. The expected result is 28 searched -> 7 include -> 2 review -> 19 exclude, with a reason for every disposition.
  6. Resolve the two review items using Approve, Keep out, or Ask counsel, then export the reason-coded manifest.
  7. Return to the samples and run D2 or D3 to inspect the fail-closed branches. Financial access must remain locked for CANNOT_CONFIRM and SCAM INDICATORS.
  8. Optional: select Upload your own to see the Google sign-in boundary for personal documents. Google authentication is not required to judge the seeded demo.

If the deployed sample path does not reproduce the expected 7/2/19 result, please use the video and repository tests as the authoritative demo artifacts and report the deployment issue to the team.

Built With

Share this project:

Updates