Skip to main content
Kapso runs the same campaign in every domain: propose a candidate, implement it on its own branch, measure it, judge it, keep the best. What differs between domains is how the work is done well: what to pin before the first experiment, which disciplines every implementer must keep, what a verifier checks, which tools and scripts exist. A harness holds that. It is one directory, written once per domain, and a build loads it.

​
Three layers

The task’s values win over anything a harness page says; the engine’s rules win over both. A harness never holds an evaluator, a dataset, a goal, a budget, a credential value or a model choice: those belong to the task, the engine and .env.

​
The seven modules

A campaign is made of sessions, and each session belongs to one of seven modules. A harness lists, per module, what its sessions get. Two pages reach every session of a module: instructions/guardrails.md, the domain’s standing rules, and instructions/<module>.md, that module’s own page. Skills, servers, delegates and hooks are defined once in the directory and listed on each module that gets them; nothing is inherited between modules.

​
What a harness changes in a build

  • A setup session runs once when the harness has setup content. It pins what every later session should find ready, under prepared/, and writes the domain statement the task statement carries.
  • A task statement, kapso_task.md at the campaign root, is composed by Kapso from the brief, the budget, the evaluation and data references, the domain statement and the prepared resources. Every session reads it first.
  • Every session is staged: its pages in the prompt under a Domain guidance heading, its skills, servers, delegates and hooks in the host’s own format, beside the session. The staging is recorded per session.
  • Verification per attempt runs when the harness has verification content: a session reads the attempt’s diff and evaluation output and writes a verdict. A void attempt keeps its branch and is never delivered; the judge reads the verdict either way.
  • One identity in every record: the harness’s name, version, content hash and source are in the launch record, the status file, the checkpoint and the solution, and a resume refuses a harness that is not the launch’s.
A build with no harness runs as before: no setup session, no staged file, no guidance heading, solution.harness is None.

​
Where to go

Use a harness

Name one on a build, check what the machine lacks, read what the campaign recorded

Predictive modelling

The bundled harness for structured prediction: what it ships, where it came from, how to run a task on it

Competitive programming

The bundled harness for timed contests scored by an official scorer or a leaderboard

Write a harness

From the two-file starter to pages, skills, servers, delegates and hooks

The trading example

A harness, a task on it, and the run an author reads

Harness reference

The manifest, the reference grammar, every check rule, the staged files per host, the records
Related pages: Use a harness · Predictive modelling · Competitive programming · Write a harness · The trading example · Harness reference · The brief Kapso is an open-source framework by Leeroo that builds software toward measurable goals through experiment campaigns. Source code: github.com/Leeroo-AI/kapso · Install: pip install leeroo-kapso · Every page as plain text: llms.txt.