The Ontology Track:
automate the right work, and know what it costs
In-person workshops for founders, department heads, operations managers and engineers. The through-line across all three formats is judgement: choosing the work that is worth automating, building it so its output can be checked, and being able to say what a year of it will cost before you commit.
What you'll be able to do by the end of the track
- →Sort your team's work into what to automate, what to assist, and what to leave alone.
- →Turn invoices, contracts and transcripts into structured records you can audit.
- →Process commercially sensitive files without them leaving your own hardware.
- →Cost a workflow per request and per year, and then bring that number down.
- →Ground an assistant in your own policies and databases, with citations.
- →Attack your own pipeline for injection and data leakage, and close what opens.
Founders, operations leads and engineers
In the room, on your own real documents
1 day decide · 2 days build · 3 days ship
One day: decide what is actually worth building
6–7 hours, in person
For a leadership team that has been told to "do something with AI" and wants to make that decision on evidence. The day ends with a ranked list of your own processes and a working assistant built on your own documents — not a strategy deck.
This is a complete workshop, not a taster. It is the format we run most often, and for most teams it is the right one — the decisions you make in this day are the ones that determine whether anything built later is worth it. The longer formats add technical skills; they do not improve on this day.
You will leave able to
- →Separate what these systems genuinely do from what the marketing claims.
- →Rank your own processes by hours saved against risk if the output is wrong.
- →Write instructions precise enough that two colleagues get the same result.
- →Pull structured fields out of a messy invoice, contract or meeting transcript.
- →Recognise a prompt injection attempt and say how your data could leak.
- →Stand up an assistant that answers from your own procedures.
How the day runs
Morning — what the technology is, minus the hype
- What is actually happening Prediction, not retrieval or reasoning about facts. Why a general model invents specifics about your business unless you put them in front of it.
- Instructions as business logic Treating a prompt the way you'd treat a procedure: defined sections, an explicit role, worked examples, and stated limits — so the output is repeatable by someone else.
- Lab 1 · whiteboard, whole team What to automate, assist, or leave alone Your real processes go on the board and get placed by volume, hours consumed, and what breaks if the answer is wrong. Most teams are surprised by which quadrant their favourite idea lands in.
Afternoon — on your own documents
- Lab 2 Messy documents into a table Real invoices, a vendor contract and a rambling call transcript, turned into structured rows — including the part where you check what the extraction quietly got wrong.
- Lab 3 Watching it fail on purpose Prompt injection hidden inside a document, confidential text arriving somewhere it shouldn't, and a first draft of what your organisation's rules should say.
- Closing build An assistant loaded with your own procedures, answering questions your staff actually ask.
And you take away
Grounded in documents you brought, working before you leave the room.
Your processes, placed and ordered, with the next one to attempt clearly identified.
What staff may use, on what data, with which checks — written by the people who'll enforce it.
Two days: build it, then work out what it costs
12–14 hours over two days
The step from a promising demo to something you could put in front of the business. Two skills carry the weight: making output machine-checkable, and doing the arithmetic that decides whether running it is affordable at your volume.
You will leave able to
- →Everything in the one-day format, plus the following.
- →Run a batch of files through a model from the command line, unattended.
- →Process sensitive data on your own hardware, with nothing sent outside.
- →Demand a fixed output shape and fail loudly when it doesn't arrive.
- →Calculate cost per request, then cut it with caching and model routing.
- →Test your own pipeline for injection, leakage and silent drift.
How the two days run
Day one — foundations, then the terminal
- The one-day material, compressed Mechanics, prompting standards and where models differ — quickly, because the afternoon needs the time.
-
A terminal from a cold start
Environment variables and secrets that stay out of your code, plus joining commands into a pipeline
(
cat | llm | jq). - Running a model on your own hardware Open-weight models on a laptop, for the spreadsheets and contracts that are not allowed to leave.
- Lab 1 Ten thousand lines into one report A pipeline over real server logs and an exported CRM dump that finds the anomalies and writes them up — the job someone currently does with a spreadsheet on Friday afternoon.
Day two — scripts, arithmetic and attacks
- Output another system can consume Declaring the shape you need, validating what comes back, and handling the case where it doesn't — because downstream systems cannot read an apology.
- Lab 2 What does one request cost? Count the tokens, price them at today's rates, multiply by your real volume. Then restructure the prompt so the fixed part is cached, and send routine work to a cheaper model. Same task, different bill.
- Lab 3 Attack the thing you just built Instructions buried in an uploaded document, attempts to make the pipeline emit data it holds, and checking whether yesterday's output still matches today's.
- Closing demo Show the room the tool, the cost model, and the attack that worked before you fixed it.
And you take away
Parses your own messy files, built on your data, running on your machine.
Per request and per year, with the caching and routing savings shown as arithmetic.
Schema-checked output with the failure paths written, not assumed.
Three days: ship a prototype the business can judge
18–21 hours over three days
Two days of labs, then a full day building in teams. The added skills over the two-day format are grounding in your own systems — documents and databases, with citations — and routing work between models so the result is affordable at volume.
You will leave able to
- →Everything in the two-day format, plus the following.
- →Let a model call your own functions and query your own database.
- →Index a document library so answers come with a source attached.
- →Route each request to the cheapest model that can actually handle it.
- →Log what the system did in a form an auditor would accept.
- →Hand your prototype to a hostile tester and survive it.
How the three days run
APIs and tool use
Calling models from code, letting them call your functions, and running coding agents from the terminal — plus a development setup on every laptop.
Grounding and routing
Retrieval over your documents and databases, tiered routing between small and frontier models, and the audit logging that makes the whole thing defensible.
Team build and demonstrations
One day, one team, one working prototype — cross-tested by another team, then demonstrated to judges who use it themselves.
Day three in detail
Each brief is a real operational bottleneck rather than a product idea, because a narrow thing that runs teaches more in a day than a broad thing that doesn't.
Choose one brief
Read a tender document, pull out the compliance requirements, and draft answers grounded in your own past work — each one citing where it came from.
Turn discovery calls, intake forms and PDFs into consistent client records, with the fields a human still has to confirm flagged rather than guessed.
Answer staff questions from private policies and a live database, respecting who is allowed to see what, and citing the source every time.
The shape of the day
What the judges are looking for
Published in advance, because the point is to build towards it — not to guess.
And you take away
Against a real bottleneck in your own operation, demonstrated live.
Source, retrieval, caching configuration and tests — yours to continue.
Scored on value, running cost and robustness by judges from industry.
Completion of the three-day programme, listing what you actually built.
A single day built from across the formats
Every lab above is self-contained, so a day does not have to come from one format. A common combination is the process-ranking whiteboard and document extraction from day one, then the cost arithmetic from the two-day format — because that is usually the conversation the executive team actually needs.
It works the other way too: a technical team can skip the strategy morning and start at the terminal. Tell us who will be in the room and what you want them able to do afterwards.
The two things most teams have never done
Demanding a fixed output shape, and pricing a request before building on it. Both are Lab 2 on day two.
Ask for a shape, not a paragraph
Declaring the schema turns "did it get the total right?" into something a test can answer. Zero temperature because this is extraction, not writing.
What a request costs, and how to change it
Three levers, in the order we teach them. The figures below are the shape of the answer — you compute yours against current published prices on the day, because they move.
The habit that matters: do this before you build, not after the first invoice arrives.