Build your own
Author a diagnostic case
A Botopsy case is not a quiz. It is a real system that runs, broken in one specific way, with a grader that judges whether you made it behave. This page documents that shape and the flow we are building toward, so you understand how the cases you fix are put together.
Anatomy of a case
Every case has four parts. Strip any one of them and it stops teaching diagnosis and starts teaching pattern-matching against an answer key.
1. A working system, broken on purpose
A case ships a real system that runs, then plants a fault in editable files. The learner opens files that actually break behavior, in the real stack, not a diagram of one. No toy stubs, no fill-in-the-blank. If you delete the plant, the system works; that is what makes the fault fixable rather than fictional.
2. Evidence to bound the fault
These are the commands a learner runs to see the failure and narrow it: logs, the node graph, topic echoes, transform lookups, lifecycle state. The point is diagnosis before editing. A learner who edits first is guessing; a learner who reads the evidence first knows where to cut.
3. A behavioral grader
The grader relaunches the learner’s current files and judges observed runtime behavior. Does the system now do the right thing? That is the only question it answers. It is never a text diff against a reference answer, because there is always more than one correct fix, and a diff punishes the good ones.
4. A transfer challenge
A second, differently shaped scenario that applies the same lesson elsewhere. If the first case was a reversed sign on a wheel encoder, the transfer might be a reversed sign somewhere with no wheels in sight. The skill sticks because the learner applied it twice, instead of memorizing one fix.
The authoring flow
Building a case is six steps. They run roughly in order, though the grader and the broken files tend to get written together.
- Pick a fault class. The kind of failure you want to teach: a bad transform, an incompatible QoS profile, a misconfigured lifecycle node, a reversed sign.
- Define the broken files plus a healthy reference. The editable broken state the learner starts from, and the working version that proves the fault is fixable.
- Script the evidence. The commands and observations that let a learner bound the fault before touching code.
- Write a behavioral grader.A pass/fail check that runs the learner’s current files and reads observed behavior, not file contents.
- Add a root-cause explanation and distractors. The real why, plus the plausible-but-wrong causes learners should rule out.
- Add a transfer prompt. A related scenario that applies the same lesson in a new context.
Live today vs coming
Live now: over 110 hand-built diagnostic cases and 10 browser playgrounds you can work through today, each on the behavioral-grader model above.
Planned: the self-serve case builder to author, grade, and publish your own case using this exact flow.