The 5 Core Pillars:
what you learn, and why it holds up
Every format in both tracks teaches the same five skills at a different depth. Each one is written below as what you will be able to do afterwards, not as a list of topics we mention. If a pillar's outcomes already describe you, skip that section — the tracks tell you which formats go deepest on which pillars.
Read a model honestly
A language model predicts likely next tokens. It does not look things up, check its work, or know when it is wrong. Almost every bad AI decision we see traces back to not believing that sentence.
By the end of this pillar you can
- →Explain in plain language what happened between your question and the answer.
- →Say in advance which parts of a task the model will probably get wrong.
- →Read a model's specifications — context window, price, modality — and know what they cost you in practice.
- →Choose between a large frontier model and a small local one for a given job, and defend the choice.
The ideas behind those outcomes
Models read tokens (roughly ¾ of a word). Punctuation, whitespace and formatting change how your text is split — which is why the same question, reformatted, gets a different answer.
The working memory limit, and the more useful fact underneath it: recall degrades in the middle of long documents well before you hit the stated ceiling.
Why temperature 0 is the right default for extraction and the wrong one for
drafting, and why "deterministic" still isn't a guarantee.
Text as coordinates: how similarity search actually works, and why it retrieves things that look related but answer a different question.
What you actually buy with a frontier model, and the large class of routine work where a small model that runs on your own laptop is the better answer.
Fluent, well-formatted and completely wrong is the default failure mode. Spotting it is a learned skill, and it is the one we drill first.
Direct it in the apps
The chat interfaces most people already have are capable of far more than conversation. The skill is writing instructions that survive a long session and produce the same shape of answer every time.
By the end of this pillar you can
- →Write a system prompt that still behaves the way you intended twenty turns later.
- →Constrain a model so it refuses to do the thing you don't want — and check that the constraint holds.
- →Set up a reusable workspace with your own reference documents and rules pinned to it.
- →Tell when a task needs a slow reasoning model and when a fast one is enough.
The ideas behind those outcomes
Structure over eloquence
Delimited sections, an explicit role, worked examples, and stated limits. A plain prompt with structure beats an elaborate one without it, every time.
Withholding as a technique
Personas that refuse to hand over the answer, ask one diagnostic question at a time, and make the person do the thinking. The core move of the Intuition track.
Workspaces, not one-off chats
Persistent projects with a fixed corpus, pinned instructions and house formatting rules, so the result is repeatable by someone who isn't you.
Run it from the terminal
A browser handles one document at a time. The terminal handles four hundred, on a schedule, without sending any of them to someone else's server. This is the step where AI stops being a conversation and starts being a tool.
By the end of this pillar you can
- →Pipe a file through a model from the command line and get structured output back.
- →Run a model entirely on your own laptop, with nothing leaving the room.
- →Keep API keys out of your scripts, your repository and your shell history.
- →Turn a task you did by hand a hundred times into a command you run once.
The ideas behind those outcomes
A model is just another pipe
Text in, text out — so it composes with every tool you already have. Read a file, send it through a model, filter the result, write it somewhere.
Local models, no egress
Open-weight models running on ordinary laptop hardware. Slower and less capable than the frontier — and the only option when the data legally cannot leave the building.
Ground it in your own work
Demos use clean data. Your data is scanned PDFs, contradictory syllabus documents, support logs and marking criteria. This pillar is about the gap between the two, and how to close it.
By the end of this pillar you can
- →Turn a pile of messy documents into a structured table you can actually check.
- →Force machine-checkable output instead of prose, and fail loudly when it doesn't arrive.
- →Ground answers in your own sources so every claim can be traced back to a document.
- →Score a system's output against a rubric rather than judging it by eye.
The ideas behind those outcomes
Splitting, chunking and extracting from tables, scans and contracts — including how to tell when the extraction quietly dropped a row.
When something downstream has to read the output, prose is a liability. Declaring a schema and validating against it turns a maybe into a check.
Answering only from an approved set of documents — a syllabus, a policy library, a regulation — with the source attached to every claim.
Blind, multi-grader scoring harnesses — the same method behind our public Ontology Eval board.
Account for cost and risk
A prototype that works is not a system you can afford to run or safely deploy. This pillar is the arithmetic and the adversarial thinking that decide whether the thing you built survives contact with a real budget and a real user.
By the end of this pillar you can
- →Work out what one request costs, and what a year of them costs, before you commit.
- →Bring that cost down by caching the fixed part of a prompt and routing routine work to smaller models.
- →Attack your own system — injection, leakage, jailbreaks — and fix what gives way.
- →Argue clearly for what should stay human, and say why.
The ideas behind those outcomes
Counting tokens in and out, pricing them at current rates, and multiplying by real volume. Most teams have never once done this sum.
Structuring a prompt so its fixed prefix can be cached, and sending high-volume routine work to a cheaper model while the frontier handles the genuinely hard cases.
Citations, narrow scopes and verification steps — so a wrong answer is caught by the system rather than by the person who trusted it.
Prompt injection, indirect injection through retrieved documents, data exfiltration and jailbreaks — practised as an attacker, not read about.
Retention settings, tenant isolation and the boundaries your organisation is actually bound by — plus when the honest answer is "run it locally".
Automating a task can quietly remove the ability to do it. Deciding which of those trades are worth making is part of the engineering, not separate from it.