Descriptor Enrichment Overview

When Witboost evaluates a governance policy or dispatches a provisioning request, it works against the project's descriptor — a YAML document containing all the metadata that describes the project and its components. Some governance decisions require information that is not known at authoring time and changes continuously — for example, whether a project is currently deployed in a given environment.

Enriched data is live platform state that Witboost automatically adds to the descriptor at evaluation time. Governance policies can then use this information to make decisions that reflect the actual current state of the platform.

Static vs. dynamic data

The descriptor a policy sees at evaluation time is assembled from two sources:

	Static data	Dynamic data
When computed	At release creation time	At evaluation time (provisioning, policy testing)
Stored in the release snapshot	Yes	No
Reflects current state	No — frozen at release time	Yes — always current (subject to cache TTL)
Example	Resolved taxonomy labels, computed maturity scores	Current deployment status per environment

Static data is computed once when a release is cut and never changes for that release. Dynamic data is fetched fresh each time an evaluation occurs, so it always reflects what is actually happening in the platform right now.

note

Enriched data is never stored in the release snapshot. If you inspect a release's descriptor directly, you will not find fields such as witboost.deploymentStatus — those are added in memory at evaluation time only.

When enrichment data is available

Enriched data is added to the descriptor in two situations:

• During a deployment: before governance policies are evaluated and before the descriptor is passed to Tech Adapters.
• During a policy test (Builder Edit & Test): before the governance engine evaluates the policy, so test results reflect the same data that would be present in a real deployment.

In both cases, by the time a governance policy runs, the descriptor already contains all available enriched data. Policies do not need any special handling to access it — they read it like any other descriptor field.

note

Testing policies against their perimeter: When testing a policy against its perimeter in the Governance section, the descriptor contains enriched data from when the project was last deployed, but this data is static (stored), not live. The policy evaluates against the stored enriched descriptor, not freshly computed enriched data.

How descriptor enrichment works

Enriched data is contributed by Descriptor Enrichment Providers — platform components that each add a specific set of fields to the descriptor. Providers are:

1. Registered automatically when the platform starts
2. Disabled by default — operators must explicitly enable them through the Administration Panel
3. Invoked at evaluation time — just before governance policies run or before the descriptor is passed to Tech Adapters
4. Cached — provider results are cached for a configurable TTL to reduce latency and upstream load

Each provider:

• Has a unique identifier (e.g., witboost.deployment-status)
• Adds fields under a specific key in the descriptor (e.g., witboost.deploymentStatus)
• Can be independently enabled, disabled, and configured
• Can be restricted to specific project types using System Types filtering

Next steps

• To enable a provider: See Enable Descriptor Enrichment Providers
• To understand configuration options: See Descriptor Enrichment Configuration
• To see available providers: See Descriptor Enrichment Providers