Rev. A / 2026-08-07 Datasheet vairworks.co.uk
VAIR LTD is a London software company that works the caching, scheduling and reproducibility layer between a repository and its CI runners. Toolchains get resolved rather than inherited, cache keys are cut from inputs somebody declared, and the task graph resolves before a runner is asked for, so a broken pin fails at resolution instead of forty minutes into a queue.
01 / Scope
Everything here sits between a repository and its CI runners. The table states what each area covers, and the class of failure it exists to remove.
| Ref | Work area | What it covers | What it rules out |
|---|---|---|---|
| 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. | A hit served from an input nobody declared, and a failed run poisoning the tier every other machine reads. |
| 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. | Fan-out that keeps widening until the runner pool, rather than the team, has decided the monthly bill. |
| 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. | Two runs that disagree for a reason nobody can name once the runner has been torn down. |
Scrolls sideways on a narrow screen.
02 / Rules
Each card states one rule and the reasoning under it. The configuration format in the specimen below is where those three rules are declared and enforced.
A cache key is a digest over the declared file set, the pinned toolchain versions and an explicit allow-list of environment variables. Anything off that list is stripped before hashing, so a stray variable in the runner environment cannot quietly invalidate a hit or, worse, manufacture one.
cache.key
Fan-out is admitted against a concurrency budget the team sets, not against whatever the runner pool happens to allow. Cold-start cost on ephemeral runners counts as a first-class input to that decision, because on short tasks it is frequently the dominant term.
task.fanout
Every task emits the resolved input set it actually hashed. Two runs that disagree get diffed at the level of inputs, which turns "it works on the other runner" from a shrug into a question with an answer.
audit.inputs
# vair.toml
# One file at the workspace root. Every key below is read at task
# resolution, before a runner is asked for.
[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
Printed in full so it can be argued with rather than summarised. Each stanza carries one of the rules above: declared inputs, a pinned toolchain, an environment allow-list, and a write rule that keeps a failed task out of the tier everyone else reads.
03 / Method
Five steps, procedural, in this order. The same sequence governs the company's own tooling and every engagement it takes, because an engagement is where that tooling meets a build nobody here wrote.
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 sets out the path a task takes from repository to artefact store and the six components it passes through. The lettered notes beside it say what each one answers for.
Repository. Source, lockfiles and the CI configuration. Taken as given. Nothing here asks a team to restructure a repository before any of 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 feeds admission as an input in its own right, rather than being averaged away as noise.
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 engagements on other teams' build systems. The terms below are standing ones. Everything else is settled per engagement, in writing, before any work starts.
06 / Notes and disclosures
The job everyone on the team has quietly learned to work around. Send its CI configuration and a rough wall-clock figure, and you get back a specific reading of where the time is going rather than a brochure.
Replies come from a vairworks.co.uk address within five working days. Written enquiries can also be sent to the registered office below.