Most technical advisors execute the approach a client brings them. My work is one level up: taking a problem down to its technical substrate and back up to the decision that depends on it, and finding where the chain breaks.
Fractional CTO, technical architect, and advisory engagements for teams shipping AI-adjacent products. Twenty-two years designing commercial systems software, twelve issued US patents, a 2025 PhD from UBC, and active 2026 research on LLM reliability: the depth to evaluate a technical claim at the substrate level rather than repeat it at the marketing level.
How I work
Every technical approach rests on an assumption its designers have stopped seeing as an assumption. Most of those assumptions are sound. The work is finding the one that is both load-bearing and wrong, then showing what should replace it.
-
Flip the burden of proof
Most teams treat the default approach as free, the thing that needs no justification. I treat it as a claim that has to earn its place. When the default cannot justify itself, the alternative is live and worth the cost of exploring.
-
Find the assumption that is load-bearing and fragile
Questioning every assumption is exhausting and obstructive. The skill is judgment. Most assumptions are load-bearing and sound, or fragile and irrelevant; the rare valuable case is the one doing real work that would not survive examination. Finding those quickly, and leaving the rest alone, is half the value.
-
Build and demonstrate the alternative
A question is cheap. Someone who only questions is a gadfly, and reopening a settled question without resolving it is just obstruction. The carry-through is the product: explore the alternative, build it, and demonstrate why it removes the problem the default created, in terms the stakeholder who has to accept it can verify, whether that is a board, a regulator, or an acquirer.
What that looks like in practice
Consider a recent case. A client arrived with a pre-framed solution: tell us how to use SHAP and LIME to explain our model's decisions. The question they asked was not the question they had. SHAP and LIME are post-hoc explanation methods, and post-hoc explanation cannot catch what a regulated decision system needs to catch.
The better frame already existed in the research literature: Cynthia Rudin's work on models that are interpretable by construction, and the Rashomon sets that make such models practical. The move from there was to turn that research insight into an engineering path, how to build a solution shaped that way, and then to carry it to the people who would have to accept it: how do you prove the new approach is better, and how do you convince a regulator.
That last step is the rare one. Most advisors who can recognize the wrong frame and find the right one stop before the question of proof. The proof is the deliverable.
Where this applies
Technical due diligence, architecture review, and AI governance are not three separate skills. They are the same move applied to three different objects.
Technical due diligence
The move applied to a company's claims. For investors and acquirers evaluating an AI-driven company: does the technology do what the deck says, and would the claim survive an expert's examination. Training-data provenance, hallucination and reliability assessment, agent behavior under adversarial conditions, deployment architecture.
Architecture review
The move applied to a system's design. For engineering teams: where does the current or proposed architecture rest on an assumption that will not hold at scale, under failure, or against the correctness requirements the product actually has. Storage, performance, concurrency, and scaling concerns.
AI governance
The move applied to a model's compliance. For teams deploying AI into regulated decisions: is the chosen approach one you can defend to a regulator, and if not, what is, and how would you prove it. Interpretability, explainability, and the gap between the two.
Fractional CTO and advisory
Ongoing technical direction for small teams shipping AI-adjacent products without a senior systems person in the room. Build-versus-buy, vendor evaluation, design and code review, and expert technical review for non-technical leadership making decisions that are hard to reverse.
Track record
Twenty-two years at OSR Open Systems Resources, from 1994 to 2016, as Consulting Partner and Vice-President. OSR is a systems-software specialty consultancy; during that tenure its client base included IBM, Microsoft, Cisco, Amazon, HP, Dell, Intel, EMC, NetApp, Seagate, and over 160 other technology companies. Several products OSR still ships in 2026 are based on technical work led there, including the File Encryption Solution Framework and the isolation-filter architecture behind transparent file encryption, compression, and streaming delivery.
That work has an unusually long reach. Microsoft's App-V product ran on a filter driver designed at OSR for more than a decade before Microsoft built its own replacement, and that replacement, the filter shipped in current Windows, implements a primitive form of the same pattern. It now underpins Windows containers and OneDrive. Designing infrastructure that is still load-bearing two decades later is the throughline: the Episode file system, written between 1989 and 1993 at Transarc, remains in production today as the POSIX file system of IBM's z/OS.
Since 2016 the work has run through wamason.com LLC: AI-systems architecture, fractional CTO engagements, and technical due diligence. A fixed-term 2020 research engagement at Microsoft Research Cambridge produced a discrete-event simulation of holographic storage wear that contributed to a 2025 ACM Transactions on Storage paper. Technical advisor to BitRaider on streaming game delivery since 2011.
Areas of competence
Transferring expertise, not just deploying it
Expertise that cannot be transferred is a single point of failure. Across the OSR years I built and taught the commercial curriculum on Windows systems internals: Developing Windows File Systems, Developing Windows File System Mini-Filters, Advanced Windows Driver Development, Windows Internals from source, Porting Windows Drivers to 64-bit, and Windows Kernel Debugging, taught to client engineers worldwide. That continues today in graduate teaching at UBC and Georgia Tech. An engagement should leave a team able to carry the work forward, not dependent on the advisor who scoped it.
Engagement model
Engagements take whichever shape fits the problem.
A defined question with a defined deliverable: a due-diligence assessment, an architecture review, a written technical opinion.
Continuous technical direction for a team that needs a senior systems voice in the room but not a full-time hire.
A bounded conversation for a specific decision, with no ongoing commitment on either side.
Rates depend on scope and are set per engagement. The best-fit work is where a technical decision is hard to reverse and the cost of getting it wrong is high. Where a problem falls outside my competence, or where I would have a conflict, I will say so and decline.
Working together
The first conversation is free and exists to find out whether the problem is one I can genuinely help with.