Teaching · Interactive
Twenty interactive topics arguing that in regulated analytics the model is the cheap part, and that the hard problems sit downstream of it. Each one renders as a molecule, where atoms are concepts and bonds are dependency and control relationships.
Most AI curricula stop where the interesting part starts. Prompting, retrieval, agents, then a closing slide about responsible use. That ordering is fine if the goal is to build a demo. It is close to useless if the goal is to put a system into a bank, because in a bank the model is the cheap part and everything around it is the expensive part.
The series makes a specific claim: in regulated analytics, the difficulty is downstream of the model. Who owns the definition of the metric the system just quoted. Which dataset was certified and by whom. Who approves an action and on what evidence. What it costs per thousand queries and which budget absorbs that. How you explain any of it to an executive who has to sign. Twenty topics give those questions the same weight as the model itself, because that is the weight they carry in practice.
It runs from foundations into the parts that usually go missing. Fundamentals, structured outputs and JSON contracts, context engineering, retrieval and its limits, evaluation. Then risk and governance, prompt injection, tool calling, deterministic execution. Then the layer almost nobody teaches: data governance in the BI stack, the semantic layer and metric registry, orchestration, observability, token economics, human-in-the-loop design, product management, enterprise architecture, local and open-source deployment, and communicating AI systems to the people who authorise them.
Where I have a view, the series takes a position rather than surveying options. Retrieval is treated as a policy question before a similarity question. Evaluation is treated as a release gate rather than a report. Cost is treated as an architectural constraint rather than a finance concern. Those are arguments, and they are the ones I would defend in a design review.
Each topic renders as a 3D molecule. Atoms are concepts, bonds encode whether one concept depends on or governs another. That is not decoration. The thing that makes governed orchestration hard to teach is precisely the structure, which concept constrains which, and prose flattens exactly that. Selecting an atom, reading it, answering a recall check and marking it learned is slower than skimming, which is the point.
The twenty pages are not hand-authored. A generator assembles them from a shared engine template and one typed data module per topic, so adding or correcting a topic means editing structured data rather than copy-pasting HTML. That is the only way twenty pages stay consistent once you are past the first five.
Every build runs integrity checks before a page ships: brace balance, atom uniqueness, bond integrity, learning-path continuity, required keys, category coverage and a JavaScript syntax pass. A series arguing that structured claims should be validated structurally would look silly not validating itself. Sixteen of the twenty topics are built.
This is where I put the domain view in writing. The code on this site shows I can build the thing; the series shows I know which parts of it matter in a regulated institution and why, which is the half that is harder to demonstrate from a repository. Teaching a system is also the honest test of understanding it, and the gaps show up fast. The pages double as the surface I drive with the projector and gesture rig in the Lab, so a topic can be walked through on a wall by hand rather than clicked at a desk.