[Bug] Trace can't join a cited provenance id to its provenance facts #262

What is broken

A decision event can carry acs.cited_provenance_ids once the #228 PR lands, but no span carries the ids of the Provenance objects it describes. A trace reader therefore can't join a cited id to its origin and source_id. The provenance-driven denials (FIDES P-T, CaMeL, AARM) are the decisions where that join matters most.

Where

specification/v0.1.0/trace/otel-mapping.json (provenance_attributes); docs/spec/trace/events.md; on the OCSF side, the provenance placement in #260

What the specification says, and what happens instead

provenance.json requires provenance_id on every Provenance object. provenance_attributes maps origin and source_id onto the step span, but not provenance_id. The decision event's acs.cited_provenance_ids names ids that appear nowhere else in the trace.

I proposed an acs.provenance.ids array on #228 (comment). It would always be complete, because provenance_id is required. The question is open on #228, so the #228 PR leaves it out and points here.

Two smaller questions belong in the same decision. The first is order. acs.provenance.origin is positional, but tool-call-request.json carries arguments as a JSON object, whose member order JSON leaves undefined, so two exporters can list the same objects in different orders. The second is duplicates. The text doesn't say whether a Provenance object reached through two arguments is listed once or twice.

Impact on implementers

A lab or auditor reading the trace can see which policy and rule denied a call, but not which input drove it. That part of replay still needs the Guardian's own records.

Proposed direction: add acs.provenance.ids to provenance_attributes, padded and ordered with the other two arrays. Order arguments by name in code-point order and list fields by index. List a Provenance object reached twice once.

Related: #228, #260.

Current Priority Scope

Feeds conformance evidence