How We Keep Generated Reports From Inventing Facts

A parent going through a custody case can accumulate a year of material before they ever sit across from an attorney. Text-message exports, photos with timestamps, a log of missed exchanges, and a paragraph typed into a phone at 11pm after a hard handoff. Daylight, our documentation tool for family-law matters, takes that pile and produces something a person can actually use: a clean, chronological account of what happened.

That last step is where the real work lives. Pulling a single quote out of a single document is mechanical. Reading forty scattered records and writing the paragraph that explains what they add up to is a different kind of task. The software has to decide what is relevant, put events in order, and describe a pattern in plain language. That is composition, and composition involves judgment.

Composition is also where things go wrong in the way that matters most.

The failure that keeps you up at night

A typo is recoverable. The failure mode that actually worries us is a sentence that reads perfectly and refers to something that never happened. An exchange on a date that was never logged. A photo described as showing one thing when it shows another. An exhibit number that points at nothing.

This is the well-documented weakness of every system that generates language from a body of data. The output is fluent and confident whether or not it is true, and a reader has no built-in way to tell a grounded sentence from an invented one. Both arrive in the same calm prose.

In our world the cost of that is not abstract. A narrative that asserts an event the records do not support is worse than no narrative at all, because someone might act on it.

Why a human reviewer is not enough on its own

We do have one structural protection. Nothing Daylight produces goes anywhere by itself. The parent reviews it, and in the matters that count, an attorney reviews it after that. The software drafts. People decide.

That is the right design, and it helps. It only works, though, if review is genuinely possible. Hand a busy professional a polished three-page account and ask them to certify that every claim is supported, and you have handed them an impossible job unless you also give them a fast way to check each one. Review without a way to verify is just a second person trusting the same unverified text.

So the question we set out to answer was narrow and practical. When the software writes a sentence, how does a reader confirm in seconds that it came from something real?

Give every fact an address

The answer turned out to be unglamorous, which is usually a good sign. Every piece of information that enters the system gets its own identifier the moment it is created. A logged event, an uploaded photo, a note, a message thread: each is a record with a stable ID. Engineers will find this routine, and the exact format of the identifier does not matter. What matters is that one exists, and that nothing can be referred to without it.

The rule we enforce on generation follows from that.

Two things follow, and both matter more than they look.

First, the citations are checkable by anyone, including the software itself. If the system writes a sentence and attaches an identifier that was never issued, that is caught at once, before the report ever reaches a person. A fabricated fact cannot survive, because it has to be hung on a real identifier and no real identifier exists for something that did not happen.

Second, the reviewer's job becomes finite. A lawyer reading the account does not have to hold the entire case in their head and audit the prose against memory. They follow a claim to its source, look at the underlying record, and confirm that the sentence is a fair reading of it. The work shrinks from "is any of this invented?" to "does this specific line match this specific record?" That second question is one a person can answer quickly, and answer again and again without fatigue.

What this actually buys you

Inline, traceable citation turns "trust me" into "check it."

The pattern is not specific to family law, and it is not really about any one product. Any time you ask software to read a body of source material and write something new on top of it, you reach the same fork. You can ship fluent output that a reader has to take on faith, or you can ship output where every claim carries its receipt. The second is harder to build and more constraining to work within. It is also the only version a serious organization can put its name on.

Fluency was the easy part. Generating smooth, confident prose is close to free now. The work that remains is making that fluency accountable, so that the convenience of generated text does not quietly cost you the ability to trust it. The mechanism we landed on is old-fashioned to the point of being boring: cite your sources, and make each citation something a machine and a person can both verify. The fact that the source material is read and summarized by software does not lower that obligation. It raises it.

A report you cannot check is a liability dressed up as a convenience. A report where every line points back to a real record is a draft a professional can stand behind, because they can see exactly what it is standing on.