Internal. Common Legal Help AI. Working draft for comment.
For content managers and knowledge base teams

Getting Your Content Ready for AI

Your website, your guides, your training decks, and your referral lists are the raw material for every AI tool. This is the cohort's playbook for turning that backlog into a knowledge base an AI can use safely, without losing control. It is a journey through stages, not a one-time export, and you do not have to reach the end to get value.

The journey, in six stages

From scattered content to a knowledge base a tool can use

Every tool runs on your content. Before any of them helps a person, your content has to be gathered, structured, tagged, and made safe to serve. The stages run in order, and each one produces something you can use on its own.

Where to start

You do not need the whole journey to get value. Take one high-traffic issue, like eviction or debt. Index and tag it, assign its authority tier, chunk it, put a safety layer in front of it, and serve it through one interface. Grow from there.

Step 0

Build the relationships first

The goal: The people who hold the content agree to share it. Most of the useful content lives in other organizations, so the first work is human, not technical.

Agreeing who shares what comes before any tagging. State teams have taken different coordination approaches, from a light touch to full federation, and all of them are valid starting points. The right level depends on how many organizations you are working with and how much trust is already in place. For example, one Texas team keeps the ask deliberately small: give me your URL, your subject matter, and the languages you offer, and I will build the knowledge base and the referral mechanism from that.

Do it in steps
  1. List where content lives and the one person who owns each source.
  2. For each owner, understand their context: their role, their constraints, and what would make sharing straightforward for them.
  3. Pick a coordination level that fits the trust and the number of organizations, from a light touch to full federation.
  4. Make the minimal viable ask. A URL, a subject, and the languages a resource is offered in is enough to start, and a light ask is what gets a cautious partner to say yes.
Tools and assets you can use
  • Content sources map — a one-page spreadsheet with columns for source, owner, context, and first ask.
  • Minimal contribution template — a URL, a subject, and the languages a resource is offered in.
  • Contributor agreement — a short note that names control, credit, and the license.
What the output looks like
Your content sources map
SourceOwnerTheir contextFirst ask
Website CMSComms leadOwns the publishing workflowExport one section
Referral databasePartner orgSmall team, limited timeURL, subject, languages
Advocate know-howSenior staff attorneyAccountable for accuracyA 30-minute interview
Signs you have done this well
  • You can name every source and the person who owns it.
  • You understand each owner's context.
  • At least one partner has said yes to a small first ask.
Stage 1

Index and tag your content

The goal: You know what you have, where it lives, and what it is about. Every item is tagged against the Legal Help Knowledge Standard and carries an authority tier.

Audit your content, decide what is in, and tag it as it comes in. On the gathering method, there is a real choice, and the cohort has a recommendation. The cohort built its index from a content management system export, from Drupal, WordPress, or similar, and recommends that route, because an export gives you the metadata, the revision history, and the internal relationships that a scrape cannot see, and it keeps you in control of exactly what enters the knowledge base. Scraping is a reasonable fallback for public content you do not control, and AI-assisted ingestion helps at large volume.

Do it in steps
  1. Audit your content sources: the website CMS, document management like SharePoint or Google Drive, referral and case-management databases, and expert knowledge in training decks.
  2. Define scope: what is in for phase one, what is authoritative rather than legacy, and what needs legal review before inclusion.
  3. Choose a gathering method. Export from your CMS, map the fields to a standard schema, and normalize the jurisdiction and issue codes as you go.
  4. Apply the taxonomy at ingestion: LIST codes for the legal issue, FIPS codes for jurisdiction, a content-type label, language codes, and an authority tier. Tag against the Legal Help Knowledge Standard rather than inventing your own.
  5. Export to the standard schema, and tag every item with an authority tier, because not all content deserves equal trust.
Tools and assets you can use
  • Legal Help Knowledge Standard — the shared issue, jurisdiction, content-type, and audience vocabularies the rest of the field tags against.
  • CMS export patterns — Views Data Export for Drupal, WP All Export for WordPress.
  • Structured contribution template — for content that is not on a public page, such as referral data and case-acceptance criteria.
  • Digitizer layer, for large volumes — an AI step that tags and structures incoming content, with human review and governance on top.
What the output looks like
The standard schema, for one record
Answering an eviction complaint (California)
Required
titleAnswering an eviction complaint
content typeHow-to guide
jurisdiction (FIPS)US-CA
issue (LIST)Eviction defense
Preferred
languageen, es
audienceSelf-help public
last review date2026-02-10
authority tierTier 1
Generated
unique idlhc-ca-evic-0142
ingestion date2026-03-01
The four authority tiers
TierSourceTrust
Tier 1Expert-authored, taxonomy-taggedHighest
Tier 2AI-outlined, expert-filledHigh
Tier 3Scraped public contentMedium
Tier 4User-contributedLower
Signs you have done this well
  • You have a tagged index of your content and a clear scope document.
  • Every item carries an authority tier.
  • Your tags map to the Legal Help Knowledge Standard, not a private scheme.
Stage 2

