dcnstrct: a debugging tool that traces app execution paths with IBM Bob 2.0

Emma @_HEISEMMAOriginally posted 2026.09.27

Open original on X

we built dcnstrct for the @ibm bob 2.0 hackathon. the idea here is to make it easier to understand what an application actually does after you use it. the idea starts with something simple. you open an unfamiliar app, click a button, and get a result. understanding how that result happened means following the request through the application, checking the decisions it made, and finding the evidence behind them. we wanted to make that journey visible. our first build uses a synthetic order application. you can try cancelling an order before fulfillment, follow the recorded execution, inspect individual steps, and check the relevant source and observed data. when cancellation is accepted, you can see the order become cancelled, a synthetic notification record get saved, and the fulfillment worker read the current order state and skip shipment. then you can run the same action on an order that has already shipped. the request is refused. the order stays shipped. no cancellation notification is created, and the worker is not invoked. having both runs available makes the behavior easier to explain. the starting state changes the path, and you can inspect exactly where the journeys diverge. ibm bob was part of building that experience. we used bob to help build and review the application logic, then connected it to our local evidence tools through mcp. bob could inspect completed runs, retrieve their events, read the relevant project source, and save explanations grounded in what those runs actually recorded. those explanations are available inside dcnstrct alongside the journey. select a step, read bob’s interpretation, inspect the cited source, and open the observed data to check what happened. we also made the relationship between an explanation and its evidence explicit. a recorded interpretation is matched to its scenario and source revision before it is shown. the interface identifies it as recorded and keeps uncertainty visible. that mattered during development because working with the integration involved real friction. we encountered a stale mcp process and a source tool schema issue. resolving them meant checking the actual tool calls, refreshing the process, and using a local file read fallback for the cited source ranges. that experience helped shape the product. an explanation becomes much more useful when you can follow its references and verify the underlying evidence yourself. the explanations in this demo are recorded, so visitors can explore the build without needing their own bob account. what we’re excited about is how this changes the process of getting familiar with software. you start with an action you understand. you follow its observed journey. you connect the behavior to the code and data that explain it. that gives you something concrete to discuss, question, and learn from. the scope is deliberately small today: one synthetic order app and two cancellation paths. it gives us a clear foundation for exploring this approach further. built for the ibm bob hackathon, with a working demo you can try here: live app: https://dcnstrct.vercel.app repo: https://github.com/emmagh1/dcnstrct

This post quotes another post: x.com/_heisemma/status/2104220176791044404