Final project: the instrument
The semester's artefact — your own race simulator and the wall you designed for it, submitted with the limits you are willing to declare
Due: 28 May 2027 · Weight: 25%
The brief#
Twelve weeks to build something you are willing to trust in front of the cohort, and one document saying where it stops.
The instrument is your own race simulator, built across the semester and due at the end of week 12, after the last lab. It takes the state of a race and returns a recommendation — box now or box later, and what goes on the car — along with how sure it is. The wall is the display you designed for it in week 11: the surface you will actually read while the race is happening.
They are submitted together and marked together, and never marked separately. Marking them apart would invite a display worth looking at in front of a model not worth trusting, and this course puts the model first.
You do not accrete this. The labs left you eleven separate codebases and no single tool for the instrument to be an extension of, so the instrument is new code that combines what they taught and goes further than any of them did.
Building across the semester#
The brief and the model-to-wall interface contract are available from the start of teaching. The course advises beginning integration after week 4, once you can turn a race state into a legal strategy set. The contract accepts a race-state input and returns legal candidate strategies with distributions over finishing positions and the derived situation quantities named in week 11. It also returns the recommendation, its confidence and the stated objective. Week 11’s harness and the final wall read the same output schema.
The following stages are advice, not deadlines, submissions or marking criteria:
- after week 4, connect a race-state input to the legal candidates your model can evaluate
- after weeks 6 and 9, add responding rivals and finishing-position distributions to those candidates
- after week 10, state the objective that ranks them; after week 11, run the unchanged wall configuration against the shared schema
- after week 12, use the blank audit plan on your own probabilities and finish your own domain of validity
Useful private checks are that every returned strategy is legal, every position distribution sums to one, and the week 11 harness can read the recommendation, confidence and objective. These checks are not assessed work. No scaffold or implementation architecture is prescribed: the instrument remains independent new code.
The declared domain of validity#
One document, submitted with the instrument: the conditions under which your instrument should not be believed. After the Week 12 lab, apply its audit method and blank plan to your own instrument and finish this document before Friday. The lab teaches the last method you need; its assessed output remains the supplied-model audit and supplied-model domain rather than this document.
Record both general limitations and actionable limits. A general limitation can be honest and important even when nobody could recognise it during a race. An actionable limit names a clear, observable condition that could be recognised from evidence available when a call is due. It does not have to be an executable predicate.
Only an actionable limit can license leaving the instrument during the race, and declaration alone is not enough. The limit must be in this submitted document, and the departure record must preserve the evidence available at the call showing that its condition applied. That evidence sits beside the call, timestamp, standing recommendation and limit citation. A limit discovered after the race cannot change the race mark. An unsupported departure can lose race conduct marks; honest, rigorous analysis can still earn defence marks without retrospectively justifying it. So it is worth writing honestly rather than narrowly — a domain that claims everything protects nothing, and one that disclaims everything says the instrument is not worth running.
What it is not required to do#
A twelve-week deliverable reads as unbounded unless somebody bounds it.
- It is not required to be right. It is required to say where it is wrong, and to be right about that.
- It is not required to generalise past the race weekend it is given: one circuit, one set of regulations, the grid you are given.
- It is not required to be a product. No installer and no packaging — a marker needs one documented command and the environment above.
- The wall is not required to be beautiful. It is required to make a correct call possible in the seconds the race gives you, which is the thing week 11’s lab measured — and you submit that measurement with it. A wall nobody has timed is a claim, and this course does not mark claims.
Your instrument publishes the same output schema week 11’s harness used, so the configuration you wrote in that lab runs against your own model unchanged. The environment is fixed for everyone (the screens, the setup, the seat) and so is the interface between a model and a wall. What varies is what you put where.
What you submit#
The codebase, the wall’s configuration with its measured latency and correctness, and the declared domain of validity, as one submission.
A marker runs it before reading it. If the same inputs give two different recommendations, the log your race produces cannot be read against the instrument that produced it, and the race has nothing to mark.
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- it runs from a clean checkout in the pit wall environment, from one documented command
- the same inputs produce the same recommendation twice
- a declared domain of validity is submitted with it, naming the conditions under which it should not be believed
- the wall is submitted as a configuration that runs on the pit wall screens, not as a picture of one
- the wall is submitted with the latency and correctness measured for it, not with a claim about it
How it is marked
| Criterion | Weight |
|---|---|
| Model fitness — the assumptions are named, the omissions are priced, and the hard constraints come from the regulations | 35% |
| Calibration and declared limits — the stated probabilities occur at their stated rate, and the domain of validity is honest about where they do not | 25% |
| The wall — a correct call is possible from it inside the time the race allows | 25% |
| The objective — what the instrument optimises for, and whose interest that serves | 15% |
A marker runs the instrument before reading anything written about it, so every criterion is judged first on behaviour. Model fitness is read on the assumptions you named and the omissions you priced: a simplification stated with what it costs is evidence, and the same simplification found by a marker is a gap. Hard constraints are checked against the regulations rather than against taste, so a strategy your model permits and the rulebook does not is a fitness failure however well it performs.
Calibration and declared limits are judged together, because a stated probability is worth what its audit says it is. Convincing evidence is week 12’s method turned on your own instrument: bins, counts, observed frequencies, and a domain naming the conditions where your own numbers did not hold. A domain that claims everything and one that disclaims everything both score low, for opposite reasons. The wall is marked on the latency and correctness you measured for it, and the objective criterion is satisfied by naming what the instrument serves — one that optimises something it never states is marked on what it actually optimises.