Expungement Eligibility Screener

What It Does

In Oklahoma, nearly one in four adults (1.2 million people) have a criminal record that affects their ability to find housing, employment, and long-term stability. About 28% are eligible for some form of expungement. But 94% of eligible people never receive it, nationally. The process is too costly and too complex, even with an experienced attorney.

To determine eligibility, an attorney must gather the client's entire criminal history across multiple courts, counties, and agencies. Then they apply a tangle of statutory rules to each charge, accounting for how case sequencing, charge types, fines, fees, and waiting periods interact. Then they draft affidavits and petitions. An error in screening can leave the client worse off than before.

The Expungement Eligibility Screener handles the analysis step. An attorney enters the case details (charges, dispositions, dates, fines/fees status, case types) into a structured web form. The system runs each charge through a Python-based rules engine that models Oklahoma's expungement statutes as a decision flowchart. It returns a per-charge eligibility determination: expungeable, not expungeable, or flagged for attorney review. Each determination comes with an explanation of the reasoning, the relevant statutory provisions, and (when ineligible) concrete next steps: how many years to wait, whether a pardon is necessary, or whether outstanding fines need to be paid first.

Results are exportable as a JSON file. The system stores no session data. Everything runs locally.

How It Works (Architecture)

The core design philosophy: if it can be avoided, don't use AI. Expungement is rules-based. The statutes define clear conditions. The team built the decision logic as deterministic Python code, not as LLM prompts.

The rules engine is a Python script that implements the full Oklahoma expungement flowchart. The team built this flowchart collaboratively with LASO attorneys Ed and Katie over several weeks, mapping the eligibility paths for misdemeanors, felonies, dismissed cases, deferred cases, and arrests without charges. The flowchart accounts for interactions between multiple cases, charge counts, conviction types, waiting periods, and financial obligations.

The UI is a structured input form. It collects case details through closed-ended inputs (dropdowns, checkboxes, short fields) rather than open-ended prompts or document uploads. This reduces ambiguity. The form supports entering multiple cases and charges per client. Once all data is entered, the attorney submits and the rules engine runs all charges at once.

AI is used in exactly one place: charge classification. When an attorney enters a felony charge description, the system uses cosine similarity embeddings against a reference list of Oklahoma statutory provisions, then sends the top 5 matches to a language model for final classification. This is necessary because charge descriptions vary wildly across counties ("driving a m/v under the influence, under violation of..." vs. "driving under the influence"). The AI maps the free-text description to the correct statutory section.

The team added a manual override for the AI classifier. The attorney sees the AI's suggested classification and can select a different statutory section from a dropdown. This was a deliberate human-in-the-loop decision: if the AI misclassifies, the consequences downstream are serious and hard to detect.

What They Tested

The team built a test set of hypothetical cases with known outcomes, then ran them through the system and compared outputs. LASO attorneys tested the prototype heavily, uncovering edge cases that the team then resolved.

Major bugs found during testing: the system initially confused the number of felony charges with the number of felony convictions, which produced incorrect logic. An improper return statement in one function caused the system to exit early and declare cases not expungeable without screening them. Both were caught through attorney testing and fixed.

Failure-state messaging required its own work. When expungement failed, the system could correctly identify that it failed but gave inadequate or inaccurate explanations of why. The team had to decompose failure states into their many possible combinations and write custom explanations for each. This works but creates maintenance debt: the codebase now contains hardcoded messages for each failure path.

The evaluation rubric covers five dimensions: case input quality (logical flow, appropriate input types, all criteria captured), eligibility evaluation accuracy (correct outcomes for misdemeanors and felonies accounting for all charges), decision logic transparency (clear reasoning, statute matching, district identification), completeness of eligibility factors (next steps, waiting periods, fines, referrals), and handling of uncertainty (flagging ambiguous cases rather than giving false certainty).

Design Decisions Worth Noting

Rules-first, AI-minimal. The team used AI only where deterministic matching fails (free-text charge descriptions). Every eligibility determination runs through handwritten Python logic, not through a language model. This makes the system auditable and predictable, at the cost of maintenance effort when statutes change.

No data retention. The system stores nothing between sessions. Attorneys export results as JSON files and store them in their own secure environments, protected by attorney-client privilege.

Attorney-facing only. The team scoped this as an internal tool for attorneys, not a public-facing screener. Clients often can't access their full criminal history, and the consequences of screening errors are too serious for unsupervised use. The attorney remains the decision-maker throughout.

Flagging ambiguity instead of guessing. When multiple charges may be expunged in a sequence that affects eligibility (across counties or filings), the system flags the case and recommends consultation with a senior attorney rather than making a determination.

Structured inputs over document upload. The team considered building a system that scans case documents and extracts information. LASO's attorneys explicitly asked for something more scoped: attorneys enter the data, the system applies the rules. This keeps the data clean and the results predictable.

Risks and Limitations

Hardcoded failure messages. The explanation system for ineligible cases relies on manually written messages for each failure combination. This is brittle and hard to maintain as statutes change.

Charge classification accuracy. The AI classifier for felony charges is the one point where the system could silently misclassify. The manual override mitigates this, but only if the attorney catches the error.

Statutory change management. Oklahoma expungement law changes. The current system requires a developer to update the Python logic. The team recommends building an editable flowchart interface so authorized users (attorneys, admins) can update rules without engineering support.

Single jurisdiction. The rules engine is specific to Oklahoma. Adapting to other states requires rebuilding the decision flowchart for that state's statutes, though the architecture (structured input → rules engine → explained output) is jurisdiction-agnostic.

What's Next

Editable legal rules engine. Convert the hardcoded Python logic into a visual decision flow that attorneys can update as laws change, with version tracking and safeguards against editing errors. This is the highest-leverage next step for cross-jurisdiction scalability.

Document generation. Extend the system from eligibility determination into petition and affidavit drafting, using the structured case data already collected. The pipeline would become: intake → eligibility → drafting → filing.

Public-facing tier. Build a simplified eligibility guidance interface for individuals who can't access legal representation, alongside the full attorney-facing version. Multilingual support (Spanish priority).

PDF export. Replace JSON export with formatted PDF reports.

Why It Matters for the Field

This project takes a rules-first principle applied to a legal help task. Expungement eligibility is statutory, not discretionary. The team built the entire decision engine as deterministic code and used AI only for the one sub-task where deterministic matching breaks down (mapping free-text charge descriptions to statutory sections). The result is a system that is auditable, explainable, and predictable in a domain where errors have serious consequences.

The editable flowchart concept in the team's roadmap points toward a replicable pattern for any jurisdiction-specific, rules-based legal determination: encode the rules as a maintainable decision graph, let attorneys update it as law changes, and keep AI out of the core logic. Other states have their own expungement statutes, and organizations like Clean Slate initiatives across the country face the same screening bottleneck.

The charge classification sub-problem (mapping inconsistent free-text descriptions to canonical statutory categories) appears across many legal tech contexts: court records, intake forms, case management systems. The cosine-similarity-plus-LLM approach with manual override is a pattern worth documenting independently.