The question telemetry cannot answer

Ask your telemetry how many times charge() failed last Tuesday between 2 and 3 p.m., and it will answer instantly, precisely, and without complaint. Nine times. It'll even tell you the error codes, the retry pattern, the exact millisecond each one happened.

Ask your telemetry what that hour actually cost you, and it will say nothing, because it cannot. Not "doesn't know yet." Cannot, structurally, ever — not because the instrumentation is immature, but because the thing you're asking about was never a fact the system could observe in the first place.

The difference between what happened and what it meant

This isn't a limitation anyone's going to engineer away with better observability. Nine failed charges is an event. What nine failed charges cost is a judgment — how many of those nine customers quietly gave up and never came back, whether this particular hour landed during a promotional push that made the damage ten times worse than an ordinary Tuesday, whether your support team is about to eat six angry tickets about it or zero because the retry actually saved most of them silently. None of that is sitting in a log line. All of it lives in a specific human's head — usually several different humans, each holding a different fragment — built from having watched this system, this customer base, this business, over time.

There's a name for this distinction, and it's older than software. Michael Polanyi, writing in 1966, put it in a single sentence that has outlived every technology it predates: we can know more than we can tell. His argument, developed across The Tacit Dimension, was that a great deal of real knowledge — a face recognized instantly out of a thousand others, a skilled diagnosis made from experience — resists being fully written down, not because nobody's tried hard enough, but because that's what the knowledge structurally is: embodied, contextual, and only partly reducible to statements a system could log.

Why "what does it cost you" is the right shape of question

Ikujiro Nonaka and Hirotaka Takeuchi picked up Polanyi's distinction and turned it into something closer to an organizational design principle, in their account of how companies actually generate new knowledge. Their core move — the one worth stealing directly for a standup — is that tacit knowledge doesn't get extracted by asking someone to write it down cold. It gets surfaced through dialogue: a specific, well-aimed question, asked of a specific person, that gives their tacit judgment somewhere concrete to attach to. Not "tell me everything you know about the checkout flow" — nobody can answer that, the same way nobody can write an instruction manual for recognizing a face. But "what does it cost us when charge() is down for an hour" — that's a question shaped correctly. It's narrow enough to answer, concrete enough to attach a real number or a real story to, and it asks for exactly the thing no dashboard was ever going to produce.

Telemetry is authoritative about what happened. It has no opinion, and can have no opinion, about what happened mattering. Asking it to answer that question is like asking a thermometer whether it's a nice day.

The asymmetry this creates for standup questions

Here's the practical split, and it's the flip side of the argument this series made about never asking the system what it already knows. That earlier post was about not wasting the room's time on lookups. This one is about the other half: making absolutely sure the room's time gets spent on the thing only a human in it can answer. Put the two together and you get a genuinely MECE split of the whole question space — machine-answerable facts on one side, human-answerable meaning on the other, with nothing that belongs to both and nothing left uncovered.

"How many times did charge() fail" belongs entirely to the machine side. "What did that cost us" belongs entirely to the human side, and it will keep belonging there no matter how sophisticated the observability stack gets, because cost-in-the-business-sense was never a property of the function call. It's a property of the business, priced by someone who understands the business, and that understanding is exactly the kind of thing Polanyi spent a whole book arguing cannot be fully extracted, only invited.

What this looks like asked badly, and asked well

Asked badly: "does anyone have context on the billing situation?" — an open floor, which per the last part of this series will lose to whatever everyone already agrees on, and which nobody can answer well because it isn't actually a question, it's an invitation to guess what you're looking for.

Asked well, and asked of a specific person who's actually touched the system: "when charge() went down for that hour last month, what did it actually cost us — refunds, support load, anyone we lost for good?" That question has a subject. It has a person who's positioned to answer it. And it asks for something that will never show up in a log line no matter how much telemetry gets added, because the number it's asking for was never a technical fact to begin with.

This is precisely the shape of question a repo-context ledger should be built to ask, and it's worth being honest about the discipline this requires: ask it rarely, ask it of the right person, and never ask it about something the system could have told you for free — that's the MECE line from the last post, applied to the other side. Every question that could have been a dashboard lookup and gets asked as if it needed a human is a question stolen from the one slot in the meeting where a human's judgment was actually irreplaceable.

The record that outlives the moment

One last piece, because a tacit answer, once actually spoken, becomes a strange hybrid: half fact, half judgment, entirely worth keeping. When someone answers "what does an hour of charge() downtime cost us" with an actual number and a story, that answer should get written down, attributed, and dated — not folded silently into a dashboard as if it had always been a metric, and not lost the moment the meeting ends, either. It's tacit knowledge that agreed to become explicit, once, for one question, from one person who was positioned to know. Anyone can learn to ask this question well. Nobody can learn to skip asking it and get the answer anyway — which is the entire point of this post, and, not for nothing, the entire reason a standup still needs humans in the room at all.