JusticeQueue

JusticeQueue helps legal aid teams focus on the right case first, not just the next case in line.

Comment

JusticeQueue

Helping legal aid teams focus on the right case first—before families fall through the cracks.

Inspiration

This project started with a simple problem.

Legal aid organizations are overwhelmed. There are more people asking for help than there are attorneys available to review cases.

Most intake queues are reviewed in the order they arrive. That sounds fair, but it can create a bad outcome. A family facing eviction in two days might sit behind dozens of less urgent cases simply because they submitted their intake form later.

I wanted to see if I could help legal aid teams identify the right case first.

Not the next case.

The right one.

What It Does

JusticeQueue helps legal aid organizations prioritize incoming cases.

When a new case comes in, the system generates an initial priority score. Then it looks for similar historical legal outcomes and uses that context to reassess the recommendation.

The goal isn't to replace attorneys.

The goal is to help them spend their limited time where it matters most.

Every recommendation still goes through a human review workflow.

How I Built It

I built JusticeQueue with Gemini, MongoDB Atlas, Atlas Vector Search, a custom MongoDB MCP Server, Cloud Run, Next.js, and Vercel.

The workflow is pretty straightforward.

A case comes in.

Gemini analyzes it and generates a baseline priority score.

The system then uses MongoDB Atlas Vector Search to find similar historical outcomes.

That context is fed back into the evaluation process before generating the final recommendation.

One thing I cared about from the beginning was transparency.

I didn't want a black box.

So I built the system to store both the original score and the final score after historical outcomes were considered.

That let me measure whether the additional context actually changed anything.

What Makes It Different

A lot of projects use historical context.

I wanted to know whether it actually mattered.

So instead of just generating a final score, JusticeQueue tracks:

  • Score without historical outcomes
  • Final score after historical outcomes

That gave me a way to measure impact directly.

Results

Across 60 evaluated cases:

  • 32 cases improved after historical outcomes were considered
  • 53% improvement rate
  • Average score increase of 6 points
  • 4 cases moved into a higher-priority tier

One eviction case went from:

83 → 98

after similar historical outcomes were retrieved.

That became my favorite example because it clearly shows what the system is trying to do.

The recommendation changed because of evidence from similar past situations.

How It Works

New Case
    ↓
Gemini Analysis
    ↓
Baseline Priority Score
    ↓
MongoDB MCP Server
    ↓
Atlas Vector Search
    ↓
Historical Outcomes
    ↓
Retrieval-Informed Reassessment
    ↓
Final Priority Recommendation

Why MongoDB Matters

Many applications use retrieval.

JusticeQueue measures its impact.

For every case, the system stores:

  • score_without_retrieval
  • priority_score

This makes it possible to quantify exactly how much historical context changed the recommendation.

Rather than simply claiming retrieval improves outcomes, I can measure it directly.

MongoDB Atlas Vector Search is responsible for retrieving the historical outcomes that inform the final prioritization decision.

Across the evaluation set, those retrieved outcomes improved recommendations in 53% of cases.

Challenges

Most of the hard work wasn't building the interface.

It was getting the retrieval pipeline working reliably.

I spent a lot of time debugging:

  • MongoDB authentication
  • MCP connectivity
  • Atlas Vector Search configuration
  • Deployment issues
  • Retrieval validation

At one point I had embeddings in the database and a healthy Atlas cluster, but searches were still returning zero results.

Tracking that down took longer than I'd like to admit.

I ended up building health checks, diagnostics, validation routes, and retrieval telemetry just to understand what was happening.

It was frustrating, but it made the system much stronger.

What I Learned

The biggest lesson was that retrieval is easy to talk about and much harder to measure.

It's easy to say historical context improves recommendations.

It's harder to prove it.

Building the baseline-versus-final comparison ended up being one of the most valuable parts of the project because it forced me to measure whether the additional context was actually helping.

I also learned that people trust recommendations more when they can see the evidence behind them.

Showing the historical outcomes mattered just as much as generating the score.

What's Next

There is still a lot I'd like to do.

I'd like to expand the historical corpus, support more legal aid categories, and integrate with existing legal aid workflows.

But even in its current form, JusticeQueue answers a question I cared about from day one:

Can historical outcomes help legal aid teams identify urgent cases earlier?

Most systems ask you to trust retrieval.

JusticeQueue measures it

Built With

Share this project:

Updates