Should build cost be an architecture principle, and where? #49

New issue

Open

opened 2026-09-08 04:47:48 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-08 04:47:48 +01:00

Contributor

What we want it to say, broadly

Build cost should be a number recorded per machine per commit — evaluation peak memory, evaluation wall time, closure size, derivation count — so that a change which makes a machine more expensive is visible when it lands rather than when a host stops rebuilding.

The prompting case: one disposable VM carried runtime = "microvm", which made every hypervisor rebuild also build that guest and pack its store closure with mkfs.erofs. Keeping that code was a deliberate decision and a reasonable one. What was missing was any signal of what carrying it cost. The price appeared when the hypervisor ran out of memory mid-rebuild and had to be power-cycled, roughly eight weeks after the cost was introduced. Withdrawing it took the hypervisor's evaluation peak from 2802 MiB to 1982 MiB.

What this issue is for

Deciding whether that belongs in architecture.md at all, and if so, in what form and where. It is a proposal, not an agreed edit.

Open questions

Is it a new principle or an amendment to an existing one? Principle 12 already requires a change to justify itself before it lands. If the gap is only that "justifies itself" has meant prose review and never a measured number, this may be a sentence added to 12 rather than a sixteenth principle. Principle 14, "lessons become mechanism", is also adjacent.

Is this a recurring pattern or a single incident? The case for a principle rests on that. The history should be checked for other occasions where a cost accumulated unmeasured and surfaced only on hitting a hard limit — OOM during check runs, disk exhaustion, evaluation time, closure growth, secrets churn rebuilding machines that did not need it. Three instances make it a principle. One makes it a nix.md entry, and principle 12 already covers the rest.

Which section, if it lands as its own principle? Principles are grouped thematically — Sovereignty, Boundaries, State and Truth, Process — and numbered straight through. Numbers are identifiers rather than a ranking, and the citation convention is by name, so renumbering to insert mid-file is available. State and Truth and Process are both plausible homes.

Could it have been implemented earlier? nix.md already recorded that a framework repo's check run "climbs with fixture count, not machine count", and the whole-flake evaluation ceiling was written down on 2026-07-16 and filed as P0 on 2026-07-30. Both were accurate and neither changed anything. Whatever lands should account for why prose did not work here, or it will not work either.

The mechanism itself — what to record, where to store it, how to surface a regression — is scoped in allod/strategy#46 alongside the microvm removal. This issue is only about whether and how the principle is written down.

A draft edit exists on an unpushed branch and should be treated as a starting point rather than a candidate.

## What we want it to say, broadly Build cost should be a number recorded per machine per commit — evaluation peak memory, evaluation wall time, closure size, derivation count — so that a change which makes a machine more expensive is visible when it lands rather than when a host stops rebuilding. The prompting case: one disposable VM carried `runtime = "microvm"`, which made every hypervisor rebuild also build that guest and pack its store closure with `mkfs.erofs`. Keeping that code was a deliberate decision and a reasonable one. What was missing was any signal of what carrying it cost. The price appeared when the hypervisor ran out of memory mid-rebuild and had to be power-cycled, roughly eight weeks after the cost was introduced. Withdrawing it took the hypervisor's evaluation peak from 2802 MiB to 1982 MiB. ## What this issue is for Deciding whether that belongs in `architecture.md` at all, and if so, in what form and where. It is a proposal, not an agreed edit. ## Open questions **Is it a new principle or an amendment to an existing one?** Principle 12 already requires a change to justify itself before it lands. If the gap is only that "justifies itself" has meant prose review and never a measured number, this may be a sentence added to 12 rather than a sixteenth principle. Principle 14, "lessons become mechanism", is also adjacent. **Is this a recurring pattern or a single incident?** The case for a principle rests on that. The history should be checked for other occasions where a cost accumulated unmeasured and surfaced only on hitting a hard limit — OOM during check runs, disk exhaustion, evaluation time, closure growth, secrets churn rebuilding machines that did not need it. Three instances make it a principle. One makes it a `nix.md` entry, and principle 12 already covers the rest. **Which section, if it lands as its own principle?** Principles are grouped thematically — Sovereignty, Boundaries, State and Truth, Process — and numbered straight through. Numbers are identifiers rather than a ranking, and the citation convention is by name, so renumbering to insert mid-file is available. State and Truth and Process are both plausible homes. **Could it have been implemented earlier?** `nix.md` already recorded that a framework repo's check run "climbs with fixture count, not machine count", and the whole-flake evaluation ceiling was written down on 2026-07-16 and filed as P0 on 2026-07-30. Both were accurate and neither changed anything. Whatever lands should account for why prose did not work here, or it will not work either. ## Related The mechanism itself — what to record, where to store it, how to surface a regression — is scoped in allod/strategy#46 alongside the microvm removal. This issue is only about whether and how the principle is written down. A draft edit exists on an unpushed branch and should be treated as a starting point rather than a candidate.