Rev. A / 2026-08-07 Specification vairworks.co.uk
VAIR LTD is a London software company working on caching, scheduling and reproducibility for CI build systems. We are pre-release. This page is the specification we are building against.
01 / Scope
The company works on the layer that sits between a repository and its CI runners. The table below states what each area covers and how far it has got. Nothing in the right-hand column is a release announcement.
| Ref | Work area | What it covers | Current state |
|---|---|---|---|
| 01 | Build caching | Content-addressed cache keys derived from a task's declared inputs, a local tier and a shared remote tier, and a rule that failures are never promoted to the shared tier. | In development. No binary released, publicly or privately. |
| 02 | Task scheduling | Dependency graph resolution, fan-out of independent tasks across ephemeral runners, and queue admission against a stated concurrency budget rather than an unbounded pool. | In development. No binary released, publicly or privately. |
| 03 | Reproducibility auditing | Recording the resolved input set for every task so that a build can be replayed later and any divergence attributed to a named input rather than to chance. | Design stage. Written specification only, no implementation. |
Table scrolls sideways on narrow screens.
02 / What we build
These are design commitments, not achievements. Each card describes what the tooling is meant to do when it ships. None of them describes behaviour you can run today.
A cache key will be a digest over the declared file set, the pinned toolchain versions and an explicit allow-list of environment variables. Anything not on the list is stripped before hashing, so an unrelated variable in the runner environment cannot silently invalidate a hit or, worse, cause a false one.
Design commitment
Fan-out will be admitted against a concurrency budget the team sets, not against whatever the runner pool happens to allow. Cold-start cost on ephemeral runners is treated as a first-class input to that decision, because on short tasks it is frequently the dominant term.
Design commitment
Every task will emit the resolved input set it actually hashed. Two runs that disagree can then be diffed at the level of inputs, which turns "it works on the other runner" from a shrug into a question with an answer.
Design commitment
# vair.toml
# The interface being designed against. No binary that reads this
# file has been released, publicly or privately.
[workspace]
root = "."
toolchain = "lockfile" # every tool version resolved, none inherited
[cache]
tiers = ["local", "remote"]
key = ["inputs", "toolchain", "env"]
write = "on-success" # failures never reach the shared tier
[[task]]
name = "build"
inputs = ["src/**", "Cargo.lock"]
outputs = ["target/release/app"]
env = ["TARGET_TRIPLE"] # the allow-list; the rest is stripped
[[task]]
name = "test"
depends = ["build"]
inputs = ["tests/**"]
fanout = 12 # admitted against the concurrency budget
This is published so the design can be argued with before it ships. It is not documentation for a product you can install, and there is no download link on this site because there is nothing to download.
03 / Method
Five steps, procedural. The same sequence governs our own tooling and any consulting engagement we take, because the second is how the first gets tested against a build we did not write.
The starting artefact is the CI configuration and the task graph it produces, not a description of them. Steps that were added for one incident and never removed are usually visible within an hour of reading.
Wall-clock per task, queue wait, runner cold-start and cache hit rate are recorded first, on the team's own runners. A change with no baseline in front of it is a guess, and we would rather publish a number the team can reproduce than one they have to trust.
Each task gets an explicit input set: files, toolchain versions, and the environment variables it is genuinely allowed to read. Most of the work in caching is here, and most of the false cache hits people have been burned by trace back to this step being skipped.
One task, one boundary, verified by replaying the build with the cache cold and then warm and comparing outputs byte for byte. Only after that boundary holds does a second one get touched.
The deliverable includes the input declarations, the measurements and the written reasons for each decision, in the team's repository. An engagement that only works while we are still on the call has not finished.
04 / Reference architecture
The schematic below is a design document. It is not a deployment diagram, no part of it is running in production anywhere, and it will change as the specification does.
Repository. Source, lockfiles and the CI configuration. Taken as given. Nothing in the design requires a team to restructure a repository before it can be cached.
Input hasher. Reads only the declared input set for a task. Undeclared files and unlisted environment variables are invisible to it by construction, which is what makes a key mean something.
Cache index. Content addressed, so an entry is named by what went into it. Two teams that produce the same inputs land on the same key without coordinating.
Scheduler. Resolves the dependency graph, drops tasks whose key already resolves, and admits the remainder against a concurrency budget the team states rather than one the runner pool implies.
Runner pool. Ephemeral by assumption. Cold-start cost is modelled as an input to admission, not treated as noise to be averaged away.
Artefact and audit store. Holds outputs alongside the resolved input set that produced them, which is what makes a later replay comparable rather than merely repeated.
05 / Engagement
Alongside its own tooling the company takes a small number of consulting engagements on other teams' build systems. The availability line is the only fact on this page that changes week to week.
06 / Notes and disclosures
There is no contact form on this site. A form that posts nowhere is worse than no form, so the only route is email, and it is read by a person.
Replies come from a vairworks.co.uk address within five working days. Written enquiries can also be sent to the registered office below.