The Unanswered Question as a Knowledge Node

The most interesting objects in a knowledge system are not the answers. They are the questions that have not been answered yet. An unanswered question has shape. It has dependencies. It has a decay rate. It is a first-class thing with properties you can measure, and almost no knowledge system I have ever seen treats it that way.

This is a piece about what happens when you start treating open loops as data instead of absence.

The default frame is wrong

When most people think about knowledge management, they think about capturing and organizing things that are already known. You take notes. You write SOPs. You build databases. You tag things. You search across them. The mental model is: knowledge is stuff you have, knowledge management is where you put the stuff so you can find it later.

That model is half the picture. The other half — the half that runs your real life — is the set of things you do not yet know but are in the process of finding out. The email you sent last Tuesday asking a vendor for a quote. The Slack message from a client where you said “let me get back to you on that.” The decision you deferred at the top of your last planning session because you did not have enough information. The question you asked Claude that surfaced a gap in your own thinking that you never went back to close.

These are not absences. They are live objects with state. They exist. They take up cognitive space. They decay in specific ways. And almost no knowledge system captures them because the default frame assumes knowledge = resolved things.

The properties of an open loop

Let me name the properties, because if these are first-class objects, they should have a schema.

Shape. What kind of answer would close this loop? A yes or no? A decision between three options? A number? A written explanation? Each shape implies a different cost to resolve and a different tolerance for delay. A yes/no can be answered in thirty seconds. A “write me a 1500-word strategy doc” takes a week.

Dependencies. What other things cannot move until this loop closes? If the answer is “nothing, it is a curiosity question I asked on a whim,” the loop has zero downstream blockers and can sit forever. If the answer is “I cannot publish the Borro Q2 content plan until I know whether the Palm Beach loan product is launching,” the loop is blocking real downstream work and should be surfaced as a priority.

Decay rate. Most unanswered questions get less valuable the longer they stay open. A “should we launch this product in Q2” question becomes irrelevant the day Q2 ends. A “what is the right SEO strategy for mentions of AI Overviews” question stays fresh for about six weeks before the landscape shifts. A “what is the right way to think about tacit knowledge extraction” question does not decay at all — it is evergreen.

Owner. Whose question is this? Who would recognize the answer when they saw it? This is the hardest property to track because in solo-operator work the owner is almost always you, but the person who can answer is often someone else entirely.

Visibility. Does the other party know you are waiting on them? There is a huge difference between a question you have explicitly asked and a question that is implied by context but never verbalized. The second kind decays faster because nobody is working on it.

Why the default tools miss this

Email has a “follow up” flag that is almost never used. Slack has “remind me about this message” which captures intent but not shape or dependencies. Task managers convert open loops into tasks, which forces them into a standardized structure (“todo item, due date, assignee”) that destroys most of the useful properties above. A curiosity question does not belong on a to-do list. A decision that is waiting on a data pull does not belong on a to-do list either. They are different objects with different lifecycles and the to-do list flattens them both.

The result is that most solo operators carry their open loops in working memory, and working memory has a known capacity limit of roughly seven items. Anything beyond seven is either forgotten or offloaded into a half-functional external system that does not capture enough of the object to be useful. You end up with thirty open loops and a system that only surfaces the ones you happened to remember to write down.

What it looks like to treat them as first-class

Imagine a table in BigQuery called open_loops. Each row is one unanswered question. The fields are the ones above: shape, dependencies, decay rate, owner, visibility. Plus the basics — when it was opened, last activity, estimated cost to resolve.

Now imagine Claude runs a query against that table at the start of every working session. It surfaces the three loops that are highest-priority right now, based on (a) downstream blockers, (b) decay rate multiplied by time since opened, and (c) cost to resolve. It presents them at the top of the chat: “Three things you might want to close before starting anything new: Pinto is waiting on a decision about task scope, the Borro Q2 plan is blocked on your Palm Beach launch decision, and you asked yourself a question last Friday about tacit knowledge extraction that is still open.”

Three sentences. Zero additional UI. One table and one query. That is what it looks like to treat unanswered questions as a first-class object in an AI-native stack.

The connection to async work

This idea came out of a different piece I wrote about relational debt — the gap between what collaborators have done for you and what you have acknowledged. Relational debt is one specific kind of open loop: the answer is “thank you” and the owner is the person you owe. But there are many other kinds, and most of them do not have a human on the other end.

Some of them are questions I asked myself. Some are questions I asked Claude that produced an answer I did not fully process. Some are questions that emerged from a data anomaly I noticed in BigQuery three weeks ago and never investigated. Each one is a piece of knowledge with a specific shape, and none of them live in any of my databases.

When this goes wrong

The failure mode is obvious and I will name it directly: you build the table, you populate it for two weeks, and then it starts getting stale because you stopped adding rows. Every knowledge system fails this way. The question is not whether decay happens but whether the cost of maintenance is lower than the cost of the forgetting it prevents.

The second failure mode is anxiety amplification. If Claude surfaces every open loop every morning, the operator feels crushed by the weight of unclosed things and stops being able to make forward progress. The surface has to be selective. Three loops, not thirty. The worst version of this tool is the one that makes you feel more behind than you did before you used it.

The third failure mode is confusing unanswered questions with procrastination. Some open loops are open because the right answer requires waiting. A question you asked a vendor last Tuesday is not procrastination on your part. Surfacing it as a priority this morning is noise. The system has to know the difference between “waiting on external” and “waiting on me.”

The bigger claim

Knowledge systems built around resolved things are half-systems. The unresolved half is where real work lives. The move from “knowledge management” to “knowledge nodes” is partly a move from treating information as a filing cabinet to treating it as a live graph with open and closed vertices. Open vertices have properties too. Treat them with the same respect you treat the closed ones and your stack gets dramatically more useful, very fast.

I have not built the open_loops table yet. I am publishing this first because the principle matters more than the implementation. If I build it in two weeks, that is fine. If I decide the better answer is to let Claude read Gmail and Notion live at the start of each session and surface open loops conversationally, that is also fine. The point is that the category of thing exists, and if you do not have a name for it, you cannot see it.