The Assumption Filed as an Answer

Three entries sat under "Answered Questions" while carrying "(working assumption)" and "(confirm in environment)". The open-questions collector only harvests what is filed as open — so they aged forever.

Three entries sat under a heading called Answered Questions.

One of them ended with "(working assumption)". Another ended with "(confirm in environment)".

Nobody was hiding anything. The caveats were right there, in the same sentence, written by the person who knew they belonged there. And they were completely invisible to the system built to stop exactly this from happening.

What Was Filed As Answered

Three questions, all of them the kind that decide test outcomes rather than test wording.

How the tax-exempt flag reaches the billing system. What actually drives "no device shipment required" on a downgrade. Whether the Asset record or the Order Product is the source of truth for a retained device.

Each had an entry. Each entry was written clearly. Two carried an explicit hedge in brackets.

The third is the one that should make you uncomfortable. It describes the mechanism confidently and then notes that the mapping it depends on — which broadband product corresponds to which router model — is still unknown.

Read that again. The answer is stated, and the input it needs to be applied does not exist yet. It is answered and unexecutable at the same time.

You cannot write a test case from it. You cannot predict a result with it. It is filed under Answered, and if you tried to use it tomorrow you would be blocked inside two minutes.

Two States For Three Kinds of Knowledge

The page had two headings: Answered Questions and Open Questions.

Project knowledge does not come in two kinds. It comes in three.

Verified — someone checked it in a system and it held. Assumed — someone reasoned it out from the design and it is probably right. Unknown — nobody knows.

Two containers, three kinds. The middle one has nowhere to live, so it goes wherever it looks least wrong — and an assumption always looks more like an answer than like an open question, because it has content. It has a sentence. You can read it and act on it.

So assumptions migrate upward. Not through carelessness. Through the pull of a form that offers no box for them.

That is the mechanism, and it is worth stating as a rule that applies well beyond one page: any classification with fewer states than the domain will silently promote the middle case to the state that looks most complete.

The Collector Made It Permanent

Migration alone would be recoverable. Somebody re-reading the page would spot the brackets.

The project also had an automatically generated open-questions registry. It scanned the documentation, harvested everything filed under an "Open Questions" heading, and aged each item so that nothing could quietly rot. Anything sitting unresolved for weeks surfaced in a report.

That tool was built precisely to stop assumptions from disappearing.

It harvests by heading. It reads ANSWERED as resolved and moves on. It does not parse the sentence, so it never sees "(working assumption)" or "(confirm in environment)".

Put those two facts together. Every assumption that got promoted into the Answered section became structurally invisible to the tracker designed to catch it. Not deprioritised. Not aged slowly. Absent from the input, which means it can never appear in the output, no matter how long it sits there.

The safety net had a hole shaped exactly like the thing most likely to fall.

Your Ageing Metric Measures Honesty, Not Risk

This is the consequence I would put on a wall.

A question registry ages only what you admit is open. So the number it reports — how many unresolved items, how long they have been unresolved — is not a measurement of how much you do not know. It is a measurement of how much you have declared that you do not know.

Those two quantities move independently. A team that writes down every uncertainty looks worse on the metric than a team that resolves uncertainty by writing a confident sentence and filing it upward. The second team has more risk and a better report.

And the dangerous state was never the unanswered question. An unanswered question is loud. It has a heading, it has an age, it turns up in a report, and somebody eventually chases it. It carries its own alarm.

The assumption filed as an answer carries no alarm at all. It reads as settled, it gets cited by the next person as if it were verified, and the caveat in brackets survives exactly as long as people keep reading the full sentence rather than the heading above it.

What To Change

None of this needs a new tool. It needs one more state and a collector that can see it.

  • Add "Assumed (unverified)" as a first-class heading, level with Answered and Open. Every entry whose basis is reasoning rather than observation lives there, including the ones you are confident about. Confidence is not the criterion — whether somebody watched it happen in a system is.
  • Make the harvester read that heading too, and age it on its own clock. An assumption that has gone three weeks without verification is a more actionable report line than an open question everyone already knows about.
  • Record what would verify each one, in the entry itself. "Check the flag on a completed order in the test environment" turns a permanent caveat into a fifteen-minute task somebody can pick up. A hedge with no verification step attached will still be a hedge at go-live.
  • Move anything that names a missing input straight to Open. If the entry says the mapping is unknown, the question is not answered, whatever the paragraph around it claims. That is the cleanest test available and it takes one read to apply.

The Check I Now Run

Open the decisions page. Search the Answered section for the words "assume", "assumption", "should", "confirm", "TBC" and "unknown".

Whatever that search returns is your real open-questions list — the part of it that no report will ever show you.

Run that search on your own project page. How many of your answers are still wearing brackets?