Provenance and Correlation
Provenance and Correlation
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Reference data-governance model |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Provenance chain
source/device → raw observation → processing step/model/version
→ derived product/correlation → human or automated decision
→ task/effect → outcome/evidence
Minimum provenance fields
- Source identity, location/frame, calibration/profile and source timestamp.
- Input object identifiers and immutable checksums for retained artifacts.
- Transformation/algorithm/model name, version, parameters and execution environment.
- Actor/service identity, authorization context and correlation identifiers.
- Output object identifiers, confidence/uncertainty and validation result.
- Handling policy, retention and release/dissemination actions.
Why this is operationally important
Provenance lets an operator understand why a track, alert or recommendation exists; lets an investigator reconstruct the decision trail; lets an analyst reproduce a result; and lets assurance personnel determine whether an effect was based on valid data and approved processing.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.