Project-level governance is where a team proves that its controls work. Enterprise governance is how the company reuses those controls without turning every repository into a hand-maintained fork.
Nool 6.2.0 governance packs provide that distribution layer. A pack is a versioned bundle of policies, invariants, playbooks, agent definitions, and steering references with explicit Nool and policy ABI compatibility.
This guide is for platform teams evaluating **enterprise AI agent governance**, **AI coding policy enforcement**, **governance as code**, and **reusable controls for autonomous development**.
## A minimal company governance pack
Create a `pack.toml` at the root of the pack directory:
```toml [pack] name = "acme/platform-baseline" version = "1.0.0" requires_nool = ">=6.0.0" policy_abi = 1 ```
The identity and version make the control surface reviewable. `requires_nool` prevents installation into a runtime that cannot interpret the bundle correctly. `policy_abi` provides a compatibility boundary for the executable policy layer.
Treat this file like an API contract. Version it, review it, and keep its release notes focused on changes to enforcement—not merely file movement inside the pack.
## Verify before installation
Nool separates read-only verification from installation:
```bash nool admin pack verify ./platform-baseline nool admin pack install ./platform-baseline ```
`verify` checks the manifest, Nool requirement, policy ABI, and referenced artifacts without changing the project. That makes it suitable for CI and for a platform-team release pipeline.
`install` verifies again, copies the pack into the project, and activates its policy layer. This order matters: compatibility should fail before a partially installed governance baseline can affect developers or agents.
## The caveat every platform team needs to know
Only the policy layer is zero-touch after installation.
Packaged invariants and playbooks are staged for downstream adoption, not silently wired into every project configuration. Each consuming team must explicitly add those blocks to its own `nool.toml` once.
That is a feature, not an omission. Policies often represent non-negotiable company boundaries, such as secret scanning or forbidden dependency rules. Invariants and playbooks frequently need project-specific identifiers, lifecycle choices, or commands. Keeping that final connection explicit avoids invisible behavior and gives the downstream ledger a clear adoption event.
A useful rollout checklist is:
- verify and install the pack - confirm the policy layer is active - copy the invariant definitions into the project config - copy the approved playbooks into the project config - bind referenced roles to named owners - run the project audit before making a gate required
## Company controls can be tightened, not weakened
A pack's steering points reference roles rather than individual people. The company might require a `ciso` role on sensitive-path pushes and an `architect` role when coupling increases.
Teams remain free to add stricter local gates. A payments team might add a billing owner, or an identity team might require a second security review. What they cannot do is weaken a company-mandated control inherited from the pack.
This gives an enterprise a clean governance hierarchy:
flowchart TD C[Company governance pack] --> D[Department workspace] D --> T[Team workspace] T --> P1[Project A nool.toml] T --> P2[Project B nool.toml] C -. mandatory role controls .-> P1 C -. mandatory role controls .-> P2 P1 --> L1[Stricter local gates] P2 --> L2[Stricter local gates]
## Nested workspaces reflect the organization
`workspace.toml` files can be nested to represent company, department, team, and project boundaries. The workspace layer coordinates discovery and rollups; child projects remain the authoritative source of implementation truth.
That distinction prevents a common enterprise failure: creating a second management database that disagrees with the repositories doing the work. Goals may decompose downward and health may roll upward, but accepted project transitions still belong to the project ledger.
Use release edges only when shipment order is real. Use contract edges when repositories share an interface without an ordering requirement. Conservative rollups should surface the worst relevant child state so leadership does not receive a falsely optimistic average.
## Extend policies without building a platform fork
Nool exposes several extension levels, and the simplest adequate option is usually the best.
Custom policy
Place a YAML or JSON policy file in the directory configured by `[aram] policies_path`. Nool auto-loads it; there is no separate registration ceremony. Use this for organization-specific forbidden patterns, ownership rules, or security boundaries.
Custom invariant
Define a declarative `[invariants.rule_definitions.<id>]` block. This is the right choice for repository facts that can be stated as configuration and checked consistently without new code.
Custom playbook
Compose existing Nool verbs into a repeatable operating procedure. A playbook can standardize a release, review, or recovery sequence. It cannot invent a steering gate that the organization has not already bound, which prevents an automation recipe from bypassing the control model.
Custom language adapter
For a simple language, use `[[languages]]` with file extensions and comment prefixes. This is enough to teach the basic adapter surface without a plugin build.
The architecture also defines a WASM plugin path through the `nool-language-sdk` and its `language_plugin!` macro for full AST-level adapters. Treat that as an advanced integration path and validate it against the SDK/runtime combination you plan to deploy.
## Design packs for adoption, not just enforcement
A technically correct pack can still fail organizationally. The best packs have three properties:
1. **A narrow, defensible mandatory core.** Company controls should protect genuine cross-team risks. 2. **Visible ownership.** Every steering role resolves to somebody who can make a decision. 3. **A migration path.** Teams can start with warnings, inspect evidence, and graduate precise rules to required enforcement.
Do not use a company pack to encode every preference of the platform team. That produces policy fatigue and encourages teams to look for escape hatches. Encode the controls that deserve global consistency; leave product-specific architecture to the people who own it.
## A practical enterprise rollout
Start with one proven project baseline. Package the policy layer, verify it in CI, and install it into a small set of representative repositories. Measure false positives and steering wait time. Then publish a versioned release and expand through nested workspaces.
The resulting system has a simple shape:
- the company pack defines mandatory policy and role references - each team binds owners and adopts explicit invariants/playbooks - each project records governed transitions in its own ledger - workspaces coordinate dependency order and conservative health rollups - audits prove which controls were active for each accepted change
That is governance as code without governance by surprise.
See the [Advanced Nool Setup documentation](/docs/advanced-setup) for the project configuration, or start with [Nool Advanced Setup: Gates, Trust, and Steering](/blog/nool-advanced-setup-gates-trust-steering) before packaging the enterprise baseline.