ConceptIntermediateEval-Driven Specification / Writing a PRD for an AI feature / #17

What does the PRD need to say about logging and observability?

The direct answer
The PRD has to require enough logged with every model decision to explain that one decision later, not just record that a decision happened. That means the actual passage or input that drove the call, the item's metadata, and which model and prompt version made it, attached to every single output. A tag and a confidence score are not enough. If nobody can answer "why did it say that" straight from the log, without re-running the model or re-reading the whole file from scratch, the logging requirement has not actually been met, whatever the dashboard says.
Do this, in order
  1. Require the source passage and item metadata to be logged with every decision, not just the tag.Why: a tag and a timestamp tell you what happened. Only the passage tells you why.
  2. Log which model and prompt version made the call.Why: without it, nobody can tell whether an old call still means the same thing after the system changed.
  3. Set a real floor for log completeness, and alert when it drops.Why: a completeness number that nobody watches can fall for months before anyone notices, the same way the underlying decisions can.
  4. Never let a cost or storage change quietly trim what gets logged.Why: the passage looks like the expensive, skippable part right up until the day somebody needs it.
  5. Test the log before a real challenge does.Why: pull one decision at random and try to explain it cold. If you can't, the gap gets found on a much worse day.
  6. Scale how much gets logged to how much a wrong call would cost.Why: not every tag needs a full audit trail, and treating all of them the same buries the ones that do.

How to answer this, stage by stage

Eight moves. Say what the log has to prove before you list what it has to store, or the requirement reads like a checkbox instead of a decision.

1
Scope it to one tool and one person
Say it like this
"Let's make this real. Say a legal tech company built an AI tool that reads documents during a lawsuit and tags each one privileged, responsive, or not responsive. Ifeoma Uchendu owns the logging spec for it."
Why this works
A logging requirement for "an AI feature" in general is empty. It only means something once you can say whose job depends on trusting it.
2
Say your structure out loud
Say it like this
"I'm going to use LEAD here, because underneath the wording this is a metric question. What's the real signal, and how do you know the log is working before someone forces you to find out?"
Why this works
Naming the method up front tells the interviewer you have a plan, not just an opinion.
3
Reframe what the question is really asking
Say it like this
"This sounds like it's asking whether we log the decision. Every tool logs the decision, a tag and a timestamp. The real question is whether anyone can explain a single one of those tags after the fact, without re-running anything."
Why this works
This is where a good answer stops sounding like a feature list and starts sounding like a decision.
4
Give the one decision
Say it like this
"So here's what goes in the PRD. Every tag gets logged with the actual sentence or passage that drove it, the document's metadata, and which model and prompt version made the call. Not just the tag. Not just a confidence score."
Why this works
This is the E step, and it's the whole answer. A logging line with no reconstruction context is a requirement nobody can actually use.
5
Prove it with a failure
Say it like this
"Here's why that matters. Six months in, a privileged memo got tagged 'not privileged' and went out the door to the other side's lawyers. When they asked why, the log had a tag and a score, nothing else. The team had to hand check twelve thousand documents to find out if it was one mistake or a pattern."
Why this works
A compressed real failure does more work than a paragraph of reasoning. It shows the cost, not just the claim.
6
Say how the loose version gets gamed
Say it like this
"If I just write 'log every classification decision,' a system that logs the tag and a timestamp technically passes. It looks thorough on an audit checklist. It explains nothing. Same problem if I anchor it to the model's own confidence score instead of the actual passage, that number doesn't tell you what the model saw, only how sure it felt."
Why this works
Naming the cheat yourself shows you understand why loose logging requirements fail, not just that they can.
7
Lay out what changes at each level
Say it like this
"Below the floor, where the passage is missing, every tag from that window needs a person to re-check it by hand before it's trusted. Close to the floor, spot-check the gaps. Well above it and holding for months, you can answer a challenge straight from the log, same day, no re-review at all."
Why this works
This is the D step. A logging requirement nobody acts on differently at different levels is just decoration.
8
Close on the accountability line
Say it like this
"If someone ever asks me why the tool got a call wrong, I want an answer ready. Here's the passage it saw. Here's the version that read it. Here's why it made sense at the time. That's the whole point of logging it this way before anyone has to ask."
Why this works
It shows the requirement was built to survive being questioned, not just to ship.
If you only get through two stages Stages 4 and 6 are the answer. Say what the log has to capture, and say how the loose version gets gamed. Everything else here is how you defend that under follow-up.

Let's learn

Every year, during a lawsuit, someone has to read through a mountain of email and memos and work out which ones a judge is never allowed to see, because a lawyer's private advice is written inside them. That job is called discovery review, and it used to move slowly on purpose, because getting it wrong is expensive in a way most mistakes aren't.