Chunk and embed

The goal: Content is turned into AI-usable pieces with safety metadata, embedded into a vector database, with retrieval you have tested.

Split the content, attach safety to each piece, and embed it. How you split depends on the content type. There are three broad strategies: fixed-size chunks of 400 to 500 words with overlap, which work when the source content is well-written; semantic chunking by heading or section, which preserves structure for complex documents; and a hybrid that retrieves many chunks and re-ranks to the best few. The most important lesson in this stage is about safety, because disclaimers in a system prompt are not enough. The stronger pattern is a deterministic set of rules that sits on top of the content and decides how each chunk is displayed.

Do it in steps
  1. Choose a chunking strategy for the content type: fixed-size with overlap, semantic by section, or a re-ranking hybrid.
  2. Add chunk-level safety metadata: warnings, scope, and dependencies.
  3. Create embeddings and populate a vector database.
  4. Wrap the content in deterministic rules that sit on top and decide how each chunk is shown, so a warning travels with every chunk from a page that has one, and some chunks must appear together.
  5. Test retrieval quality on real questions.
The safety framework has five parts
  • Deterministic rules on top of the content, rather than trusting the model to know what is dangerous.
  • Chunk-level metadata tagging each chunk with warnings, scope, and dependencies.
  • Linked warnings so a warning travels with every chunk from a page that has one.
  • Retrieval rules so some chunks must appear together.
  • An evaluation process that tests for harm before going live.
What the output looks like
One chunk, with its safety metadata

"In California, you have 10 court days to respond to an eviction complaint after you are served."

warning Deadline. Missing it can lose the case by default. scope California unlawful detainer only. must show with the step on how to file the response.

People's Law School's Beagle+ works this way: it parses pages into 200 to 600 word chunks with overlap, tags each with source, title, topic, and date, embeds them, and re-runs the pipeline nightly so the index stays current.

Signs you have done this well
  • You have a populated vector database.
  • You have a chunk-level safety metadata schema.
  • Your safety rules are written down, not left to the model.
Stage 3

Store and connect

The goal: Filtering, navigation, and cross-references work, and every tool queries the same content the same way through one interface.

Set up the storage and wire the relationships between records. Storage is a vector database for semantic search plus a metadata store, like PostgreSQL, Airtable, or Sanity, for filtering and facets. You define the relationships that let a tool navigate, such as the issue hierarchy from Housing to Eviction to Eviction Defenses, along with document-to-section and guide-to-form links. The working group converged on an MCP server as the standard interface, so any bot, tool, or partner queries the same content the same way.

Do it in steps
  1. Set up a vector database for semantic search and a metadata store for filtering and facets.
  2. Define parent-child relationships, like Housing to Eviction to Eviction Defenses, and document-to-section and guide-to-form links.
  3. Build cross-references and "see also" connections.
  4. Enable filtering by jurisdiction, issue, content type, and authority tier.
  5. Expose all of it through a single interface, an MCP server, so every tool queries it the same way.
Tools and assets you can use
  • Vector database plus metadata store — PostgreSQL, Airtable, or Sanity for the filtering layer.
  • The issue hierarchy from the Legal Help Knowledge Standard, for the parent-child relationships.
  • An MCP server — the standard interface the working group converged on.
What the output looks like
One interface every tool queries
Vector database

Semantic search over your chunks.

Metadata store

Filter by jurisdiction, issue, type, tier.

MCP server

One interface for every bot and partner.

A parent-child relationship
Housing Eviction Eviction defenses
Signs you have done this well
  • You have a populated vector database and a metadata store with relationships.
  • You can filter by jurisdiction, issue, content type, and authority tier.
  • Every tool reads through one interface.
Stage 4

Test and evaluate

The goal: Quality, accuracy, and safety are proven before launch, against a real test set.

Grade the system against a test set before it reaches a person. Define your evaluation criteria across retrieval accuracy, answer correctness, safety compliance, and citation coverage. Build a test set of representative queries, edge cases like multi-jurisdiction and complex eligibility, and known-tricky scenarios with conflicting guidance. Then run the evaluations and iterate, fixing gaps in content, improving chunking where retrieval fails, and adding guardrails where safety issues show up.

Do it in steps
  1. Define evaluation criteria: retrieval accuracy, answer correctness, safety compliance, and citation coverage.
  2. Build a test set: representative queries, edge cases like multi-jurisdiction and complex eligibility, and scenarios with conflicting guidance.
  3. Run the evaluations with automated metrics, expert spot-checks, and user testing.
  4. Iterate: fix content gaps, improve chunking where retrieval fails, and add guardrails where safety issues show up.
Tools and assets you can use
  • The Evaluation Methodology and the grounding and classification findings from the companion guides.
  • A test set of representative queries and edge cases.
  • Automated metrics plus expert spot-checks, run together.
What the output looks like
An evaluation scorecard
CriterionHow measuredResult
Retrieval accuracyAutomated metricPass
Answer correctnessExpert spot-checkNeeds edit
Safety complianceHarm test setPass
Citation coverageAutomated metricFail · uncited claim

