How Investigators Read Public Records Without Getting Burned by Bad Data

The Problem Nobody Talks About

Public records get a lot of credit they haven't earned. The phrase itself carries a kind of authority — official, verified, documented. But anyone who has spent real time running records knows that the data quality across sources ranges from excellent to completely fabricated, and most of it lands somewhere in between.

Aggregator databases are the most common tool investigators reach for first. They're fast, they're searchable, and they surface a lot of data at once. They are also built by pulling from other compiled sources, which were themselves built from still other compiled sources, some of which date back to the 1990s and were never updated. An address that appears in four different databases isn't confirmed four times. It might just be wrong four times, copied from the same original bad record.

The speed problem makes this worse. When a database returns results in under a second, it feels authoritative. Investigators under time pressure take that feeling and run with it. Cases get built on addresses where nobody has lived for eight years, phone numbers that have been reassigned twice, and identity records that merged two people with the same name into one profile because they shared a zip code in 2014.

This is not a reason to avoid public records. It is a reason to know what you're looking at before you put it in a report.

Primary vs. Compiled Sources

The first distinction that matters is between primary records and compiled records. A primary record comes directly from the entity that created it. A county assessor's property database, a state court's online filing system, a secretary of state business registry — these are primary. The data comes from whoever submitted it, and while that data can still contain errors, at least you know where it originated and when it was last touched.

Compiled sources are everything else. They aggregate from primaries, from marketing lists, from voter rolls, from utility records, from other aggregators. Each layer of compilation introduces another opportunity for data to get stale, merged, or misattributed. When you're looking at an aggregator result and you see an address, you are not seeing a primary record. You are seeing a copy of a copy of something that may have been accurate at some point.

This matters in practice. If you find an address in an aggregator and you need that address to hold up, you go find the primary source. If it's a property address, check the county assessor. If it's a business address, check the state registry. If it's a court address, pull the actual case filing. If the primary source confirms it, you have something. If it doesn't, or if you can't find a primary source that corroborates it, you document it as unverified and you keep working.

The OSINT Grid is built around this distinction. Its 4,577 source entries are organized by state and record type specifically so investigators can get to primary records without bouncing through aggregator layers first. County clerk databases, state court portals, property appraiser systems — the sources that actually have standing. That's the whole point of building it.

How Records Get Wrong

Understanding why data goes bad makes it easier to spot when it has. A few patterns show up constantly in public records research.

Name merges. Aggregators use name and address combinations to link records to individuals. When two people with the same name live in the same geographic area, records get crossed. This is especially common with common surnames and with families where parents and children share names. You can end up with a profile that shows a 35-year-old with a 1947 birth year because the system pulled the wrong generation's records.

Stale addresses. People move. Records don't always follow. An address tied to a subject might be the last known address from a utility account that closed five years ago, carried forward through every data sale since. Some investigative databases explicitly show data source dates; many don't. When there's no date attached to an address, you have to treat it as potentially outdated.

Reassigned phone numbers. The FCC allows phone numbers to be reassigned after a period of inactivity. A number that was genuinely tied to your subject two years ago may now belong to a completely different person. Running a number through a carrier lookup will tell you the current status, but it won't tell you who had it before. Phone numbers from old records need to be verified against current carrier data before they mean anything.

AKA list inflation. Aggregators generate AKA lists by pulling name variations, maiden names, and sometimes outright data errors. A subject whose name appears with a typo in one record will have that typo in their AKA list forever. Don't assume every name on an AKA list is a real alias without confirming it against a primary source that shows the variation was actually used.

Relative and associate contamination. Many aggregators also show "relatives" and "associates" generated from address history. If your subject once lived at an address shared with other people, those people may appear in the relatives section even if they have no actual relationship. This creates false connection maps that look like investigative leads but aren't.

What Verification Actually Looks Like

Verification is not just running the same search twice. It means finding at least one independent source that confirms the specific claim you're trying to support, and that source should ideally be a primary record or a source that traces back to a primary record.

For addresses, the county property appraiser or assessor database is the most reliable option if the subject is listed as a property owner. If they're a renter, that's harder to confirm through public records because lease agreements aren't public in most states. In those cases, you're looking for other corroborating signals: utility accounts, voter registration, business registrations, professional licenses. Each of those goes to a different database and is independent from the aggregator that surfaced the address initially.