Knowledge spark: what does "privileged" mean here? A private talk between a client and their lawyer about getting legal advice. Courts protect it from being used against you. If it leaks out by accident, it can sometimes still be pulled back, but only if the company acted carefully and asked for it back fast.

Before the tool, a team of thirty contract attorneys read a mid-size case's documents by hand, about sixty an hour each. A quarter of a million documents took them close to three weeks and cost the client about 1.4 million dollars in review time.

Now Docket Sense, a classifier built by Casewell AI, tags all quarter of a million documents overnight. Reviewers only have to check the roughly nine thousand it flags as close calls. Three weeks becomes four days.

Here's the turn. A few wrong tags out of a quarter million barely move an accuracy number. That was never the real risk. The real risk is what happens when one specific tag turns out to be wrong on a document that should never have left the building, and somebody has fourteen days to explain why it did.

The model didn't fail because it tagged something wrong. It failed because nobody could say why.

At its worst, that's exactly what happened. A memo forwarded between a company executive and in-house counsel got tagged not privileged and went out to the other side's lawyers in a contract dispute with a company called Bramholt. Someone on Bramholt's team spotted the words "attorney client, please keep confidential" halfway down the page and sent a clawback letter: give it back and prove it was a mistake, or the whole executive's file could lose its privilege too.

Knowledge spark: what's a clawback letter? A formal demand to return something handed over by mistake, here, a document that should have stayed private. The company gets a short deadline to prove it was an accident. Miss that, and a court can decide the secret isn't protected anymore, sometimes for more than just that one document.

Once the letter landed, the team went back and checked something nobody had been watching: how many of Docket Sense's tags actually had enough attached to explain a call, not just to record one.

Log completeness rate, by month
97% 96% 71% 58% 47% 41% Month 1 Month 2 Month 3, storage cut Month 4 Month 5 Month 6, the letter
clears the 90 percent floor
falls under it, never checked at the time
The completeness rate fell under the floor three months before the letter arrived. Nobody was watching it, because the tags themselves kept looking fine.
Two panels in one frame. Left, a document marked logged, not privileged, tag saved, checkbox ticked. Right, a document marked the sentence that mattered, never saved, already gone.
The log said "handled" the whole time this was happening

The number that finally moved was how long it took to answer a challenge like Bramholt's.

Time to fully answer a privilege challenge, before and after
0.5 day
an earlier challenge, full passage on file
9 days
the Bramholt letter, log-light window
Nine days, and 12,400 documents from that one executive's inbox had to be checked by hand, because the log couldn't say why any of them had been tagged the way they were.
The choice I'd take back We decided to log only the tag and a confidence score, to keep storage light and the pipeline fast. That was fine when someone could just re-read the document if a question came up. I'd log the source passage and the item's metadata with every tag instead, before the file ever leaves the building, so nobody's explaining a decision from memory months later.

What I'd leave alone. Documents Docket Sense tags not responsive because they're clearly nothing, calendar invites, out-of-office replies, don't need this much logging. Nobody is ever going to send a clawback letter over a lunch invite, so a tag and a timestamp are enough there.

The lesson. A log that only says what happened isn't a log of why it happened. If it can't answer that on its own, it isn't protecting anyone. It's just proof something ran.

Now here is the same thing as a story

Use this version when you've got the time. Nobody argues with a Tuesday nine days into a deadline.

Ifeoma Uchendu can read a privilege log the way most people skim a grocery list, and she's the one people at Casewell AI call when a tag looks wrong. She wrote Docket Sense's original logging spec four years ago, back when the whole tool was still running on one law firm's test data.

It shipped to Straithorn LLP two summers ago. For most of that first year, review teams loved it. An associate would kick off an overnight run, come in the next morning to a stack of maybe two hundred close calls instead of a quarter million documents, and spend the day on the ones that actually needed a human eye. Partners started saying the tool had given them back a week of every case.

The habit faded in three small steps, none of them looking wrong on its own. First, as the case grew, someone on the platform team switched the logging pipeline to a cheaper storage tier to keep the bill from climbing, and quietly capped how much of each passage got saved. Second, nobody re-checked the completeness number afterward, because nobody had ever been asked to watch it in the first place. Third, reviewers stopped even glancing at "why" a tag came out the way it did, because the tags themselves kept looking fine on their face.

Then, on a Tuesday in the Bramholt matter, an associate on the other side read a produced memo and found the words "attorney client, please keep confidential" sitting in it. She sent a letter. Ifeoma got one question from Straithorn's partner she couldn't answer: "Why did the tool call this one not privileged?"

We didn't just lose one document. We lost the ability to say why, for six months of tags.

