diff --git a/04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/01-progress.md b/04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/01-progress.md
index e683953..cf8c83e 100644
--- a/04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/01-progress.md
+++ b/04-ISSUES/142-the-host-is-the-one-thing-the-mesh-does-not-deliver/01-progress.md
@@ -89,3 +89,9 @@ work on.
 two of them is a C library, not a kernel" — and a static Go binary has no C library. So one build would
 in fact run on all three. The pin is then a policy (a host refuses a machine it was not built for)
 rather than a necessity, which is a reasonable thing to keep and is worth knowing is a choice.
+
+**And a sharper one, asked as a question and worth its own record.** The artifact's system is validated
+and then read by nothing: it does not reach the compiler, no machine is matched against it, and nothing
+chooses between two artifacts by it. The host built here is x86-64 because the build machine is, not
+because anything in the declaration said so — correct for this mesh by coincidence. That is
+[issue 159](../159-an-artifacts-system-is-checked-and-then-ignored/00-report.md).
diff --git a/04-ISSUES/159-an-artifacts-system-is-checked-and-then-ignored/00-report.md b/04-ISSUES/159-an-artifacts-system-is-checked-and-then-ignored/00-report.md
new file mode 100644
index 0000000..d20a5dc
--- /dev/null
+++ b/04-ISSUES/159-an-artifacts-system-is-checked-and-then-ignored/00-report.md
@@ -0,0 +1,82 @@
+---
+status: located
+opened: 2026-09-30
+located-in:
+  - mesh-controller internal/catalogue/build.go (System is validated and read by nothing else)
+  - mesh-controller internal/builder (the compile invocation names no target)
+fixed-by:
+amended-design:
+---
+
+# 159 — An artifact's system is checked, and then nothing uses it
+
+## What was observed
+
+Asked whether the host is built for more than one architecture, 2026-09-30, having just built it
+through the new Go toolchain.
+
+[ADR 0142](../../02-DECISIONS/0142-the-mesh-delivers-its-own-components-as-binaries.md) says an
+artifact declares what it targets, and that one artifact per target is one build each. The manifest
+layer enforces the first half strictly: a bundle in a language that compiles to a binary **must** name
+a system, must name one of `alpine`, `android`, `arch`, and must not name one at all if its language is
+interpreted. A manifest that gets any of that wrong is refused with a reason.
+
+**The field is then read by nothing.** Every use of it in the control plane is in the function that
+validates it. It does not reach the compiler, no machine is matched against it, and nothing chooses
+between two artifacts by it.
+
+So the compile runs with no target named and produces a binary for whatever the build machine happens
+to be. The host, declared `system: arch` and built on this mesh's only build machine:
+
+```
+mesh-host: ELF 64-bit LSB executable, x86-64, statically linked, stripped
+```
+
+Correct for every machine in this mesh, which are all x86-64 Arch — and correct by coincidence rather
+than by anything the declaration did.
+
+## Why it matters
+
+**A module declaring two systems would get two identical binaries.** Both would be published, both
+pinned, both delivered, and the one sent to the machine it was not built for would fail at exec with a
+message about a format — which is the shape ADR 0005's link-time pin exists to prevent, arriving
+because the pin was never applied.
+
+`android` in the list is the sharp end: it is not an x86-64 platform, and an artifact declared for it
+today would be an x86-64 binary wearing the label. Nothing would say so until a machine tried to run
+it.
+
+**And the field reads as implemented.** It is required, validated against a closed list, and refused
+with a careful message — every signal a manifest author gets says the mesh is acting on it. A field
+that is checked and ignored is worse than one that does not exist, because the check is what persuades
+you it works.
+
+## Two things this is not
+
+- **Not the same axis as the distribution.** `alpine`, `android`, `arch` are what a machine reports
+  itself to be, and the comment on the list says why: "the difference between two of them is a C
+  library, not a kernel". The processor is a second dimension and the manifest has no word for it at
+  all — so even a correct implementation of the current field would not answer the question that
+  started this.
+- **Not urgent for this mesh.** Four machines, all x86-64 Arch, one build machine. Nothing is broken
+  today and nothing will be until a machine differs — which is exactly how long a field like this stays
+  invisible.
+
+## Where to look
+
+The compile invocation is assembled in `mesh-controller internal/builder`, and for Go it would need
+`GOOS`/`GOARCH` set from the artifact rather than inherited from the build machine. That needs the
+manifest to carry a processor as well as a system, or the systems list to mean both — which is a
+decision, not a fix, and belongs with whoever answers whether one static binary should serve several
+distributions at all.
+
+**That last question is live.** The Go toolchain builds statically, so a single binary has no C library
+to differ about and would in fact run on Alpine and Arch alike. The per-system pin is then a policy — a
+host refuses a machine it was not built for — rather than a technical necessity, and worth knowing is a
+choice.
+
+## How a fix is checked
+
+An artifact declared for a system the build machine is not produces a binary for that system, shown by
+reading the file rather than by the build reporting success; and two artifacts declared for two systems
+do not have the same digest.