Turnaround

2026

Constraint Solving · Independent Proof · The Week Sheet

The showtime grid is a constraint problem wearing a spreadsheet. Turnaround takes the house, the slate and the distributors’ terms, and builds the week — every session on every screen — with a constraint solver. Then a checker that never imports the solver re-derives every hard term from the brief and proves the grid again.

Role
Designer & Engineer
Stack
Python · OR-Tools CP-SAT · Hypothesis
Methods
Constraint modelling, unsatisfiable cores, independent verification, property testing, measured benchmarks
Scope
146 tests · 20 decision records · published on PyPI
The Regent, one Thursday: three screens and five titles, solved to proven optimal in 4.3 seconds
The Problem

The grid is one they can live with, not one they can prove

Every week, in every cinema, someone builds the grid by hand: which title plays on which screen, and when. They hold a set of rules nobody has written in one place. A screen holds one thing at a time. The room needs twenty minutes between features, and the floor can turn two rooms at once, not five. Two starts too close together and the lobby can’t cope. The distributor wants three shows a day, one in prime, its own screen through Sunday.

The grid they arrive at is one they can live with. The first anyone hears of a missed term is the distributor’s report.

Two readings that agree are evidence; one is an assertion.
The Answer Was No

The hero is the word INFEASIBLE

Ask for an impossible week and Turnaround doesn’t return a quietly worse one. It says no, and names the terms that make it impossible — a minimal set. Every term is an assumption literal; CP-SAT returns an unsatisfiable core over them, and a deletion pass shrinks the core until every term left in it is necessary. A term is never relaxed silently. If you want a grid anyway, terms are given up one by one, out loud, and the sheet says so.

That refusal is the most useful thing the tool does, and it is the thing a spreadsheet, a heuristic or a penalty-scored optimiser cannot do.

Two Readings

The solver claims; the checker proves

The solver’s output is a claim, read from a file. The proof belongs to a separate checker that never imports the solver: it shares only the brief’s schema and re-derives every hard constraint in plain Python. If the two disagree, plan exits with its own code. Property tests hold the checker to a brute-force all-pairs check on 300 random grids. The browser board draws the grid but never pretends to be the proof.

The numbers are honest too. A three-screen house solves to proven optimal in seconds. A sixteen-screen house with twenty-two titles plans a week in about eleven minutes, every day feasible and checked, but 12–23% from the bound. The target set in advance was a 2% gap on one day inside a minute; the best day reached 13.4%. Missed, and the benchmark says so — with each optimisation measured, including the ones that made things worse.

The board: the same week drawn in the browser
The board: the same week, drawn in the browser. Nothing leaves the page.
146Tests
20Decision records
16Screens, one week
26,470Booleans in a sixteen-screen day
Explore

Plan a week

The command-line tool is on PyPI, the board runs in the browser, and the source is public.