It would be easy to say the model got a call wrong, and it did. But that's not really the story, because a single wrong tag out of a quarter million was always going to happen. The real problem was that nobody could tell whether it was one mistake or a pattern, because the one thing that would have answered that, the actual passage the model saw, had never been kept.

So here's the decision I would take back.

Two years earlier, in the meeting where the logging spec got trimmed, someone had asked whether they really needed the whole passage saved with every tag. Storage costs were climbing fast as the case grew, and the confidence score already looked like it was doing the job. Ifeoma remembers agreeing. It seemed like a fair trade at the time.

I would put the passage back. Compressed if it needs to be, but attached to every tag, along with the document's metadata and the model version that made the call.

Here's the replay. Same storage bill, same pressure to cut it, new spec. The passage and the metadata stay attached to every tag instead of getting dropped. When Bramholt's letter arrives, Ifeoma pulls the exact sentence Docket Sense saw, the executive's name, the date, and the model version, straight from the log. She has the real answer back to outside counsel in under four hours. No twelve thousand four hundred documents re-checked by hand. No nine days.

One design makes you re-read the whole case to answer a question. The other makes the log answer it for you.

And the thing I'd tell myself, back in that meeting: I traded away the one thing nobody could rebuild later, to save space on the thing everybody could rebuild anytime.

What LEAD looks like when the metric is "can you explain yourself"

This is a concept question about writing a PRD, but the shape underneath it is a metric question: what's the one number that tells you a log is actually useful, before somebody needs it to be. That's LEAD, not GUARD. GUARD is for who gets treated unfairly. Here the harm is that a decision can't be explained at all, to anyone, fair or not.

L, link. The real thing logging has to protect: whether anyone can explain any single output after the fact, to a partner, a court, or a customer. Not whether the system technically recorded that a decision happened.
E, early signal. Log completeness: the share of decisions logged with the actual passage and item metadata attached, not just a tag and a score, checked on its own before anyone needs it for a specific case.
A, abuse. Write the requirement as "log every decision" and it's satisfied by a tag and a timestamp. Anchor it to the model's own confidence score instead, and that number tells you how sure the model felt, never what it actually saw.
D, decision. Below the floor, every decision in that window needs a human to re-check it before it's trusted. Close to the floor, spot-check the gaps. Well above it and holding for months, answer any single challenge straight from the log, same day, no re-review.
The check that proves a log is real Pull one decision at random from last month and try to explain it using only what's in the log, no re-reading the item, no asking whoever built the model that week. If you can't, the log was never doing its job, whatever the dashboard says.

And if you want to be sure it really works, try it somewhere else

A clinic called Willowmere Family Health uses a similar tool to sort patient portal messages into urgent and routine, so a nurse's queue surfaces the ones that can't wait. Same shape of question. "Log every triage decision" survives an audit the same way "log every classification" did, and explains just as little.

L. Whether a clinician can find out, after a bad outcome, exactly why a message got tagged the way it did.
E. The actual message text, the symptoms it flagged, and which model version triaged it, attached to every urgent-or-routine tag.
A. Log only the tag and a timestamp, and "every message logged" is true of a system that explains nothing. Anchor it to the model's urgency score instead, and that number changes meaning every time the model is retrained.
D. Below the floor, a nurse re-reads every routine tag from that window by hand. Close to it, spot-check the low-confidence ones. Well above it and holding, trust the log to answer any single question, no re-review needed.
A labeled diagram centered on a document icon marked the call, with four labels radiating around it: the source passage, doc metadata, model version, before a challenge lands.
Same idea, a different desk

Swap the trigger and it still runs

  • Storage gets more expensive. Doesn't matter. Storing the passage and metadata still costs less than a nine-day manual re-check ever will.
  • The model gets faster. Doesn't matter either. The log still has to say why, however quickly the tag arrived.
  • The model gets better than planned. Even then, log it. A real audit trail turns "it seems better" into proof, instead of a feeling nobody can check.

Where people run it wrong

  • Logging only the output because it's cheaper to store, quietly trimming the log's usefulness before anyone notices.
  • Treating a confidence score as if it were the reasoning, when it's really just a number the model made up about itself.
  • Building the reconstruction habit only after the first challenge, instead of testing it on a random decision before anyone asks.

How to use it live

Say the reconstruction line first. "Before I say the logging is enough, I want to know if I can explain one random call from it, cold, without rereading anything." That's not stalling. That's the E step, said out loud, and it buys the time to build the real answer instead of guessing at one.

Flashcards (click a card to flip it)

