Governance envelopes
How policy cascades through nested projects. ~30 axes. Intersection, union, min, max, AND, OR. Fail-closed throughout.
A governance envelope is the typed envelope of what a project (and its descendants) is allowed to do. Allowed providers, allowed regions, allowed federation targets, allowed connectors, quotas, minimum auth strengths, allowed connection types, and ~30 other axes. Vadyl compiles a project's effective envelope from its full ancestry chain — closer ancestors don't override farther ones; they tighten them.
Why envelopes
Vadyl supports nested projects: an organization can have child projects, those can have grandchild projects, and so on. Without a governance model, a child could drift outside what the parent allowed — bind to a forbidden region, federate with an unapproved peer, exceed parent quotas. Envelopes prevent that, structurally.
Merge discipline
Envelopes merge from root to descendant with typed reduction rules — never ad hoc:
- Allowlists narrow (intersection):
AllowedProviderTypes,AllowedRegions,AllowedFederationTargets. - Denylists grow (union):
DeniedConnectionTypes,DeniedEgressHosts. - Quotas shrink (min):
MaxStorageBytes,MaxMonthlyEvents,MaxConcurrentRuns. - Auth strength rises (max):
MinimumAuthStrengthonly ever increases as you walk down the tree. - Permissions AND: a child can only have a permission if every ancestor grants it.
- Restrictions OR: a child has a restriction if any ancestor enforces it.
These rules guarantee that a descendant's effective envelope is always a subset of (or equal to) every ancestor's. Tightening at the root automatically cascades down on the next compile.
Where envelopes are enforced
Enforcement is fail-closed at every mutation site:
- Child project provisioning
- Provider binding creation / update
- Cache binding creation / update
- Governed connection creation / update
- Capability grant issuance
- Quota mutation
- Federation contract creation
- Installable surface publishing / installation
- Branching mutations (branches, commits, sandboxes, deployments)
- Identity / database connector binding
If the envelope cannot be resolved (control-plane corrupted, ancestry chain broken), the descendant is marked Corrupt with a zero-default integrity status — it cannot serve traffic and cannot be mutated until the chain is repaired.
Tightening cascades
When a parent envelope tightens — e.g. removing a provider fromAllowedProviderTypes — every descendant's next compile observes the new envelope. Bindings that previously resolved but no longer satisfy the envelope are dropped, and the affected runtime descriptor is marked corrupt with a truthful reason code (governance-envelope-tightened). Operators see the change in the dashboard and the explainer.
Capability grants
Inside the envelope, projects receive explicit, time-bounded capability grants. A grant is a typed authorization — "this project may host child projects", "this project may federate cross-project entities", "this project may publish installable surfaces". Grants are issued by an authority (typically the parent), are auditable, and expire if not renewed.
Why this matters
Multi-tenant SaaS, agency-style organizations, regulated industries, and AI agents that provision their own sub-environments all need a guarantee that descendants stay inside parent-imposed boundaries. Envelopes give that guarantee structurally — not as a runtime check you have to remember to add, but as a compile-time invariant baked into every mutation site.