predictive-modelling is the harness for structured prediction: a table or a relational database with a target to predict, a validation protocol, and a test set the campaign never trains on. It ships inside the package and loads by name. Its skills name two situations in particular, a relational database with a temporal cutoff and a flat prediction table, and its playbooks cover the other task shapes (text, images, audio, detection and the rest).
What it holds is the discipline, not the task: the brief, the evaluator, the data and the starting repository are yours. The domain stops at the candidate; deployment is the engine’s bundled targets.
Where it came from
The harness was written from the benchmarks the engine was measured on: first RelBench (the feature practices that measured positive when ablated, the temporal protocol, the leakage audit), then MLE-bench (the task-type playbooks and the Kaggle-shaped validation discipline). Every practice is stated as a thing to measure on the task at hand and keep only where its own numbers agree, never as a benchmark’s constant: the package’s gate runscheck over each bundled harness at the packaged page budget and scans it for a benchmark constant. The results on those benchmarks, with who ran them and when, are on RelBench and MLE-Bench.
What it ships
instructions/guardrails.md, the standing rules (the task statement before anything else, the data and its shape, the protocol the evaluator fixes), and the module’s own page, one each for setup, ideation, implementation, verification, feedback and learning. The skills, the delegate and the hooks are defined once and listed per module:
The skills
The delegate
leakage-auditor audits one attempt for leakage in data access, joins, time handling, the split and the validation chain, and reports pass, fail or inconclusive with evidence. Implementation sessions can call it before they finish; verification sessions call it for the verdict.
The hooks
protect-prepared, on the file tools: the pinned snapshot underprepared/is read-only, since it is what makes attempts comparable. A session that wants derived data writes it somewhere else.deny-web-fetch, on the shell, anddeny-web, on the native web tools: no web in implementation and verification. A candidate’s data is the task’s data and the sanitized copy, so every attempt sees the same rows and nothing dated after the cutoff.
The environment
requirements.txt lists the Python packages the skills’ scripts need. Nothing is installed for you: kapso harness check prints a needs line with the install command for each one this machine lacks, and a build refuses to start while one is unmet.
Run a task on it
Harness predictive-modelling line and kapso.load_harness("predictive-modelling") name it the same way. The campaign then runs as Use a harness describes: the setup session pins what every later session should find ready under prepared/ (a sanitized copy of a time-cut database with the test cutoff applied; the pretrained models and companion datasets the task allows, screened and pinned) and writes the domain statement into the task statement; each implementation session works on its own branch under the hooks; each attempt is verified by a session that reads its diff and its evaluation output, with the leakage auditor’s report, and a void attempt keeps its branch and is never delivered.
The benchmark runners run on it by default. Each keeps the task material (the download, the sanitized copy, the provided grader, the brief) and launches the build with this harness; --harness names another.
pip install leeroo-kapso · Every page as plain text: llms.txt.