1 · THE FRAMEWORK
Which framework fits this question, and what does it stand for here?
Tap to flip
ANSWER
LEAD. L is the real outcome logging has to protect, E is the early signal that proves it, A is how a loose logging rule gets satisfied by a log that explains nothing, D is what changes at each level of log completeness.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Ifeoma Uchendu, who has owned the logging spec for Casewell AI's document classifier for four years and wrote it herself back when the tool was still a prototype.
3 · THE HABIT
What did the team stop doing because nothing forced them to keep doing it?
Tap to flip
ANSWER
Checking the log completeness rate against anything. It fell from 97 percent to 41 percent over six months, and nobody noticed, because the tags themselves kept looking fine.
4 · THE LOG SPEC
What's the loose sentence at the center of this story, and what should replace it?
Tap to flip
ANSWER
"Log every classification decision" against "log the tag, the source passage, the item's metadata, and the model version, for every decision." One records that something happened. One explains it.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Dropping the source passage from the log to save storage cost, in the same meeting where someone asked whether it was really needed and the confidence score seemed like it was already doing the job.
6 · THE NUMBER
Log completeness held at ______ percent in month one and had fallen to ______ percent by the month the clawback letter arrived.
Tap to flip
ANSWER
97 percent in month one. 41 percent by month six. It had already crossed under the 90 percent floor three months before anyone was forced to notice.
7 · THE REPLAY
Same storage pressure, real logging spec in place, what changes?
Tap to flip
ANSWER
The passage and metadata stay attached to every tag instead of getting dropped. Ifeoma answers the Bramholt letter in under four hours from the log alone, instead of nine days and 12,400 documents re-checked by hand.
8 · THE TRANSFER
Section four runs LEAD on a different product. Which one, and what's its early signal?
Tap to flip
ANSWER
Willowmere Family Health's patient message triage tool. Its early signal is the actual message text, symptoms flagged, and model version attached to every urgent-or-routine tag, not just the tag itself.

Check yourself Score: 0 / 0

True or false
1. True or false: if a tool logs the tag and a confidence score for every decision, that's enough to explain any one of them later.
  • True
  • False
Show hint
Ask what the confidence score actually tells you about what the model saw.
Show answer
False. A confidence score says how sure the model felt, not what it read. Without the source passage and metadata, nobody can rebuild the reasoning behind a single call.
Multiple choice
2. Which of these logging specs would actually survive a real challenge to a decision?
  • A. Log the classification tag for every document.
  • B. Log the tag and the model's confidence score.
  • C. Log the tag, the source passage, the document's metadata, and the model version, for every decision.
  • D. Log whether a human reviewer signed off on the tag.
Show hint
Three of these can be true of a system that still can't say why it made a specific call.
Show answer
C. Only this one lets someone reconstruct the actual reasoning without re-reading the whole file or asking whoever built the model that week.
Fill in the blank
3. Before the drift, a privilege challenge got answered in about ______ day(s). After, the Bramholt letter took about ______ days, and 12,400 documents had to be checked by hand.
Show hint
The numbers sit right under the bar chart in Section 1.
Show answer
0.5 days. 9 days. The gap is the whole cost of losing the source passage: the same question, eighteen times slower to answer.
Short answer
4. Name a place in this same tool's logging where a loose, tag-only line is fine and doesn't need the full passage kept.
Show hint
Look for a tag nobody would ever challenge in the first place.
Show answer
Model answer: "Documents tagged not responsive because they're clearly nothing, like calendar invites or out-of-office replies. Nobody sends a clawback letter over a lunch invite, so a tag and a timestamp are enough there."
Short answer, apply it yourself
5. Pick a product you use yourself. Name one decision it makes with no reconstructable record behind it. What would the fix look like?
Show hint
Look for a message that states an outcome with no evidence attached, like "no matches found."
Show answer
Model answer: "A delivery app that says 'no drivers available' at busy times, with no record of which drivers were nearby or why none got the offer. The fix: log the actual candidate list, each driver's distance, and the outcome for each one, tied to that message, so a support call could explain it instead of repeating the same line."
Multiple choice
6. If Casewell had caught the completeness rate at 70 percent instead of letting it fall to 41 percent before the Bramholt letter arrived, what would most likely have happened to the nine-day response time?
  • A. No change, it would still take nine days.
  • B. Shorter, because most tags in that window would still have their source passage attached.
  • C. Longer, because a partly complete log is worse than none at all.
  • D. It depends only on document count, not on how complete the log is.
Show hint
Think about how many documents would still need a manual re-check at 70 percent complete versus 41 percent complete.
Show answer
B. More tags with the passage attached means fewer documents that need hand re-checking, so the response gets faster the closer completeness stays to the floor.
From U2xAI Academy

From answering questions to owning outcomes.

A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.

  • A live AI agent you actually shipped
  • A launch decision you can defend under pressure
  • An interview-ready portfolio, not more flashcards
Know more