Method
How I approach a question
Three moves, in the same order, on every project — plus a plain statement of what the status and evidence labels on this site are allowed to mean.
Step 01
Investigate the mechanism
Work out how the money actually moves before deciding whether the technology matters, because most AI arguments are really arguments about a cost structure nobody has written down.
A question like “is this company exposed to AI?” cannot be answered at that level of abstraction. It has to become a question about a specific mechanism: which cost falls, whose willingness to pay changes, which step in the delivery chain stops needing a person.
So the first pass on every project is structural. In Disrupt This Business that meant writing down how a seat price and a per-outcome price actually compete for the same customer. In Priced In it meant deciding that the model runs backwards from the price, because the requirement is the thing being argued about.
Step 02
Test the assumptions
Build the smallest thing that could show an assumption is wrong, then run it against a baseline dull enough that beating it means something.
An assumption that cannot fail is not an assumption, it is a preference. The test has to be capable of returning an inconvenient answer, and the comparison has to be against something honest rather than something flattering.
That is why The Moat Test measures its challenger against a deterministic tagged-line extractor rather than a commercial product: the baseline is unimpressive, legal to publish, and impossible to argue with. It is also why the economic engine in Disrupt This Business is deterministic — a result nobody can reconstruct is not evidence.
Where a test has not been run, the project says so. All three now run as software, which is a different claim: only The Moat Test has recorded a measured run, and its gold annotations are still unreviewed drafts.
Step 03
Make the trade-off explicit
State what the recommendation costs and what would change it, so the reader is disagreeing with a position rather than with a tone.
Every case page carries a Trade-off and an Uncertainty in its opening brief, before the long-form argument starts. Both are there so a reader can find the weakest part of the position quickly instead of hunting for it.
The same rule applies to conclusions. Where the evidence does not support one yet, Position reads “Investigation in progress” and explains the test that would settle it. A confident recommendation with nothing behind it would be the easiest thing to write and the least useful thing to read.
What the labels mean
Every project carries two labels, and they are separate claims. One describes the software; the other describes the evidence. A project can have a working demo and no measured results, or specified evidence and no software at all. A successful build is never a reason to move either label.
| Label | What it means |
|---|---|
| Concept | Designed and specified. No runnable demo and no measured results yet. |
| Prototype | A working demo runs. Results are reported by the evidence label. |
| Published | An authored case with reviewed evidence. |
| Label | What it means |
|---|---|
| Illustrative | Hand-authored or specified content used to show structure. No performance claim of any kind. |
| Measured, partial | Real output from a recorded run, archived with its run metadata. Covers part of the question, not all of it. |
| Reviewed | Measured evidence that a person has actually reviewed against a stated rubric. |
All three projects are currently Prototype: the software runs and each one is deployed where you can reach it, so every project shows a launch button. Two carry Illustrative evidence; The Moat Test carries Measured, partial. No case publishes a recommendation, because software that runs is not a finding.