Two in the morning, Ezra's been up for an hour, his forehead feels like a radiator, and Daniel's standing in the kitchen squinting at his phone through the fog of interrupted sleep, trying to remember whether the number on the thermometer means call the doctor now or wait until morning. The information is in his head somewhere. He just can't reach it.
That's the scene behind this week's prompt. Daniel wrote in with what I'd call a deceptively practical question. He's been thinking about the medical encyclopedia his family had when he was growing up, the one with those wonderful branching flowcharts where you'd answer yes or no and get routed to a different part of the page. He wants to build something like that for his own life. A wiki of small reference snippets covering parenting, household tasks, personal projects. Videos, audio notes, photos, text. All the little details that keep slipping away.
His actual questions are threefold. First, what unified storage solution would hold all this, with a good API and accessibility for AI agents? Second, how should he structure such a diverse collection that spans several major life domains? And third, which knowledge management tools support interactive decision trees, have both mobile and web apps, and would feel like a natural home for this project?
And there's a thread running through the whole thing that I think matters more than the tooling. He says he's realized the systems he relies on aren't shameful. That he can own using them without shame. That's the real prompt, as far as I'm concerned. Everything else is implementation.
The retrieval problem. That's what he's actually describing, and it's the part most people get backwards. They assume the hard part is storing information. It isn't. Daniel already has the information. He's recorded the laser measure video. He's made the audio notes. The photos exist. What breaks down is recall at the exact moment he needs it, which is two in the morning with a feverish toddler and a brain that's been running on four hours of sleep for a week.
ADHD affects working memory directly. It's not that the information never got encoded. It's that the buffer where you hold things temporarily while you act on them is smaller and drains faster. Add parenting fatigue on top of that and you've got a situation where the smartest person in the room can't remember whether the washing machine needs colors separated. Not because he doesn't know. Because the retrieval cue isn't firing when he needs it.
And the shame angle is real. I've watched Daniel talk about this before. There's a way that forgetting the washing machine setting becomes a moral failing in your own head. Like, I should know this. Hannah knows this. Why don't I know this? But that's not how working memory deficits work. The information was never the problem. The access was.
Right. And that's where the medical encyclopedia analogy does something clever. Those flowcharts weren't designed for people who knew nothing. They were designed for people who knew plenty but needed their knowledge organized into a sequence they could follow under pressure. The flowchart doesn't make you smarter. It makes you able to act when you're tired, scared, or distracted. Which is exactly the condition Daniel's in at two in the morning.
What strikes me about his list of examples is how low-complexity they all are. The washing machine setting. The laser measure technique. The fever protocol. None of these are conceptually difficult. But they're all high-stakes in the moment, at least emotionally. Get the fever call wrong and you're either dragging a sick kid to the emergency room unnecessarily or sitting at home when you should be calling a doctor. The flowchart turns that anxiety into a series of yes or no questions. Is the temperature above this threshold? Is the child under three months? Each branch narrows the decision space until there's only one sensible action left.
And the fever example is a good one to anchor this. The American Academy of Pediatrics is very specific. For an infant under three months, a rectal temperature of a hundred point four Fahrenheit or higher, that's thirty-eight Celsius, means immediate medical attention. Call the doctor or go to the emergency department. No waiting, no watching. For older infants and toddlers, the guidance branches based on age, temperature, behavior, hydration, how long the fever's lasted. It's a genuine decision tree, and it's been refined over decades of clinical practice.
So Daniel's instinct to model his wiki on that structure isn't nostalgia. It's pattern recognition. He's identified the format that best matches the cognitive demand of the situations he's trying to document.
The multimedia piece is also more important than it might sound. Text is terrible for procedural knowledge. I don't care how well you write. If you're trying to explain a physical technique, like the Pythagoras method on a laser measure where you're taking two indirect measurements to calculate a distance you can't measure directly, a thirty-second video beats a paragraph every time. The spatial relationships, the hand positions, the order of operations. Video captures all of it without requiring the viewer to translate words into physical movements.
And that's the thing about the laser measure video. He recorded it because the text instructions in the manual were unintuitive. The technique itself, once you see it, is simple. But describing it in words? Point the laser at the first target, press this button, then point at the second target, but make sure the angle is right, and the device does the math. It's a recipe for getting it wrong. The video removes the translation step entirely.
So the challenge isn't just storing diverse media types. It's storing them in a way that makes them retrievable when the retrieval cue fires. And right now Daniel's got videos in one place, audio notes in another, photos scattered across Google Drive, text snippets somewhere else. The fragmentation isn't just inconvenient. It actively prevents the system from working as a memory aid, because he has to remember where each piece lives in order to find it. Which is the exact cognitive load he's trying to offload.
And that's where the API requirement comes in. He's not asking for a pretty interface. He's asking for something an AI agent can query and update. The long-term play here is that the wiki becomes a backend for a system that doesn't require him to remember anything at all. He asks a question in natural language, the agent retrieves the relevant snippet, maybe even walks him through the decision tree step by step.
Let's talk about the actual tools, because this is where it gets interesting and also a little frustrating. The mainstream knowledge management space has a genuine gap here. Notion has databases and can embed content, but it doesn't have native interactive flowchart elements. You can embed a Mermaid diagram, but Mermaid is static. It renders a picture of a flowchart. You can't click through it the way Daniel wants. You can't answer a yes or no question and have the diagram route you to the next node.
And that interactivity is the whole point. A static flowchart is just a diagram. The medical encyclopedia worked because you physically traced your finger along the lines from one question to the next. Your eye didn't have to hold the entire branching structure in working memory all at once. The page did that for you. A digital version needs to do the same thing. Show me one question at a time, I answer it, you show me the next question.
And that's the feature that's remarkably hard to find. Obsidian, which is probably the closest fit for the rest of Daniel's requirements, has a plugin ecosystem that includes Mermaid support. You can write flowcharts in Mermaid syntax and Obsidian will render them. But again, they're static diagrams. There are community plugins that attempt to add interactivity, but they're inconsistent, they break when Obsidian updates, and they don't always work on mobile. The mobile app is a hard requirement for Daniel, because the fever protocol needs to be accessible at two in the morning from a phone.
Obsidian does have a lot going for it though. Local Markdown files, which means the content is future-proof and AI-friendly. Any agent can read plain text. There's a Local REST API plugin that lets external tools query and update the vault. The mobile app is solid. The web app exists, though it's not as polished as the desktop version. And the community is enormous, so there's likely a plugin for whatever specific need comes up.
Notion's tradeoff is the opposite. The web and mobile apps are excellent. The database features are useful for structuring a large collection of snippets with tags and properties. But the data lives in Notion's cloud, the API is proprietary, and the interactive flowchart feature simply isn't there. You can build a database of decision points and link between them, but it requires manual navigation. There's no native way to present a branching question sequence.
There are newer tools in this space. Tana has been getting attention for its supertag system and its approach to structured knowledge. Anytype is another one, local-first with a graph database underneath. But neither of them has cracked the interactive decision tree problem either. They're better at some things than Obsidian or Notion, but the specific feature Daniel wants, the clickable flowchart that routes you through a protocol, remains a gap across the entire category.
Which means the honest answer is that no single tool does everything he wants. The realistic approach is a hybrid. Obsidian as the storage and retrieval layer, because the Markdown files are portable, agent-accessible, and future-proof. Then some kind of additional layer for the interactive decision trees. That could be a custom-built web app that reads from the Obsidian vault. Or a plugin that renders Mermaid diagrams with clickable nodes. Or even a simple HTML page with JavaScript that handles the branching logic.
And here's where Daniel's background actually helps him. He's an AI developer. He builds agents and automation workflows. The API requirement isn't aspirational for him. He can actually wire this together. The question is whether he wants to spend his time building custom decision tree infrastructure or whether he'd rather find something off the shelf and accept the limitations.
Let's talk about structure, because that's the part that will determine whether the system actually works six months from now. Daniel mentioned three domains: parenting, household, personal projects. That's a sensible top-level split. But the real value comes from the template he applies to each snippet.
I'd suggest something like this. Each snippet has a trigger, which is the situation where you'd reach for it. Fever, washing machine, laser measure. Then the content itself, which could be text, video, audio, or a combination. Then, where appropriate, a decision tree that branches based on the specifics. And finally, links to related snippets. Fever links to medication dosage. Medication dosage links to the medicine cabinet inventory. The washing machine links to the laundry detergent purchase list.
The trigger is the part most people skip, and it's the part that makes retrieval work. If you structure the wiki by topic, you're organizing for browsing. If you structure it by trigger, you're organizing for the moment of need. The trigger is what fires when you're standing in front of the washing machine at midnight trying to remember the setting. You don't search for washing machine. You search for what setting do I use for a regular wash. The trigger is the question, not the topic.
And that's where tags and links earn their keep. A single snippet can have multiple triggers. The fever protocol might be tagged with fever, sick, temperature, emergency, doctor, thermometer. Each of those is a potential retrieval path. The links between snippets create the web that lets an AI agent traverse from one piece of information to the next based on context.
The AI agent piece is worth dwelling on, because it's the part that could make this transformative rather than just another well-organized folder. If the wiki is in Markdown with a consistent structure, an agent can parse it. If there's an index file that lists all the snippets and their triggers, the agent can search it quickly. If there's an API, the agent can update the wiki when new information arrives. The long-term vision is a system that doesn't just store Daniel's knowledge. It actively participates in his memory.
Voice is the killer feature here. Imagine Daniel at two in the morning, phone in hand, and he just says, hey, what's the fever protocol for a fourteen-month-old? And the agent reads the decision tree back to him. First question. Is the temperature above a hundred and four? No. Is he drinking fluids? Yes. Is he responsive and alert? Yes. Okay, monitor and recheck in four hours. That's the medical encyclopedia brought to life.
And the technology for that is essentially here. Speech recognition is good enough. The retrieval problem is solved if the wiki is well-structured. The text-to-speech is natural enough. The missing piece is the integration layer, which is exactly what Daniel builds for a living.
There's a knock-on effect here that I want to name. Every time Daniel can't remember something and has to ask Hannah, there's a small cost. Not a huge cost. But a small one. He feels less capable. She feels more burdened. The information asymmetry between them grows. A system like this doesn't just help Daniel remember. It redistributes the cognitive load more evenly. He becomes more useful in the moments that matter, which reduces the pressure on Hannah, which makes the whole household function better.
And there's a third-order effect too. Ezra grows up watching his father use external systems to manage his memory. That's a model. That's teaching a child that you don't have to hold everything in your head, that it's okay to use tools, that asking a system for help is not a sign of weakness. That's a gift.
The ownership mindset Daniel mentioned is the foundation for all of this. The system has to be built with the understanding that it will be imperfect. There will be gaps. Some snippets will be out of date. Some triggers won't be documented. And that's fine. The act of building it is itself a form of self-compassion. You're saying to yourself, I deserve a system that helps me function, and I'm going to build it without apologizing for needing it.
There's a concept from cognitive science called externalized cognition. The idea is that thinking doesn't just happen inside your skull. It happens in the interaction between your brain and the tools you use. A calculator is externalized arithmetic. A shopping list is externalized prospective memory. Daniel's wiki is externalized parenting knowledge. It's not a crutch. It's a legitimate cognitive architecture, and it's one that humans have been using since we first scratched marks on clay tablets.
The misconception I want to kill is the idea that relying on external systems is a sign of failure. It's the opposite. It's a sign of self-awareness. You've identified where your brain needs support, and you've built the support. That's not weakness. That's engineering.
And the other misconception is that the wiki has to be text-only to be useful. Daniel already knows this, which is why he mentioned the laser measure video. But it's worth saying explicitly. Procedural knowledge lives in video and images. Declarative knowledge lives in text. A system that only handles text is only handling half the problem.
Let's get concrete about the fever decision tree, because it's the best example of what Daniel's trying to build. The AAP guidelines branch on age first. Under three months, any fever of a hundred point four or higher is an emergency. Period. Three to six months, the threshold shifts. Six months to two years, which is where Ezra is, the guidance considers temperature, duration, behavior, and hydration. A fever of a hundred and two in an otherwise happy, drinking toddler is very different from a fever of a hundred and one in a lethargic, dehydrated one.
The flowchart captures that nuance without requiring the parent to hold it all in their head. You start at the top. What's the temperature? Then what's the age? Then how's the child behaving? Each answer routes you to the next question or to an action. The flowchart doesn't make the medical decisions. It makes the parent able to follow the medical guidance without getting lost in the branches.
The structure for Daniel's fever snippet might look like this. The trigger is, child has a fever. The content includes the temperature thresholds, the age-based guidance, and the warning signs. The decision tree branches on temperature, age, behavior, and hydration. And the links point to medication dosage, thermometer instructions, and the pediatrician's phone number.
The medication dosage link is a good example of why cross-referencing matters. Fever and medication are separate snippets, but they're deeply connected. When you're in the fever protocol, you need the dosage. When you're in the dosage snippet, you need the fever context. The links make the wiki a web, not a list.
Now, the interactive piece. Daniel said he's found this feature remarkably hard to find, and he's right. I spent some time looking at this, and the landscape is sparse. Obsidian's Mermaid support renders static diagrams. Notion has no native flowchart interactivity. Tana and Anytype don't either. There are specialized tools for building interactive decision trees, but they're mostly aimed at customer support or sales, not personal knowledge management. And they don't integrate with a personal wiki.
That's the gap. The tools that do interactive decision trees well are built for businesses. The tools that do personal knowledge management well don't do interactive decision trees. Daniel's use case falls into the crack between them.
Which brings us back to the hybrid approach. Obsidian for storage and retrieval. A custom layer for the interactive trees. And since Daniel is a developer, the custom layer is actually feasible. He could build a simple web app that reads Markdown files from the Obsidian vault, parses a custom syntax for decision trees, and renders them as clickable flows. The syntax could be something like, question, then options, then target nodes. Mermaid already has most of this. The missing piece is the click-to-navigate behavior.
The API makes the custom layer viable. Obsidian's Local REST API plugin exposes the vault to external tools. An agent could query the vault for a specific snippet, retrieve the decision tree, and walk the user through it. The same infrastructure could power a voice interface. The pieces are all there. They just need to be assembled.
There's a simpler option too, and I want to mention it because not everything needs to be a software project. A plain text file with a decision tree written in a simple branching format can be read by a human and parsed by an agent. The interactivity doesn't have to be a graphical interface. It could be a conversation. The agent reads the tree and asks the questions one at a time. That's interactive enough for the two-in-the-morning use case, and it's dramatically simpler to build.
The interactivity Daniel wants is really about sequential disclosure. Show me the next step, not the whole tree. A conversational interface does that naturally. The agent asks, what's the temperature? Daniel says, a hundred and one. The agent says, is he drinking fluids? Daniel says, yes. The agent says, monitor and recheck in four hours. That's the flowchart, just rendered as dialogue.
It works on any device with a voice assistant or a chat interface. No custom app required. No plugin to maintain. Just the wiki and an agent that can read it.
The tradeoff is that the conversational version loses the visual overview. Sometimes you want to see the whole tree to understand where you are in it. The medical encyclopedia gave you that overview. The page showed you the entire flowchart, and you could trace your finger along the branches. That spatial sense of position is valuable, and a purely conversational interface gives it up.
Maybe the answer is both. The wiki stores the decision tree in a structured format. The conversational agent reads it for the quick, two-in-the-morning retrieval. The web app renders it visually for the times when Daniel wants to study the whole protocol and understand the branches. Same source, two interfaces.
That's the right architecture. One source of truth, multiple ways to access it. The wiki is the foundation. The agents and interfaces are just views on top of it.
Let me pull on the ownership thread one more time, because I think it's the part of Daniel's prompt that deserves the most attention. He said, I realized that the systems I rely upon aren't shameful, and I can own using them without shame. It's the difference between building a system because you're broken and building a system because you're smart enough to know what you need.
The parenting context makes it more acute. There's a cultural expectation that parents should just know things. That the knowledge comes naturally. That asking for help or consulting a reference is somehow a failure of instinct. But parenting is a domain with enormous amounts of learnable information, much of it counterintuitive, and none of it taught systematically. The idea that anyone should hold it all in their head without external support is absurd.
Daniel's medical encyclopedia memory is relevant here. That book existed because even doctors, who spend years training, use references. The flowchart isn't a sign that the doctor doesn't know medicine. It's a sign that medicine is too complex to hold entirely in working memory. Daniel's wiki is the same move applied to parenting. He's not admitting defeat. He's building the reference that every parent should have.
The multimedia aspect makes it better than the old encyclopedia in one crucial way. The encyclopedia could only show static images and text. Daniel's wiki can show a video of the laser measure technique, an audio note of the washing machine setting, a photo of the medicine cabinet. The formats match the content. That's not a gimmick. That's a better encyclopedia.
The washing machine example is actually a perfect illustration of why this matters. The setting for a regular wash is probably a single piece of information. Cotton, forty degrees, spin speed whatever. But it's buried in the interface of a machine that Hannah uses more often, so Daniel doesn't have the reps to make it automatic. A photo of the dial with the correct setting circled, or a ten-second video of the button presses, solves the problem instantly. Text would work too, but the photo is faster and removes ambiguity.
The photo is easier to capture. Daniel can take it in five seconds while standing in front of the machine. The barrier to adding a snippet is low, which means the wiki actually gets populated. That's the other failure mode for systems like this. If adding information is friction, the system stays empty, and an empty system provides no value.
The API point connects here too. If the system is easy for an agent to update, Daniel can capture information in whatever format is most convenient in the moment. Voice note while cooking. Photo while doing laundry. Video while figuring out the laser measure. The agent files it into the right place, applies the template, adds the tags. The capture is effortless because the organization is automated.
That's the dream, honestly. The system that maintains itself. Daniel captures the raw material. The agent structures it. The wiki stores it. The interfaces retrieve it. The whole thing works as an extension of his memory without requiring constant manual curation.
The curation that does happen becomes a meaningful activity rather than a chore. Sitting down once a week to review the new snippets, check the links, update the decision trees. That's not maintenance. That's reflection. It's a way of noticing what you've learned and what you keep forgetting.
There's a version of this that becomes a family resource, not just Daniel's personal system. Hannah can add her knowledge. The pediatrician's advice can be captured. The daycare's policies can be documented. The wiki becomes the household's shared memory, which is a powerful thing.
Ezra inherits it eventually. Not just the information, but the practice. The habit of externalizing knowledge, of building systems that support you, of treating your brain as a partner rather than a container. That's a legacy.
Hilbert: The best decision tree I ever used was laminated.
Hilbert: I did knowledge management for a medical device company in the nineties. Troubleshooting flowcharts for field technicians. Paper, three-ring binders, tabs. A technician would call in with a machine down, and we'd walk him through the binder. Flip to the tab for the error code. Read the first question. Yes or no. Flip to the next page. The pages were numbered, and the branches told you which page to turn to. It was a hypertext system made of paper.
Hilbert: One of our best technicians, a guy named Ray, he kept a laminated card in his van. Just the top ten error codes and the first three branches for each. He said the binder was for when he had time. The card was for when he didn't.
Hilbert: One time Ray's phone died in the middle of a call. Dead battery, no charger, and he's standing in a hospital basement with a machine that won't start and a patient waiting upstairs. He pulled out the laminated card and worked the whole problem from that. Flip it over, there's the next branch. He had it fixed before the phone came back on. He called in and said, the card did the thinking, I just did the walking.
Hilbert: I still have a binder of those flowcharts. Not the card. Ray kept the card. But the binder's in a box somewhere. I could digitize it for Daniel if he wants. Scan the pages, run them through one of those text recognition things.
Hilbert: But here's the thing. A flowchart on a screen is not the same as a flowchart on a card. On the card, you can see the whole thing at once. Your eye finds the branch you need without scrolling. And you can skip a step when you know it's wrong. The card doesn't stop you. It just sits there. The digital version, it wants to walk you through every node. It doesn't trust you to jump ahead.
Hilbert: Ray knew when to skip a step. That's the human element. The flowchart gets you to the right neighborhood, but the technician gets you to the right house. Daniel's wiki will be the same way. The decision tree is the map. Daniel's still the one driving.
The laminated card is a good reminder that the format matters as much as the content. A decision tree you can hold in your hand, glance at, and act on is different from one you have to unlock a phone to read.
The skipping point is subtle. A rigid algorithm that forces you through every branch is slower than a human who knows which questions are irrelevant. The best system gives you the branches and lets you choose your own path through them. That's what the medical encyclopedia did. The page showed you the whole tree. You traced the branches you needed and ignored the rest.
Which is why the visual overview matters. The conversational agent is great for the two-in-the-morning fog. But the laminated card version, the thing you can see all at once, is better for the times when you're awake enough to use judgment. Daniel's system should probably have both.
The question I'm left with is whether a digital system can ever replicate the serendipity of flipping through a physical encyclopedia. The thing about those books is that you'd look up one thing and find three others on the way. Your eye would catch a diagram, a cross-reference, a condition you'd never heard of. The browsing was part of the learning.
That's the open question for Daniel. Can a wiki, with its search and its links and its structured templates, ever give him the same accidental discovery? Or does the efficiency of retrieval come at the cost of the wandering that made the encyclopedia memorable?
I think the answer is that they're different tools for different moments. The wiki is for when you need the answer now. The encyclopedia was for when you had time to learn. Daniel's system can be both, if he builds in the space for wandering. Maybe a random snippet feature. Maybe a browse mode that shows the links in a way that invites exploration.
As AI agents get better, the wiki could become proactive. Not just waiting for Daniel to ask, but anticipating what he might need. The agent notices that Ezra's been feverish, checks the protocol, and reminds Daniel of the warning signs before he even asks. That's the version of this that starts to feel like a real second brain.
The best system is the one that reduces shame and increases agency. Whether it's a laminated card in a van or a Markdown vault queried by an agent. The point is that Daniel gets to act in the moment, with confidence, instead of fumbling for the information and feeling bad about it.
That's worth building, even if the interactive decision tree feature doesn't exist off the shelf yet. The pieces are all there. The vision is clear. The rest is just assembly.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts. Email us at show at my weird prompts dot com. We'll be back soon.
