Declaring hw:X:Y automatically also declares hw:X. Declaring hw:wlan:broadcom therefore also declares hw:wlan. Layer authors can gate on either the generic token (has('hw:wlan')) or the vendor-specific one (has('hw:wlan:broadcom')). Inferred parents are associated with the same declaring layer as the child.

A registry entry may carry a Triggers: rule that pushes a value onto another token - either unconditionally (the trait equivalent of an implies: cascade) or conditionally, once a build’s accumulated token set makes the condition true. This captures cross-branch derivations that hierarchy alone can’t express. For example, declaring hw:soc:bcm2712 cascades unconditionally into a microarchitecture fact (hw:uarch:cortex-a76), an architecture-extension fact (hw:arch:arm:aes-accel), and an execution-capability fact (hw:exec:kernel:aarch64) - three independent branches, all derivable from the SoC identity without the layer author enumerating them:

A when= clause need not be the y sentinel - it can be a genuine, multi-token condition, evaluated to a fixed point against the build’s accumulated trait set:

Triggered tokens are themselves subject to hierarchical parent inference. hw:pcie is declared directly by device layers rather than implied by SoC, since the same SoC can appear on boards that expose PCIe to the user and boards that don’t - interface and peripheral accessibility belongs on the device, capabilities intrinsic to silicon belong on the SoC.

Each file is one DEB822 stanza. A stanza can define several sibling local names, each built from X-Env-Trait-<local>- fields - the same shape that layer files use for X-Env-Var-<name>-. There is no Name:/Parent: field - hierarchy comes purely from position in the Include: chain, not from the local name itself. A local name is always a single, colon-free segment. The full dotted-colon token is assembled by prefixing with whichever ancestor’s Include: pulled the file in.

Real example - trait/hw/periph.deb822 and trait/hw/periph/storage.deb822:

hw:storage:nvme requires PCIe functionality, so declaring NVMe without hw:pcie:bus presence is a contradiction and is rejected.

These are deliberately two different fields rather than one field with a flag, so necessity and derivation can never be confused:

Only use an unconditional derivation when the relationship is genuinely both necessary and sufficient. A real device example - trait/hw/device/rpi/sbc/pi5.deb822 cascades a single device identity token into every fact that’s always true of a Pi 5:

A real (colon-containing) trait token may only ever be defined once, in one file, across every trait/ directory in scope - there is no mechanism to reconcile a second definition. A duplicate will always result in an error. It is not possible to override a built-in token by redeclaring it - the only supported override point is the build config file’s trait: section (see Build Config Overrides). This is the only way a trait can enabled/disabled/set outside of declaring it via a DEB822 stanza.

Bare namespace nodes (eg, hw, boot) carry no declaration fact of their own - only an Include: list. Therefore a different source root may legitimately redefine one to extend it with new children (the OEM mechanism below). Two top-level files in the same root both defining the same namespace node is still an error.

Trait tokens are declared in X-Env-Layer-Provides alongside plain label tokens:

Declaring hw:device:rpi:pi5 resolves its full hierarchy and Triggers: cascade into all children (and everything those in turn cascade into), injecting the full expanded set into the provider index.

Declares that a token must be present somewhere in the build. The engine validates its existence but imposes no ordering constraint - trait tokens have no position in the build sequence, so this is the only field that makes sense for them:

The build is rejected at validation time if no layer (and no config override) provides hw:bluetooth or a descendant that implies it.

Trait tokens are not permitted in X-Env-Layer-AfterProvider - rejected at parse time with a clear error. Traits express presence, not build-order position. Use RequiresProvider instead.

A trigger can derive a variable’s value purely from which trait is active, so the variable auto-adapts to whatever hardware or config-level state applies, instead of the layer author enumerating every device/variant combination:

This suits a module that ships with one storage medium by default (asserted unconditionally by its own device-identity trait, eg hw:device:rpi:cm5 cascading to hw:storage:emmc) but where a carrier board or config override can substitute another. A Triggers: rule can just as well set a second, purely informational variable from the same trait - eg deriving a human-facing variant label from hw:storage:sd - so that field reflects trait state rather than being the thing that drives it.

has()/not has() in a Conflicts: expression can validate that a declared IGconf_* value is actually backed by the trait state, or catch an impossible combination of traits with no IGconf_* reference at all:

The first form rejects a selection the trait state doesn’t support - eg choosing nvme storage when nothing asserted hw:storage:nvme. The second is a pure trait-vs-trait check: two mutually-exclusive storage traits both being active is a hardware impossibility, typically from a config override asserting one trait without suppressing the other. If a trait already carries a Requires: on another trait (eg an NVMe token requiring a PCIe token), there’s no need to also duplicate that check here - the registry’s own Requires: validation (see Requires: vs Triggers:) will already cover it, earlier in the pipeline. Conflict expressions run after variable resolution and after the provider index is built, so both IGconf_* values and has() are available.

Pull a layer into the build only when its required trait is present:

The condition is appended to the layer name with when=, separated by a space. Unconditional and conditional entries can be mixed freely in the same comma-separated field. See Conditional Requires in the layer metadata reference for the full syntax, the mixed-field form, and the single-pass/first-order evaluation limitation.