Skip to content

VBL Governance Metadata Fields

Governance metadata appears at the top of a boundary definition:

boundary_id: payment-authorization
version: 1
scope: production
eta_cap: 9950
Field Purpose Required
boundary_id Unique identifier within the project No
version Version string (informational) No
scope Operational scope No
eta_cap Evidence freshness ceiling No

All metadata fields are optional. At least one must be present for the governance header to exist.

Governance metadata must appear first in the boundary definition when present, before evidence requirements, prohibitions, predicates, or the BOUNDARY expression.

A unique identifier for the boundary within its project:

boundary_id: payment-authorization

A version string. Informational: the platform tracks versions through compiled boundary versions, not this string:

version: 1

The operational scope of the boundary:

scope: production

Governance metadata is audit and traceability data. It participates in boundary hash computation but does not affect evaluation outcome. The evaluation engine does not interpret metadata values.

Governance keywords (boundary_id, version, scope, eta_cap) are reserved only when immediately followed by :. This ensures backward compatibility: a field named version (without the colon) is a valid evidence field, not a governance declaration.

boundary_id: my-boundary # governance metadata (keyword + colon)
version: 1 # governance metadata (keyword + colon)
predicate: check: version_field >= 2 # 'version_field' is an evidence field

Governance keywords are unconditionally excluded from evidence_class_name and predicate_name positions. For example, require_evidence: version is a parse error because version is a governance keyword. However, governance keywords are valid as field names in predicate expressions: predicate: check: version >= 2 is valid because version appears as a field reference, not as an evidence class name.