For court records, always go to the primary court record system rather than third-party case search tools when accuracy matters. Third-party tools that index court records can lag on updates, miss recent filings, or misattribute cases with similar names. Pulling directly from the state court's e-filing portal or the county clerk's system costs nothing in most states and gives you the actual filing.

For business records, every state secretary of state office maintains a business entity database. These are searchable by entity name, registered agent, and in some states by officer name. They show formation date, registered address, current status, and annual report history. If a business name comes up in your research, this is where you verify it is or was real, who controlled it, and what address it operated from on record.

The Report Composer and Note Organizer make it straightforward to log each claim alongside its source, document the verification step separately, and flag anything that sits on a single unverified source. That structure protects the final report. When someone asks where an address came from, the answer should be a specific primary record with a date, not "it was in the database."

When to Trust an Aggregator Result

This isn't all-or-nothing. Aggregator results are genuinely useful as starting points. They surface a volume of data quickly that would take hours to assemble from individual primaries, and they often point you toward records you would not have known to look for.

The question is not whether to use them. The question is what kind of weight to give a result that exists only in an aggregator. The answer is: low weight, labeled clearly. Use the aggregator result to direct your search. Use the primary source to build your case.

Aggregator results are worth more confidence when they show a consistent pattern across multiple data points. An address that appears alongside consistent phone numbers, consistent associated names, and a consistent timeline is worth more than a lone address hit with no supporting context. Pattern consistency doesn't equal verification, but it does tell you the record is probably not a merge artifact.

Results also get more weight when the data is recent. Some aggregators show data source dates per record. When they do, pay attention to them. A 2025 address hit is more useful than a 2017 one, though neither is confirmed without a primary source to back it.

Documenting the Data Quality Problem in Reports

The final step that separates a competent investigator from a good one is how they document uncertainty. Public records research does not always produce clean answers. Addresses can be current or stale. Phone numbers can be active or reassigned. Names on AKA lists can be confirmed aliases or data errors. A report that presents all of this as equally verified is not an honest report.

Every significant claim in a final report should be tagged with its source and its confidence level. "Subject's address confirmed via county property appraiser record dated April 2026" is a different thing from "Address appears in database search result, source date unknown, no primary record located." Both might appear in the same report. The distinction is what keeps the work defensible.

The Report Composer is built to handle this. You can separate confirmed findings from working leads, cite sources individually, and add notes about data quality concerns directly into the documentation. When the report goes to someone who has to act on it, they know exactly what you verified and what still needs work.

This also protects you. Investigators who get burned by bad public records data are usually the ones who presented it as fact without documenting how they evaluated it. The record itself might be wrong. Your evaluation of it does not have to be.

Working with the OSINT Grid for Primary Records

If you do public records research regularly, the OSINT Grid is worth bookmarking not as a one-time tool but as a reference you reach for before an aggregator, not after. The Grid covers all 50 states, Washington D.C., and federal databases. Sources are filtered by state and by record type, so if you need a Florida property record, a Texas court filing, or a Montana business registration, you get the actual government portal rather than a third-party index of it.

Aggregators have their place. But once you've identified what you're looking for, going to the source directly eliminates one entire layer of potential error. For records that have to hold up under scrutiny, that matters.

FAQ

How reliable are public records for investigations?

It depends entirely on the source. Primary records from government databases are more reliable than compiled aggregator data, though both can contain errors. Every investigator should treat records as starting points that require verification, not as confirmed facts straight out of a search result.

What is the biggest mistake investigators make with public records?

Treating speed as accuracy. A database that returns results in one second did not verify those results in one second. It retrieved them. Those are different things.

How do you verify a public records result?

Find an independent primary source that confirms the specific detail you're relying on. County assessor, state court system, secretary of state business registry. If the primary source confirms it, document the source and date. If it doesn't, document that the result is unverified and note why.

What are compiled sources in public records research?

Databases built by aggregating from other records rather than from the original government or institutional source. They're fast and useful for discovery but should never be treated as a substitute for the primary record when accuracy matters.