Summary
OPA recently added support for metadata labels on Rego rules (see open-policy-agent/opa#8613 and the follow-up commit 913739161). Labels are arbitrary key-value pairs that policy authors attach to rules via the # METADATA annotation block. When a labeled rule is successfully evaluated, the OPA runtime collects the labels and includes them in decision log entries under a rule_labels field. Labels can be defined at rule, document, package, or subpackages scope, and OPA's compiler aggregates them so that each rule carries the full set of inherited labels from all applicable scopes.
Today, none of this metadata survives the IR planning stage in OPA. There is an upstream issue to extend the IR data model so that labels are carried through to the plan output (see the corresponding OPA issue). Once that work lands, swift-opa will need to be updated to read label metadata from the IR plan and surface it to callers after evaluation.
This presumes decision log support.
What this would involve
Once the upstream IR format includes label metadata, swift-opa would need to parse the new fields from the plan JSON, associate them with the corresponding planned functions, and collect the labels of rules that fire during evaluation. The deduplication behavior (suppressing exact-duplicate label maps) should match OPA's semantics. The collected labels should be made available to the caller as part of the evaluation result, whether through a decision-log-like structure or a simpler metadata accessor on the result type.
References
Summary
OPA recently added support for metadata labels on Rego rules (see open-policy-agent/opa#8613 and the follow-up commit 913739161). Labels are arbitrary key-value pairs that policy authors attach to rules via the
# METADATAannotation block. When a labeled rule is successfully evaluated, the OPA runtime collects the labels and includes them in decision log entries under arule_labelsfield. Labels can be defined at rule, document, package, or subpackages scope, and OPA's compiler aggregates them so that each rule carries the full set of inherited labels from all applicable scopes.Today, none of this metadata survives the IR planning stage in OPA. There is an upstream issue to extend the IR data model so that labels are carried through to the plan output (see the corresponding OPA issue). Once that work lands, swift-opa will need to be updated to read label metadata from the IR plan and surface it to callers after evaluation.
This presumes decision log support.
What this would involve
Once the upstream IR format includes label metadata, swift-opa would need to parse the new fields from the plan JSON, associate them with the corresponding planned functions, and collect the labels of rules that fire during evaluation. The deduplication behavior (suppressing exact-duplicate label maps) should match OPA's semantics. The collected labels should be made available to the caller as part of the evaluation result, whether through a decision-log-like structure or a simpler metadata accessor on the result type.
References