A Harvard Law dropout raised 6 million dollars for Blue Voice, an AI assistant for police officers that the article describes as a Harvey for officers. The detail that matters is in a single line of the announcement: the system is trained on department-specific laws, local ordinances, protocols and internal guidelines that general-purpose tools can't reach on the public internet. You can read the original coverage on TechCrunch.
Why it matters
The signal isn't that someone else raised money to put an LLM on top of a vertical. The signal is where the value ended up. It's not in the model: anyone can rent the same model through an API. It's in a corpus you can't scrape because it was never published, and in the process of keeping it alive.
That flips the conversation we've been having for two years. For a long stretch, the architecture question was which model to use and how to write the prompt. Today, in any domain with its own regulations, the question is where the document backing the answer comes from, who updates it and how you prove it's still correct.
There's a great piece of side evidence from this week. Vercel wrote up how it built design.md: they tried to port their internal design skill into a public prompt and it failed, because inside the repo the agent reads surrounded by real components and already-published examples, and outside it only has words. They had to write the file from scratch and validate every change against seven evaluation prompts pulled from real cases. It's exactly the same problem Blue Voice faces, at a different scale: context isn't copied, it's distilled and evaluated.
What changes in practice
If you build software for a regulated domain (healthcare, legal, insurance, compliance, public safety), the project's center of gravity shifts. The pipeline looks more like this than like a chat:
┌──────────────┐
│ Regulations │ ordinances, protocols
└──────┬───────┘
│ ingestion + versioning
▼
┌──────────────┐
│ Index with │ each chunk with date
│ provenance │ and jurisdiction
└──────┬───────┘
│ filtered retrieval
▼
┌──────────────┐
│ Agent + LLM │ answers only with a citation
└──────┬───────┘
│
▼
┌──────────────┐
│ Human │ accountable person
│ review │
└──────────────┘The concrete decisions that show up the moment you start:
- Version the corpus, not just the code. An ordinance that changed in March and an index from January produce an answer that's correct according to the system and wrong according to reality. The index needs an effective date per chunk.
- Mandatory provenance. If the agent can't cite the document and the section, the answer doesn't get shown. Without a citation there's no possible audit, and without an audit there's no sale to an institution.
- Jurisdiction filtering before retrieval. One department's protocol doesn't apply in the one next door. That filter is a permissions and data problem, not a prompt problem.
- Your own evals. Vercel's lesson applies just the same here: without a repeatable set of real cases to measure every change against, you're iterating blind.
- Governance as part of the product. OpenAI published the Gilbert + Tobin case, where adoption rests on commitment from leadership, rigorous governance and explicit human accountability. In a regulated vertical that isn't a contract annex: it's a purchase requirement.
| Dimension | General LLM | Vertical with its own corpus |
|---|---|---|
| Source of the answer | Public web and model weights | Internal documentation with provenance |
| Updates | Outside your control | Your own process, at your own cost |
| Traceability | Hard to audit | Auditable by design, if you design it |
| Startup cost | Low | High: ingestion and agreements with the institution |
| Dominant risk | Generic hallucination | Plausible but outdated answer |
When NOT to use it
Here's the uncomfortable part. The TechCrunch piece publishes no accuracy data, no benchmarks, no account of how error is measured. There's no information about hit rate, or about what happens when the model gets it wrong in front of an officer who has to decide on the street. With the available material you can't claim it works well: you can claim someone invested in the thesis.
Cases where I wouldn't put a system like this in yet:
- When there's no owner for the corpus. If nobody inside the organization is formally responsible for updating the documents, the product degrades on its own and nobody finds out until the first incident.
- When the consequence of an error isn't reversible. A wrong answer about a police procedure isn't a UI bug. If the flow doesn't have mandatory human review before the action, the system isn't ready.
- When the client confuses assistant with authority. If someone in the demo says the system decides instead of suggesting with a source, the problem is one of expectations and it's going to blow up in production.
- When you don't have evals yet. Without real test cases, every prompt or model change is a bet. Better to wait and build the set first.
- When search over the same documents is enough. Often the user wants to find the paragraph, not a freshly written version of it. Searching well is cheaper and more auditable than generating.
What I'd do today
If a project like this landed on my desk tomorrow, I wouldn't start with the model. I'd start by collecting twenty real questions from the people who are going to use the system, with the correct answer and the document that backs it. That set is the product spec and the acceptance criteria at the same time. Then I'd build ingestion with dates and jurisdiction, and only then pick a model, which is the easiest part to change and the one that least determines the outcome.