The scorecard tells you exactly what to fix before launch: here, a claim that does not carry its citation.

Signs you have done this well
  • You have an evaluation framework and test results.
  • You have an improvement backlog drawn from the failures.
  • Safety is tested for harm, not assumed.
Stage 5

Deploy and maintain

The goal: It is in production for a real use case, and it stays current, because a knowledge base is never finished. An AI surfaces stale content faster and more confidently than a website ever did.

Put it into production, then keep it alive. Choose initial use cases, like website search, a chatbot, service matching, or advocate tools, and build the interfaces, user-facing and admin, with monitoring dashboards. The longer and harder work is what comes after launch. Every team named maintenance as the hardest part, because stale content is universal, so the knowledge base is a living system, not a delivered project.

Do it in steps
  1. Choose initial use cases: website search, a chatbot, service matching, or advocate tools.
  2. Build the interfaces, user-facing and admin, with monitoring dashboards.
  3. Stand up the maintenance cycle below, and give each part of it an owner, because content starts going stale the day you publish it.
The maintenance cycle never ends
  • Watch for legal change — new cases, statutes, and administrative orders that change what a guide should say.
  • Spot the gaps — the topics and jurisdictions where your content is thin or missing.
  • Review for freshness — flag content past its review date, before an AI surfaces something stale.
  • Translate — carry every update into the other languages you serve, so no language falls behind.
What the output looks like
A cycle that repeats for the life of the knowledge base
Watch for change

Cases, statutes, admin orders.

Spot the gaps

Thin or missing topics.

Review for freshness

Flag stale content.

Translate

Every language you serve.

And around again, continuously. The cycle is the job, not a closing task.

Signs you have done this well
  • It is live for at least one use case, with a monitoring dashboard.
  • Someone owns watching for legal change, and gaps are tracked.
  • Freshness review and translation keep pace, on a standing cadence.
Stage 6

Knowledge graph optional, when ready

The goal: You add a graph only when you need rule-based reasoning over facts. A vector database with good metadata covers search and retrieval, which is what most teams need first.

Add relationships as a graph after stages 1 through 5 are working well. The graph is the last step, not the first. One state is planning a graph on the order of two million nodes, connecting organizations, services, eligibility, and issues, and it is building the simpler layers first.

Do it only if
  1. You need to answer "given these facts, what applies", such as which organization will take a case.
  2. Eligibility rules are genuinely complex, or you want guided exploration rather than search.
Signs you have done this well
  • A real reasoning or navigation use case pulled the graph into being.
  • Stages 1 through 5 were working well before you started it.
What the stages point to

The shared standards and guides underneath

The stages tag against shared vocabularies and lean on shared methods. A team building any of this starts here rather than from scratch.

Stage 1

The Legal Help Knowledge Standard

The shared vocabularies you tag against: LIST codes for issues, FIPS codes for jurisdiction, content types, audience categories, and the authority tiers. Tag against this rather than inventing your own.

Stage 2

The chunk-level safety framework

The deterministic rules that sit on top of the content: chunk-level warnings, linked warnings that travel with the content, retrieval rules, and a harm evaluation before launch.

Stage 4

The Evaluation Methodology

How to build the test set and grade retrieval accuracy, answer correctness, safety compliance, and citation coverage, with the grounding and classification findings from the companion guides.

Stage 1

The shared vocabularies and datasets inventory

The datasets and vocabularies you can build on instead of starting cold, so you reuse the field's work rather than rebuilding it.

Plain words

The terms, in plain language

If a word above sent you here, this is what it means. You do not need the jargon to use the Playbook.

Chunk
A small, self-contained piece of content, like one step or one answer, that a tool can pull on its own without the rest of the document.
Embedding and vector database
Turning text into numbers that capture its meaning, so a tool can find the passage closest to a question. Those numbers live in a vector database.
LIST code
A shared code for a legal issue, from taxonomy.legal, so that "eviction" means the same thing across every state's content.
FIPS code
The standard federal code for a place, a state or a county, so a record's jurisdiction is never ambiguous.
Authority tier
A label for how much to trust an item, from expert-authored content at Tier 1 down to user-contributed content at Tier 4, so a tool can weight its sources.
Legal Help Knowledge Standard
The shared vocabularies the field tags against: issue, jurisdiction, content type, and audience. Tag against this rather than inventing your own.
Chunk-level safety
Safety rules and warnings attached to each chunk, so a warning travels with the content instead of relying on the model to remember it.
MCP server
A standard interface, so any bot, tool, or partner queries the same content the same way.
Grounding
Making a tool answer from your curated content instead of its own memory. It is the single biggest lever on quality.
Digitizer layer
An optional AI step that tags and structures incoming content before it enters the knowledge base, with human review and governance on top.
Next

Your content is ready. Now scope what it can power.

This playbook builds the knowledge base the tools run on. The reason to do it is the tools that content unlocks: the Q&A bot, the issue classifier, the referral router, and more.

Scope the brief-help tools