Twenty years teaching people to think creatively — first in person, now at platform scale.

Built as an argument, not just a demo: that personalization doesn't require harvesting personal data. Visitors choose a persona and a Claude-powered guide adapts tone and depth accordingly, while every interaction is logged as anonymous xAPI statements — the same measurement discipline he brings to L&D, pointed at his own portfolio this time. React front end, a serverless API streaming Claude responses, Claude as production partner throughout.

The core design bet: an adaptive system should never assert more confidence than its evidence supports, and the learner should always be able to see and challenge its reasoning. The live inspector shows the exact behavioral signals — pacing, hesitation, review patterns — that produced each inferred state, before any adaptation happens. Built solo with Claude as production partner across the full stack: React front end, an xAPI event pipeline into a Learning Record Store, and an inference layer translating raw behavior into pedagogical decisions.

Building the prototype opened onto a bigger thesis: most "adaptive" tutors reset with every session. The interesting problem, especially for corporate L&D, is a persistent adaptive tutor — a learner-tutor relationship that builds a profile over time instead of starting cold each time someone opens it. That thesis split into three research threads he's kept developing past the prototype itself.

Thread A — Persistent Adaptive Tutor. Cognitive load is the easier half to infer: pacing, error rates, time-to-completion, how often someone asks for clarification. The harder half is behavioral and contextual — when a person learns best, whether they need a concrete example before an abstraction or the reverse, whether they thrive on productive struggle or get frustrated by it. That's the same territory Josh Bersin's Dynamic Enablement model points at, and it's where a persistent profile actually earns its keep.

Thread B — Privacy-Preserving Adaptive Tutoring. Enterprise data-minimization policy is a real design constraint, not a footnote: a tutor built for a corporate context has to infer learning style and cognitive load from implicit behavioral signals, with minimal explicit data collection. Most of the literature treats privacy and personalization as a trade-off to be balanced — he'd argue that's a genuine research gap, not a settled question. The technical path runs through federated learning (FedProx has shown gains over FedAvg specifically on heterogeneous student data), differential privacy, on-device data locality, and explainability techniques that keep the inference auditable instead of opaque.

Thread C — Intent-Aware Learning Design. Not every question deserves the same kind of answer. Sometimes a learner needs a fast, direct answer to finish a task under deadline pressure; sometimes what they actually need is for the knowledge to stick. The system distinguishes a direct-answer mode from a retrieval-practice mode, and flags when a pattern of repeated quick-answer requests might itself be the signal that deeper learning — not just task completion — is what's needed.

Supporting research runs alongside all three threads: NSF-funded work out of AI-ALOE at Georgia Tech, RCT evidence that AI tutoring can outperform traditional instruction in some studies, and federated learning as the concrete technical path for the privacy-preserving angle.

Where the Adaptive Tutor prototype proved the architecture, this is the architecture put to real content: ten illustrated pages, in-story prompts, and a discussion phase that evaluates the learner's own reading against a rubric — not a quiz, a Socratic companion. The system prompt is built server-side from the learner's page, mode, and intent rather than trusting the client with free-form prompt text, so the tutor endpoint can only ever produce this lesson, nothing else.

All of the copy here lives in a single file, content.md, in a tiny key:value format anyone could edit. A build script — plain Node, built-in modules only, zero npm packages — parses it and fills a template to produce the page, and the generated HTML is never touched by hand. A GitHub Action rebuilds it on every push that changes the content, template, or script, so the source and the live site can't drift apart. Editing the site is editing markdown.

The design decision that matters most is the failure mode. After the build fills the template, it scans the output for any token it failed to replace — the fingerprint of a typo in the content or the template — and if it finds one, it prints the exact list and refuses to build. That was the deliberate middle path: not a heavyweight CMS, not a "just don't typo it" honor system, but a lightweight pipeline with a loud quality gate. It's the same instinct as the content standards and measurement systems elsewhere on this page, scaled down to a personal site — if content is going to be edited safely, by other people or by future Matthew, the system has to catch mistakes before readers do.

The standard wasn't a style guide — it was a small set of testable questions any team could ask before publishing, like whether the content respects the learner's time and whether anyone could actually measure if it worked. Teams that could answer those honestly got out of his way; teams that couldn't got coaching, not a rejection. That's the difference between governing quality and just gatekeeping it.

Some of that coaching went past editorial notes and into the tools themselves — a multi-session training series he ran taught instructional designers custom CSS and HTML so they could shape content design directly, not just prose. It's the kind of feedback that earned him a reputation for pursuing "product excellence without overcomplicating user flows," and for giving notes — fearlessly, by one colleague's account — that made the work better even when they weren't easy to hear.

