Domain packs

What a pack is

A domain pack bundles everything that describes a problem area rather than a physical thing: roles, the capabilities those roles may grant, constraints, resource definitions and goal definitions. Port operations, urban traffic, airport operations, wildlife, manufacturing and emergency response are all natural packs.

Packs are the reusable unit. An adapter is reusable across every instance of a class; a pack is reusable across every place that has the same problem.

Naming and namespaces

Capability names are minted by packs and namespaced to them. A role can only reference capabilities its pack declares or explicitly imports, which prevents a role from quietly acquiring authority that nothing audited.

• machine.hoist is declared by the manufacturing or port pack that owns it.
• port.crane_operator is a role that grants a set of those capabilities.
• port.clear_inbound_queue is a goal defined in the same pack.

Composition

Packs compose. A logistics pack can build on a vehicles pack; an airport pack can import ground-traffic capabilities. Composition is explicit — importing a pack does not automatically grant its capabilities to your roles, it only makes them available to grant.

Pack validation

Packs are validated when they load, not when a decision needs them. Validation checks that:

• Every capability a role grants is declared by the pack or an imported one.
• Every goal decomposes into goals or capabilities that exist.
• Every resource referenced by a cost or budget is defined.
• No constraint references an observation field that no adapter in scope produces.

A pack that fails validation prevents attachment for the roles it defines. It does not load partially.

Versioning

Packs carry a version. Changing what a role grants is a breaking change to every place that imports it, and the tooling reports which roles are affected before you ship it. See Releases and versioning for how compatibility is handled across releases.