Welcome back to My Weird Prompts. I am Corn, and I am joined as always by my brother, the man who has spent more time reading documentation than most people spend sleeping. He is the only person I know who gets excited when a software update includes a fifty page change log.
Herman Poppleberry here, at your service. And yes, Corn, documentation is the highest form of literature. It is where the truth lives. Code can lie, marketing definitely lies, but the documentation? That is the contract between the creator and the universe. If it is not documented, it does not exist.
Well, today we have a prompt from Daniel that I think is right up your alley. He is looking for a way to turn decision-making algorithms, specifically those first aid flowcharts we all know, into something interactive. He wants an app, or at least a framework, where the logic can be customizable and maybe even written by an artificial intelligence agent. He is tired of squinting at a poster on a wall while someone is bleeding.
This is a classic engineering problem, Corn. It is the transition from a static representation of knowledge, like a P D F or a printed poster on a wall, into an executable state. Daniel is originally from Ireland but has been in Jerusalem for years now, and he is a very technical guy. He is deep into automation and open source, so he knows that the gap between a flowchart and an interactive app is sometimes wider than it looks. It is the difference between a map and a G P S. One just shows you the terrain; the other tells you when to turn left because there is a metaphorical car crash ahead.
It is interesting that he mentions first aid. We actually talked about emergency procedures back in episode seven hundred and sixty five, specifically about engineering your emergency standard operating procedures. But Daniel is pushing it further. He does not just want a clear document; he wants a tool that guides you through the logic step by step. If this, then that. If the patient is breathing, do X. If not, do Y. In a high stress situation, your brain basically turns into a potato. You cannot process a complex diagram. You need one question at a time.
And the first thing we have to talk about is the fundamental difference between a flowchart and a state machine. Most people look at a first aid chart and see a flowchart. They see boxes and arrows. But if you want to build an app that actually works and is reliable, you are really looking for a state machine. In a flowchart, you are just following arrows, and it is easy to get lost or end up in an undefined state. In a state machine, the system knows exactly what state it is in at any given moment and what transitions are allowed based on specific inputs. It is mathematically rigorous.
So, for someone like Daniel who wants to build this, where do we even start? Is there a specific language or framework that makes this easy? He mentioned Python or JavaScript or even something more niche. He is looking for that sweet spot between ease of use and professional robustness.
If we are talking about web and mobile, JavaScript and TypeScript are the heavy hitters here. But the real answer is not just the language, it is the library. There is a specific tool called XState that is almost tailor-made for what Daniel is describing. XState is a library for creating, interpreting, and visualizing finite state machines and statecharts. It was created by David Khourshid, and it has basically revolutionized how we think about application logic in the front-end world.
I have heard you mention XState before. Is that the one that has the visual editor? Because Daniel specifically asked for something where an A I could help, and visual tools usually play nice with structured data.
Yes! And that is the crucial part for Daniel’s request about A I agents. XState has a visualizer where you can see the logic as a diagram, but the underlying code is just a JavaScript object, usually formatted as J S O N. This is perfect for an artificial intelligence. You can tell a large language model to write a state machine for a first aid burn protocol in XState format, and it will give you a structured object with states like checking for breathing, assessing burn depth, and cooling the wound. Because it is a formal specification, the A I is much less likely to hallucinate a random step that does not connect to anything.
That makes a lot of sense. If the logic is structured as data rather than just nested if-else statements in code, it becomes much more portable. You could feed that J S O N into a web app or a mobile app, and the engine would know how to render the next question. You are basically separating the brain from the body.
Precisely. The goal is to separate the logic engine from the user interface. You do not want to hard-code every button and every screen transition. You want a generic interactive decision runner. Think of it like a game engine, but for protocols. You provide the rules in a J S O N file, and the engine handles the navigation. This is actually how a lot of modern medical software is being built now. It uses something called C D S Hooks, or Clinical Decision Support, which often relies on these kinds of structured logic trees.
But Daniel also asked if there are existing tools. Not everyone wants to build a custom React app from scratch, even with A I help. Are there low-code or no-code ways to do this that are more sophisticated than just a basic form? I mean, Google Forms has branching logic, but it feels a bit clunky for a medical emergency.
There are a few. On the more professional or enterprise side, there are things called rule engines. Something like Drools in the Java world, or a simplified version like J S O N Rules Engine for Node dot J S. These allow you to define complex business logic in a structured way. But for a slick interactive app, you might look at something like Typeform, though that is a bit too linear for complex branching logic. A better fit might be something like Glide or Bubble if you want to build the U I visually, but even those can get messy when the decision tree gets deep. If you have fifty different branches, a drag-and-drop interface starts to look like a bowl of spaghetti.
What about the visualization? Daniel mentioned Mermaid. We love Mermaid for documentation, but it is static. Is there a bridge between the static diagram and the interactive experience? I know we use Mermaid for our internal show notes to map out episode flows.
There is a project called React Flow that is incredible for this. It allows you to build node-based editors. So, if Daniel wanted to create a tool where he or an A I could drag and drop nodes to define the first aid steps, React Flow would be the framework to use. It handles all the zooming, panning, and connecting of lines, and then you just have to map those nodes to your application logic. It is basically like building your own version of Miro or Lucidchart, but one that actually executes the logic.
I like the idea of the A I agent being the one to write the logic. We have discussed sub-agent delegation in episode seven hundred and ninety five, and this feels like a perfect task for a specialized agent. You give it the medical handbook, maybe a P D F from the Red Cross, and tell it to output a valid XState machine.
It is actually a very reliable way to use A I. Asking an A I to write a long essay can lead to hallucinations. But asking it to output a very specific, schema-validated J S O N object that represents a decision tree is much easier to verify. You can even write a script to validate that the state machine has no dead ends or infinite loops before you ever deploy it to the app. In the world of formal methods, we call this model checking. You are proving that your algorithm is safe before a human ever touches it.
That is a great point. Safety is everything in a first aid context. You do not want the app to hang or crash when someone is trying to remember how to treat a snake bite. Or worse, you do not want the A I to accidentally skip a step like checking for a pulse because it got confused by the formatting of the source text.
And that is why the state machine approach is superior. It is mathematically deterministic. You can prove that for every possible input, there is a defined output. You cannot always say that about a giant pile of nested if statements written by a tired programmer at three in the morning. With XState, you can actually use their test generator to automatically create test suites that walk through every single possible path in your flowchart to ensure they all lead to a valid conclusion.
So, let us talk about the data structure. If Daniel is building this, he probably wants a way to store these algorithms in a way that is easy to update. If the medical guidelines change—say, the recommended ratio of chest compressions to breaths changes—he just wants to swap out a file without rebuilding the whole app.
Yes, and that brings us to the concept of a domain specific language, or D S L. Daniel could define his own simple language in Y A M L or J S O N. For example, a step might have a title, a description, an image U R L, and a set of options. Each option points to the I D of the next step. It is very clean.
Wait, I am going to stop you there for a second. That sounds like the structure of those old choose your own adventure books. You know, if you want to enter the cave, turn to page forty two. If you want to run away, turn to page eighty nine.
It is exactly like that! In fact, there are tools for interactive fiction, like Twine, that are actually very powerful for this. Twine uses a language called Harlowe or SugarCube to create branching stories. People use it for games, but it is actually a fantastic way to build a rule-based decision tree. It exports to H T M L, so it works on any phone or computer, and it is very easy for an A I to write. You can even use the Twee format, which is a plain text version of a Twine story, which makes it very easy to track changes in Git.
That is an interesting pivot. Using a game development tool for medical protocols. It makes sense because the core requirement is the same: branching logic based on user choice. And Twine has a huge community of people who have already solved the problem of how to make these trees look good on a mobile screen.
And Twine is open source, which we know Daniel appreciates. You can customize the C S S to make it look like a professional medical app rather than a retro text adventure. You can embed videos, audio cues, and even timers. Imagine a screen that says perform compressions now and has a metronome clicking at one hundred beats per minute. That is trivial to add in a tool like Twine.
I can see the potential there. But what about the mobile experience? Daniel mentioned web or mobile. If he is in Jerusalem, maybe he wants something that works offline, in case he is in a basement or an area with poor reception. Or maybe he is out hiking in the Judean Desert. You cannot rely on a cloud connection when you are dealing with heatstroke.
That is a critical requirement. If you are using a web-based tool, you would want to build it as a progressive web app, or P W A. That way, it can be installed on the home screen and cache all the logic locally. If Daniel goes the custom route with React and XState, he can just bundle the logic files directly into the app package. There is no need for a back-end server at all during the actual emergency. The entire decision tree lives on the device.
Let us dig a bit deeper into the A I side of this. If I am Daniel and I have a one hundred page P D F of medical protocols, how do I actually get the A I to help me without it making things up? We have all seen A I give confident but wrong advice.
The best way is to use a technique called few-shot prompting combined with a strict schema. You do not just say, make me a flowchart for first aid. You say, here is a J S O N schema for a decision tree. Here is an example of a simple protocol for a cut finger. Now, take this text about heatstroke and convert it into the same J S O N format. By giving it the structure and an example, you anchor the A I's output. You can also use tools like Instructor or Marvin in Python, which use Pydantic to force the A I to return data that fits your exact specification. If the A I tries to return something that is not valid J S O N, the library will catch it and ask the A I to fix it.
And then you could have a second A I agent act as a red-teamer. We talked about red-teaming user interfaces with A I in episode eight hundred and thirty five. You could have an agent pretend to be a panicked user and try to break the logic or find confusing steps. It could simulate different inputs to see if it can ever reach a state where the app does not know what to do.
That is a brilliant connection, Corn. You could literally simulate thousands of emergency scenarios in seconds to see if the decision tree leads the user to the correct outcome every time. It is like unit testing for medical logic. You could even have the A I check for medical consistency. If one branch says to apply a tourniquet and another branch says never apply a tourniquet for the same injury, the red-teamer agent would flag that contradiction immediately.
It feels like we are moving toward a world where the documentation is the application. There is no middleman. You write the rule, and the app exists. It is the ultimate form of what we call literate programming, where the explanation and the execution are one and the same.
That is the dream of the death of S a a S, which we explored in episode eight hundred and sixty four. Instead of paying for a subscription to a first aid app that might go under or stop being updated, you build your own bespoke tool using these open-source frameworks and A I. You own the logic, and you own the data. If the company that made your app goes bankrupt, your first aid protocols do not disappear. They are just files on your phone.
I think Daniel would really appreciate that. He is very much about that self-sovereign tech stack. He wants tools that are durable and transparent.
He really is. And speaking of Jerusalem, if he is building this for a local context, he might have to deal with multiple languages. Hebrew, Arabic, English. That brings in the whole bi-directional text issue we covered in episode seven hundred and seventy five. If your interactive app needs to switch from left-to-right for English to right-to-left for Hebrew, that is another layer of complexity for the U I.
Oh, man, I remember that episode. The formatting nightmares. But if he uses a solid framework like React, a lot of those layout issues are solvable. The logic, however, stays the same regardless of the language. The state machine does not care what the label on the button says. It just cares that button A was pressed.
The transition from the state checking-pulse to the state performing-C P R is the same whether you call it C P R or something else. You can have a separate translation file that maps the state names to the display text in any language. This makes the app incredibly easy to localize. You could even have the A I handle the translations, ensuring that the medical terminology is accurate in all three languages.
So, to summarize the technical stack for Daniel: XState for the logic engine, React or a similar framework for the U I, and J S O N as the bridge that allows an A I to write the protocols. Or, if he wants something faster, look into Twine for the quick-and-dirty interactive format.
I would also throw in a mention for a tool called Obsidian. I know many of our listeners use it for note-taking, but with the Canvas feature and some of the community plugins, you can actually create interactive flowcharts that function almost like a mini-app. It might be a good place for Daniel to prototype the logic before he commits to building a full app. You can link notes together and use the graph view to see how the decisions branch out.
That is a good shout. Prototyping is key. You do not want to find out your logic is flawed after you have already spent weeks on the mobile styling. You want to fail fast and fail often in the design phase, not in the middle of an actual emergency.
Speaking of weeks, I wonder how Ezra is doing. Daniel and Hannah’s son must be getting big now. I imagine having a young child makes you think about first aid protocols a lot more often. You start seeing hazards everywhere. Corners of tables, small objects on the floor, the list is endless.
Oh, absolutely. The stakes get much higher when it is your own kid. You want that information to be instant and unmistakable. You do not want to be flipping through a paper manual while your toddler is choking on a grape. You want a big red button that says choking and then immediate, clear instructions.
Which is why the interactive format is so much better than a book. In a crisis, your brain loses the ability to process complex paragraphs. You just want one question at a time. Is he breathing? Yes or no. If the answer is no, the app should immediately tell you what to do next, perhaps with a loud audio prompt so you do not even have to look at the screen.
It is about reducing the cognitive load. You are basically outsourcing your executive function to the app so you can focus on the physical task.
Precisely. You are offloading the navigation of the complexity to the machine, so the human can focus on the physical task of helping. It is a partnership between human empathy and machine logic.
I think we have given Daniel a lot to chew on here. But I want to go back to the rule engine idea. You mentioned Drools, which is a bit heavy. Is there a modern, lightweight version for the web? Something that feels more like nineteen ninety six than twenty twenty six?
There is one called Zen Engine. It is written in Rust but has bindings for other languages. It is designed to be extremely fast and uses a simple J S O N format for the rules. It is often used in fintech for decisioning, like determining if a loan should be approved, but it would work perfectly for medical flowcharts. It even has a visual editor where you can see the logic branches. It is very high performance, which is great for low-end mobile devices.
Zen Engine. That sounds like something Daniel would like. It is modern, fast, and uses a logic-first approach. And because it is written in Rust, it is incredibly memory-safe, which fits our theme of reliability.
It is very slick. And because it is high-performance, you could run it on a low-powered device without any lag. It also supports something called J S O N Logic, which is a way to write complex rules in a format that is easy for both humans and machines to read.
We have covered a lot of ground, but I feel like there is still one piece missing. How do you handle the media? In first aid, a picture is worth a thousand words. A video of how to do a bandage is even better. How does Daniel integrate that into his state machine?
That is where the bespoke app approach really shines. In your J S O N protocol, each state can have a media key. If the state is apply-tourniquet, the media key points to a fifteen second looping video. Your U I engine sees that key and automatically renders the video player above the instructions. You can even have different media for different devices—low resolution for older phones or high resolution for tablets.
It is like a dynamic instruction manual that follows you. It could even use the phone's camera to show you where to place your hands using augmented reality.
And you could even have the A I generate the descriptions for those images to make the app more accessible for screen readers. Accessibility is not just a nice-to-have in a first aid app; it is a requirement. You might be the one injured and trying to use the app by voice.
We are really building a high-end tool here. I hope Daniel actually builds this. I would use it. I would feel a lot more confident in my first aid skills if I had a Herman-approved state machine in my pocket.
Me too. I would feel much better having a Herman-approved state machine guiding me through a crisis than trying to remember what I learned in a three hour course five years ago. Most people forget eighty percent of what they learn in those courses within a month. An app like this bridges that gap.
Well, you are the expert, Herman. I just ask the questions.
And they are good questions, Corn. They keep me honest. They remind me that at the end of the day, all this technology has to serve a human purpose.
Dorothy: Herman? Herman, are you there?
Oh... Mum? Mum, I am actually in the middle of recording the show right now. We are right in the middle of a very technical explanation of state machines.
Dorothy: I know, I know, but I just wanted to tell you, I left a little container of that mushroom soup you like by your front door. I was passing by and I did not want to bother you, but you must eat, Herman. You look so thin on the internet lately. I saw that video you posted and I thought, that boy needs some vitamin D and some cream of mushroom.
Mum, I am fine, really. And everyone can hear you. This is Episode eight hundred and fifty seven. We have thousands of people listening.
Hi, Dorothy! The soup sounds amazing. Can you leave some for me next time? I am a big fan of your cooking.
Dorothy: Oh, hello, Corn! Of course, sweetheart. I have a whole extra batch. Herman, do not forget the Tupperware this time. The blue lid, okay? It is part of a set. I do not want to have to come looking for it.
Yes, Mum. The blue lid. I will get it back to you. I promise. I have to go now, we are talking about first aid. It is very serious.
Dorothy: First aid? Very important. Make sure you tell them about putting a cold spoon on a burn. My mother always said that. It takes the heat right out.
We will... uh... we will look into that, Mum. Love you, bye.
Dorothy: Love you too, bubbeleh. Bye-bye!
A cold spoon, Herman? Is that in the medical literature? I do not remember seeing that in the Red Cross manual.
I am going to go out on a limb and say we should probably stick to the official protocols for Daniel’s app. Sorry about that. My mother has a sixth sense for when I am trying to sound professional. She can smell a technical podcast from three miles away.
It is fine. It adds a bit of flavor. Much like the mushroom soup, I imagine. It is good to be reminded that there is a world outside of J S O N schemas and statecharts.
Right. Where were we? Oh, the logic engines. We were talking about how to make these things robust.
We were talking about the media integration. But I want to pivot slightly. Daniel mentioned that he wants a programming language or framework. We talked about XState and Zen Engine. But what if he wants to stay in the world of Python? He is a tech comms guy, and Python is huge in the A I space. It is the language of choice for most people working with large language models.
If he wants to stay in Python, there is a very cool library called SpiffWorkflow. It is a powerful workflow engine that implements the Business Process Model and Notation standard, or B P M N.
B P M N. That sounds very corporate. Like something you would use to map out an insurance claim process.
It is! It is the standard that big companies use to map out their business processes. But the beauty of it is that it is a visual standard. There are tons of editors out there, like Camunda, where you can draw your flowchart, and SpiffWorkflow can take that X M L file and actually run it as Python code. It is incredibly robust and handles things like parallel tasks and complex timers.
So you could draw a first aid chart in a professional diagramming tool, and Python could execute it? That sounds like exactly what Daniel was asking for. It bridges the gap between the visual and the executable.
It is probably overkill for a simple app, but if Daniel wanted to build something very robust that integrates with other systems—say, automatically calling emergency services if a certain state is reached—B P M N is the pro way to do it. There is even a web-based modeler called b p m n dash j s that allows you to embed the editor right in a browser.
I like that there are so many levels to this. You can start with a simple Twine story, move up to an XState machine in React, or go all the way to a B P M N workflow engine in Python. It is a spectrum of complexity.
It really depends on the goal. If the goal is a quick personal tool for Daniel and Hannah to have on their phones for Ezra, Twine or a simple custom React app is the winner. If he is looking to build the next big open-source emergency response platform, he should look at XState or Zen Engine. The key is to choose the tool that matches the stakes.
Let us talk about the My Weird Prompts angle. What is the weirdest way to solve this? We have talked about the professional ways, but what is the hacky, weird solution that actually works?
The weirdest way? Oh, that is easy. You could build the entire decision tree as a series of nested folders on a computer or a cloud drive.
Wait, explain that. How do you turn a folder structure into an app?
Okay, so you have a main folder called First Aid. Inside it, you have folders for Burns, Choking, and Cuts. You click on Burns. Inside that folder, you have two more folders: Is the skin charred? and Is the skin just red? You keep clicking through folders until you reach a file called instructions dot t x t. The folder names are the questions, and the subfolders are the answers.
That is... incredibly low-tech and yet strangely brilliant. It requires no code at all. You are just using the file system as your logic engine.
It is completely platform-independent! It works on Windows, Mac, Linux, iPhone, Android. It is even searchable. You just use the file explorer as your user interface. It is the ultimate minimalist approach. No dependencies, no framework, no updates. Just folders and files.
I love that. It is the ultimate Death of S a a S solution. It is just files. You could even sync it via Dropbox or I Cloud, and it would be available on all your devices instantly.
It is a bit clunky, of course. You do not get the nice videos or the big buttons. But in terms of pure rule-based navigation, it is the simplest possible implementation of a decision tree. It is basically a physical representation of a linked list.
I think Daniel would find that hilarious. But probably a bit too simple for his tastes. He likes his automation. He would probably find it frustrating that he couldn't easily automate the creation of a thousand folders.
True. He would probably write a script to generate the folder structure from a markdown file. Which, ironically, would bring us right back to needing a logic engine.
Which brings us back to the A I. The A I is the glue here. Whether it is generating folders, J S O N, or Python code, the ability to translate medical text into a structured format is the real breakthrough. We are no longer limited by our ability to manually code every branch.
It really is. We are moving away from the era where a programmer had to sit down and manually map out every branch of a flowchart. Now, the programmer builds the engine, and the A I provides the map. This allows for much more complex and nuanced protocols than we ever could have handled before. You could have a protocol for every specific type of snake in the world, rather than just a general snake bite instruction.
I wonder if there is a way to use A I to even simplify the questions. Sometimes medical jargon is a bit much. Could the A I act as a translator in real-time? If the protocol says check for cyanosis, the A I could translate that to is the skin turning blue?
You could have a toggle in the app for Explain like I am five or I am a medical professional. The state machine stays the same, the logic is identical, but the text displayed to the user is transformed by the A I on the fly. This is the power of separating the logic from the presentation layer.
That would be incredibly useful in a high-stress situation. You do not want to be googling what distal means when you are trying to help someone. You just want to know if you should move the arm or not.
You just want the most direct, actionable instruction possible. The A I can act as a filter, stripping away the unnecessary information and leaving only what is needed for the current step.
This has been a really fascinating look at a problem that seems simple on the surface but has so many deep technical layers. From state machines to B P M N to nested folders. It is all about how we structure and navigate knowledge.
It is the kind of thing that makes you realize how much of our world is just hidden algorithms. Every time you call a customer support line or follow a recipe, you are traversing a state machine. We are just talking about making those machines more explicit, accessible, and reliable.
And more reliable. Especially when it comes to something like first aid where the cost of a mistake is so high.
Especially then. I really hope Daniel finds a path here that works for him. Whether he goes with XState or Zen Engine or just a big pile of folders, the world needs better ways to access life-saving information. The current system of posters and P D F s is just not cutting it in the twenty first century.
Well said, Herman. I think we have given him plenty of options to explore. And maybe he will even send us a link to the prototype once he has it running. I would love to see how he handles the Irish-Jerusalem cultural blend in the U I.
I would love to see it. Maybe he can include a Dorothy mode that reminds you to eat some soup after you have successfully bandaged a wound. A little bit of grandmotherly care to soothe the nerves after an emergency.
Only if it is the mushroom soup. I am not settling for chicken noodle.
Deal. I will make sure to include that in the specification.
Well, that about wraps it up for this episode. Daniel, thanks for the prompt. It really got our gears turning. It is always great to think about how tech can be used for something genuinely helpful.
Yes, thank you, Daniel. It is always a pleasure to dive into these engineering challenges. It keeps my brain sharp and my Tupperware collection growing.
Before we go, if you have been enjoying My Weird Prompts, we would really appreciate it if you could leave us a review on your favorite podcast app. It really does help other people find the show, and we love hearing what you think. Even if you just want to tell us your favorite soup recipe.
It makes a huge difference, so thank you to everyone who has already left a rating. We read every single one of them.
You can find all of our past episodes, including the ones we mentioned today about emergency S O P s and the death of S a a S, at myweirdprompts dot com. We have a full archive there and a contact form if you want to send us your own weird prompt.
Or you can just email us directly at show at myweirdprompts dot com. We love hearing from our listeners, especially the technical ones who want to argue about state machine theory.
And a quick shout out to Suno for the music you hear at the beginning and end of every episode. It is amazing what you can generate these days with just a few keywords.
It really is. Alright, I think it is time to go find that soup. I can smell it from here.
Save some for me! Thanks for listening to My Weird Prompts. We will see you next time.
Goodbye, everyone! Stay safe out there.