Self-serve only works if "good enough to publish" means the same thing to everyone doing the publishing. The system paired lightweight editorial review with clear authoring guardrails so teams could move at their own pace without the platform turning into a pile of unreviewed content. The goal was never to slow teams down — it was to make the fast path and the good path the same path.

Some of that governance work meant translating messier real-world process into the standard, too — writing acceptance criteria and refining backlog tickets, and running the refinement and planning sessions that came with the platform team's shift to Agile, including the forming-storming-norming arc that shift brought to a distributed org. He also led a third-party content-integration effort end to end — design through legal and privacy review to launch — proving the governance model held up against an external platform, not just internally authored content.

The instinct here was the same one behind the content standards and measurement work elsewhere on this page — don't just react to a problem, build the system that catches the next one. He recruited testers across regions to capture real-world performance data, then worked directly with engineering to turn that data into a justified case for where to spend fix effort. The process outlived the initial fire drill, too: it became a recurring practice, run again in later cycles to keep pace as the platform kept growing.

The dashboard itself was never the point — the loop was. Feedback rolled up alongside adoption and support signals on a regular cadence, then went back to the teams that made the content and into what got built next. Content that scored well on completion but poorly on "did this actually help" was a signal to redesign, not a metric to celebrate.

That same instinct scaled up into a bigger initiative: leading the strategy behind a data-layer and LMS migration, aligning stakeholders across teams toward consolidating learning data into a single enterprise data warehouse. A colleague later credited a set of his slides with "effectively communicating the vision of consolidating learning data" org-wide — the same measurement discipline, aimed at the data layer itself rather than just the dashboard on top of it. That migration also had to hold up under real privacy constraints, not just functional ones — building data handling that stayed compliant across regulated international markets from the start, rather than retrofitting compliance in later. He's brought that same research-through-delivery approach to a manager-facing dashboard, owning it end to end, and to UX research that directly shaped a shipped platform capability for tracking skills and proficiency levels.

That same measurement discipline is what this site demonstrates in miniature. Every visitor interaction here is logged as anonymous xAPI statements to a live Learning Record Store and read back onto the page in the Live insights section below — the same feedback loop, small enough to watch run in real time.

The old process was white-glove by brute force: several hours of live, one-on-one training walking each new provider through the system, while the backend onboarding ran at least a week in parallel. The replacement made the entire path self-service, anchored to weekly office hours, with a single 30-minute one-to-one preserved for each new team — the white-glove touch kept where it earns its keep, not spread across the whole process.

The other deliberate move: from day one, new teams are pointed at each other and at the more experienced members of the community, so the platform team stopped being the only place answers lived. Front-loading the standards and platform mechanics meant teams spent their early weeks building content, not discovering the system by trial and error.

What started as a one-off session turned into two years of monthly programming because the format worked — give people real tools and real art, get out of the way, and let looking closely turn into making something. It's the same instinct behind everything else on this page — the best teaching moments are the ones where the "teacher" mostly sets up the conditions and steps back.

Epistemology in particular — the question of how we actually know something, versus how we merely feel confident about it — turns out to be the same question underneath most of his measurement work. A completion rate tells you someone finished; it doesn't tell you they understood. The marathon detail is the tell here: nobody assigns the Republic to a training plan. Reading philosophy for its own sake, with no professional agenda, is what keeps that distinction sharp instead of theoretical.

That reading habit showed up at work too: he led Apple's worldwide rollout of training on the philosophical considerations of AI, built to be accessible to every employee rather than gated behind technical teams — the rare case where the unassigned reading turned out to be exactly the preparation the job needed.

The pull was never really about physics specifically — it's wanting to know how the thing in front of him works, whether that's a combustion engine, a watch movement, or one of his own 3D prints warping off the bed until he figures out why. Quantum mechanics was just the hardest version of that same question, and the best test case yet for explaining something genuinely hard well.

What kept him in it was watching great science communicators solve the exact problem he solves for a living: making complex ideas stick. His favorites — Space Time, Kurzgesagt, and ScienceClic — all lean on the same trick: ground the physics in the history of how the thinking evolved, and keep the confusion and awe in instead of editing it out.

The pattern he keeps noticing across the channels he returns to: they don't sand the confusion out of the story. They show you the specific historical moment where people were genuinely stuck, let you feel the size of the problem, and only then hand you the resolution. Understanding sticks better once you've felt the weight of the question it's answering — the same argument he'd make for teaching almost anything else, not just physics.

The newest version of the itch is home automation, right at the point where it's starting to absorb LLMs. A house that used to run on if-this-then-that rules is starting to run on models that reason about what you probably want, and he's tinkering with that shift at home — the first hobby that's converged with what he does for a living.