Board names are convenient for people. They are dangerous as hidden program logic.
When a build system sees a string containing esp32s3 and silently chooses a target, memory layout, USB behavior, or driver set, it replaces an explicit hardware contract with a guess. The guess works until a vendor releases a variant, a board carries an unusual peripheral, or a product needs a different partition shape.
Hardware facts have to be declared
A board catalog should own what is physically true: SoC, architecture, flash, RAM, buses, pins, onboard devices, and partition capabilities. Build and runtime layers consume those facts. They should fail when required facts are absent or inconsistent.
That creates a cleaner responsibility boundary. A build backend translates a canonical build plan into toolchain arguments. It does not decide what the product is.
Capabilities express product intent
An application should request operations such as light control, presence detection, environmental sensing, or motion. Those capabilities are stable enough to survive a board change, while modules and drivers bind them to a verified implementation.
The resolver still respects resource constraints. Two boards that expose the same high-level capability may need different drivers, pins, buses, and memory. Capability equivalence is a resolved fact, not a marketing assumption.
Why this matters beyond firmware
The model reaches the rest of the product. Configuration can be validated against the selected implementation. Commands can be generated from the capability contract. Documentation can show compatibility without hand-maintained matrices. A Project Release can record what it requires instead of containing an unexplained binary.
The result is not “write once, run anywhere.” Physical systems are too constrained for that promise. The more useful promise is: define intent once, resolve it honestly, and keep the evidence attached.