Scientific diagnosis for complex technical systems.
I investigate AI systems, software architectures, and technical claims to determine what is actually happening, and give leadership an evidence-based account they can act on.
Technical due diligenceSystems diagnosisIndependent AI advisory
I go deep into the system and come back with an explanation everyone can act on.
The questions that lead here.
Each one is a scientific investigation applied to business-critical technology. If one of these is sitting on your desk this quarter, we should talk.
An AI initiative where no two people give the same answer about what it does, and budget is about to be committed on the strength of vendor decks.
A production system that passes every test and is still producing something wrong.
A major purchase resting on performance claims that nobody internal is positioned to evaluate.
A roadmap or system design that assumes capabilities the models may not reliably have.
A system everyone depends on and nobody wants to touch, because the people who built it are gone and nobody can say what kind of thing it is.
An acquisition, and two stacks that have to be understood before they can be merged.
Down into the system, then back up into something you can act on.
Three moves, in sequence: descent, causal reconstruction, classification. The third is what makes the first two worth paying for: anyone can produce a 60-page findings document nobody reads.
Descend.
Into the code, the documents, the decision history, the interviews, as deep as the material goes.
Reconstruct the causal chain.
What actually happens, in what order, driven by what. Not the architecture diagram, the real one.
Classify.
Identify what kind of system this actually is and place it in a class whose behavior is already understood, so its known properties become available to your team.
What the work looks like.
A few representative engagements, each an investigation into a technical reality: a production AI system, a vendor's claims, an architecture's assumptions, a leadership team's picture of the technology. The range runs from a boardroom to a production codebase.
Correct implementation, wrong operating point.
I went into a product built on mathematics from four different fields, chaotic maps, strange attractors, fractals, cellular automata, and came back with a single sentence that described what was wrong with all of it: correct implementation, wrong operating point. The silent defects were the proof that the descent happened; the one-sentence class was the point.
What the technology actually does
A leadership team was set to commit budget to an AI plan assembled from vendor decks. I gave them an independent read of what the technology can and can't actually do, in terms they could act on, before the spend.
An accurate model of their own tools
A team had wired an AI tool into a production workflow and couldn't say where to trust it. I mapped where it was reliable and where it wasn't, so they leaned on it where it earned trust and stopped where it didn't.
A roadmap that assumed too much
A proposed roadmap assumed capabilities the models don't reliably have. Tracing the assumptions back to what is actually known reclassified the hard part and reordered the plan around what would work.
The product, not the pitch
Ahead of a major purchase, a team wanted a vendor's performance claims checked against evidence. I verified and reproduced what could be, so the decision rested on what the product does, not what the deck says.
Three depths, one investigation.
All three are the same scientific investigation at different depths: go down into the technology, then come back up with an evidence-based account a team can act on. That covers a boardroom and a production codebase alike. Start wherever the question is.
Executive technical briefings
What the state of the art actually is, what it does, and what it means for this organization, delivered so an executive team can act on it. Includes board sessions and conference and internal-event speaking.
- executive briefings
- board sessions
- conference keynotes
- internal events
Independent AI and technology advisory
AI strategy, architecture review, and build-vs-buy, judged against how these systems actually behave. Includes whether a proposed direction rests on sound technical assumptions, and how far the tools your teams already use deserve to be trusted.
- AI strategy
- architecture review
- build vs. buy
- technical assumptions
Technical due diligence and systems diagnosis
Going all the way into a system, a stack, a pipeline, or a set of technical claims, and returning an evidence-based account of what it does, where it fails, and why. Delivered as written findings.
- a vendor's claims
- a proposed architecture
- an AI pipeline
- an acquired stack
- the production system
I'm an independent scientist and technical advisor. I come in from the outside with no stake in the existing explanation, architecture, or proposed solution. My job is to determine what is actually happening.
I diagnose complex technical systems by reconstructing how they actually work, identifying what kind of system they are, and translating the result into decisions executives and engineers can act on together. The critical step is classification: identifying what class of system or problem you're actually dealing with, which properties matter, and what established body of knowledge applies to it. A problem that is classified correctly becomes much easier to diagnose.
The second advantage is independence. I have nothing to sell downstream and nothing to gain from the answer being reassuring. I'm there to establish the technical reality and give you an account of it you can act on. Finding what's broken along the way is often just a byproduct.
Independent scientist and technical advisor.
Enterprise delivery for Fortune 500s over many years.
Author of Discovered, Not Designed (2024).
Research published on Zenodo.
Notes2Tree makes structure visible.
Notes2Tree takes your material: notes, meeting transcripts, backlogs, code…and turns it into representations you can reason with. See hierarchy, sequence, process, causality, argument, and relationships that are difficult to see in the raw material.
Different views expose different properties of the same system, helping you understand how it works, diagnose where problems lie, and decide what to investigate next.