RecordsTracker: OpenAI Build Week 2026

Inspiration

A public record can be public and still be practically invisible.

A child may be living in a licensed facility where questions about care or treatment have been raised, while a public-interest attorney is trying to piece together what was reported, how the state responded, what it found, and what may require closer examination. That work is difficult when the information is scattered across search pages, facility listings, and reports that must be opened one at a time.

Before an attorney can investigate conditions, prepare a case, or advocate for change, someone has to reconstruct the record. For public-interest legal teams with limited time and resources, that work can consume hours that should be spent serving children and youth.

RecordsTracker gives them a single place to start investigating a facility's complaint history.

It began with a much smaller idea.

The project started in June 2026 with a simple question from a public-interest attorney:

“Would it be possible to build a scraper with AI?”

I decided to find out.

I was not a software developer, and I had never used Codex. I knew how to ask what problem the attorney was trying to solve, what the records could support, and what the tool must never claim. I had to learn how to turn those questions into clear instructions that Codex could implement.

My first goal was modest: retrieve selected public complaint reports, preserve the originals, pull out the dates, findings, and facility details that attorneys repeatedly had to reconstruct, and organize them.

Then I met directly with an attorney who did this work.

That conversation changed the project. He described the time required to investigate conditions in facilities, trace how complaints were handled, and find records that might matter to an individual child, a broader lawsuit, or an effort to change policy. He also described the gap between public-interest organizations and large private firms that can afford extensive research systems.

What began as “scrape it and put it in a file” became a larger question:

What would it look like to build an actual platform for the people doing this work?

Every hour spent reopening reports and reconstructing timelines is an hour not spent listening to a young person, preparing a case, investigating conditions, challenging a harmful practice, or developing the record needed for reform.

RecordsTracker cannot perform that legal work. It can reduce repetitive reconstruction and help attorneys reach the point where their judgment matters.

What it does

RecordsTracker is built around a simple path:

Find. Understand. Verify. Decide. Act.

An attorney can find a facility by its name, public Facility Number, location, facility type, or licensing status. As the attorney moves from search results to complaints and original reports, the facility name and public number stay together, even when several facilities have similar names.

The attorney can then understand the complaints currently available in RecordsTracker. Complaint dates, official findings, repeated subjects, and links to the original reports appear together. When comparison is useful, the attorney can look across complaints or facilities to see whether dates, findings, or repeated concerns warrant another report or additional records.

From there, the attorney can open a complaint and verify what the report says. For the first investigation activity date, the attorney can check the value against the specific sentence that supports it and open the original public report instead of simply taking the application at its word. RecordsTracker does not claim that every fact has this level of support.

Current licensing information does not overwrite what an older complaint recorded at the time. A later name, address, operator, or status cannot silently replace the historical context of the earlier report.

RecordsTracker also keeps the attorney's notes and review status separate from the public record. Personal observations can help organize the work, but they cannot change what the report said.

That same care matters when information is missing from the page. The attorney needs to know whether the public report never included it or whether RecordsTracker failed to carry it forward. A blank field should not create a false impression about the record, and a missing value does not prove that an event did not occur.

After reviewing the records and their limits, the attorney decides what deserves further investigation. The next step might be opening another complaint, gathering more records, examining a possible pattern, investigating a condition, preparing material for a case, or deciding whether the records support litigation or policy advocacy.

The product is not the case. It helps the attorney bring together complaint reports, dates, and findings that may matter to a case. An allegation is not a finding, and a record that warrants attention is not proof of wrongdoing. RecordsTracker does not decide whether a child was harmed, whether a facility violated the law, or whether legal action is justified.

Nothing RecordsTracker displays should become more authoritative than the public record it came from.

The attorney opens the report, checks the facts, and determines what the records mean.

How I built it

I never wanted an attorney to depend on a chatbot's interpretation of a public report. I used AI behind the scenes to help me build a tool for researching facility complaints and licensing records while keeping interpretation and legal action in human hands.

I used ChatGPT to question my assumptions, work through product choices, and turn what I learned from attorneys into clear direction. Codex turned that direction into working software, tested it, surfaced problems, and implemented corrections for me to review. Figma let me compare page layouts and review flows before I approved them for implementation.

Some early pages technically worked but were crowded, confusing, or organized around the software rather than the attorney's task. Seeing those pages clearly helped me decide what an attorney needed at the moment of review and what could move into help or administrative pages. It also taught me that passing tests was not proof that a page was understandable.

I did not outsource accountability.

I still had to decide what RecordsTracker should do, what it must never claim, whether a design served the attorney's task, and whether I was willing to put the result in front of an attorney.

AI accelerated the work. It did not decide what the records meant or what legal action should follow.

Challenges I encountered

The hardest part was preserving what the public reports actually said when the reports themselves were inconsistent. Labels changed, values wrapped across lines, older reports followed different patterns, and fields could appear without a value. If RecordsTracker misreads those variations, it could change the report's meaning.

As the collection grew, methods that worked with a small set of reports became slow or incomplete. I had to change how RecordsTracker loaded larger sets of complaints and how attorneys moved through them without losing their place.

Even after the application was accurate and fast enough, a page could still fail its user. It could be too dense, too vague, or too focused on the software to help an attorney decide what to do. Fixing that required looking at the page as an attorney would, not as the person who built it.

What I accomplished

Before Build Week, RecordsTracker could retrieve and organize selected public reports. During Build Week, I turned that foundation into a path an attorney could actually follow, from finding a facility and understanding the complaints currently available to comparing related records, opening the original report, and checking an important date against the passage that supports it.

I also corrected details that can quietly undermine legal research. Facility Numbers that begin with zero stay intact, and current licensing information remains separate from what an older complaint recorded. Those choices help keep the right records attached to the right facility and preserve the history the attorney is trying to understand.

RecordsTracker now lets a public-interest attorney begin investigating a facility without first manually rebuilding its complaint history.

What I learned

I learned that a person does not need to become a conventional programmer before building meaningful software with AI.

But building good software still requires judgment.

The project changed when I listened to an attorney and understood that the real problem was not downloading reports. It was helping someone find the right record, understand it, and know what question to ask next.

I kept returning to four questions:

  1. What did the public record actually provide?
  2. Where did the value on the page come from?
  3. What happened when information was incomplete, unavailable, or conflicting?
  4. What should the attorney examine next?

AI let me do work that would normally require a larger technical team. It could not assume responsibility for those answers.

What's next for RecordsTracker

I want to carry that same care into what comes next by improving how California attorneys find, compare, and review facility complaints, while helping more public-interest attorneys and advocates spend less time rebuilding records and more time serving children and youth.

Any expansion must proceed carefully, one jurisdiction at a time. Each place has different records, laws, terminology, and limits, and RecordsTracker should respect those differences rather than pretending they are interchangeable.

The project began with one attorney asking whether AI could scrape a difficult website. Build Week showed me that a non-developer can use OpenAI tools to give public-interest advocates capabilities that would normally require a much larger technical team, without replacing the people whose judgment the work depends on.

RecordsTracker does not replace legal judgment.

It helps attorneys and advocates reach the point where judgment can do the most good.

Built With

Share this project:

Updates