Vulnerability Fix Verification Fidelity: When Proof-of-Fix Fails
Fidelity is the property of a fix verification that separates a defensible closure from a closed ticket. A finding that closes with replay evidence, named verifier, and scope coverage carries a closure trail an auditor can read against the original attack path. A finding that closes with a status change and no replay carries a date stamp and an assumption. The two closures look identical in the in-SLA closure rate and identical in the headline MTTR. They are not identical in defensibility, in regression risk, or in audit evidence quality. Fix verification fidelity is the metric that separates them.5,7,8,9
This research lays out how vulnerability fix verifications fail across enterprise remediation programmes, the eight low-fidelity patterns that recur across AppSec, internal security, vulnerability management, and security engineering teams, the three axes that measure fidelity in a way the in-SLA closure rate cannot, the relationship between fidelity at closure time and scanner cadence post-closure, and the live-record discipline that keeps the verification artefact paired to the original finding so the fidelity question is reproducible at any moment between reporting cycles. The argument is not that verification should be slower. The argument is that the verification act has to produce evidence, and the evidence has to live on the same record the original finding lives on, with a clock that does not silently reset.1,3,4,7
Why fidelity is the missing axis in remediation reporting
Enterprise vulnerability remediation programmes typically report three operational metrics to leadership: the mean time to remediate, the in-SLA closure rate per severity band, and the open queue depth per severity band. All three measure throughput in different framings. None of them measure the quality of the verification act that produced the closure. A programme that closes findings quickly on weak verification evidence and a programme that closes findings at the same pace on strong verification evidence report identical throughput metrics and very different audit-evidence trails.
The discipline that scales is to treat fidelity as a third axis alongside throughput and durability rather than as an implicit property of closure. Throughput answers the speed question (how quickly do findings close). Durability answers the post-closure question (do closed findings stay closed; see the vulnerability reopen rate research). Fidelity answers the verification-act question (does the closure record carry proof the fix worked). Together the three axes separate fast-and-defensible programmes from fast-and-undefendable programmes without requiring a tribal-knowledge interpretation of the numbers.18
ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS v4.0 Requirement 6.3.3, and NIST SP 800-53 RA-5 and SI-2 each frame remediation expectations; the audit-fieldwork reading of those controls in 2025 and 2026 is increasingly that closures need verification evidence on the same record, not only a closure date. Fidelity is therefore not only an operational metric; it is the leading indicator of audit-evidence quality, and programmes whose closure records carry only a status change face a higher reconstruction cost when the auditor asks for the verification artefact.5,7,8
Eight low-fidelity verification patterns
Closures that fail to produce defensible verification evidence concentrate in a small number of recurring patterns. Each pattern produces a closure record that reads convincingly in the headline number and poorly in the diagnostic detail. Naming the patterns lets the programme attack the verification gap directly rather than chasing the symptom.
| Pattern | What it looks like | Defensible counter |
|---|---|---|
| 1. Status-change-only closure | Developer marks the ticket done. No replay, no evidence, no second pair of eyes. | Verification mode field on the closure record. Closures without a verification mode entry surface in the queue dashboard. |
| 2. Self-attestation closure | Engineering owner certifies their own fix without independent verification. Acceptable for low-severity, unacceptable for control-evidence boundaries. | Severity-and-criticality policy that names where self-attestation is allowed. Attestation recorded explicitly on the closure record. |
| 3. Code-only verification | The fix is reviewed in the diff but never replayed against the deployed artefact. The code looks right; the deploy may not match. | Replay required against the deployed environment, not against the commit; for SAST findings, re-run on the merged branch. |
| 4. Single-payload replay | Original payload is replayed but adjacent variants on the same input are not. The headline payload fails; siblings still succeed. | CWE-class verification: replay payload variants in the same family (encoding, normalisation, alternate codec). |
| 5. Wrong-environment replay | Replay runs against staging but production has not shipped, or against production while the fix is staging-only. | Replay target named on the closure record. Mismatch against the original finding target surfaces as a verification gap. |
| 6. Different-credential replay | Original finding raised under an authenticated session; replay runs unauthenticated and returns clean for the wrong reason. | Credential context recorded on the original finding; replay must run against the same credential context to count. |
| 7. Stale-scanner closure | Next scheduled scan returns clean against a rule pack that no longer carries the original detection. Absence of finding read as fix. | Scanner version and rule pack version recorded on the original finding; replay must match or surpass the original detection. |
| 8. Evidence-free closure | Closure carries a status change, a date, an actor; no attached request and response, no scanner output, no commit reference. | Evidence attachment required for closure. Document storage on the finding holds the verification artefact. |
Each pattern produces a distinct signature in the verification audit chain. Status-change-only and evidence-free closures show as missing fields on the closure record. Self-attestation closures show as verifier-equals-remediation-owner. Code-only verification shows as commit-only references with no replay output. Single-payload, wrong-environment, and different-credential replays show as replay metadata that does not match the original finding context. Stale-scanner closures show as scanner version mismatches. Reading the patterns by signature lets the programme target the verification interventions to the patterns that actually appear in its closure data rather than to the patterns that show up in industry commentary.9,10,11
Three measurement axes that read fidelity honestly
A single fidelity number obscures the pattern breakdown. Reading fidelity across three independent axes separates evidence-completeness gaps from replay-correctness gaps and from scope-coverage gaps. Each axis has a different intervention path, and the diagnostic value is in the breakdown rather than in the aggregate.
| Axis | What it measures | Defensible benchmark |
|---|---|---|
| Evidence completeness | Share of closed findings whose closure record carries replay evidence (request and response, scanner-confirmed absence, commit reference plus verifier note). | Above 90 percent across severities; 100 percent on critical findings. |
| Replay correctness | Share of closed findings whose replay used the original payload class, original environment, and original credential context. | Above 85 percent across severities; 100 percent on critical findings. |
| Scope coverage | Share of closed findings whose verification covered the affected scope captured on the finding (paths, endpoints, parameters, config keys, dependency versions) rather than only the original instance. | Above 80 percent on findings with explicit scope capture; 100 percent on critical findings. |
The axes are independent enough that a programme can hit the benchmark on one and miss it on the others. High evidence completeness with low replay correctness means closures carry evidence but the evidence is of the wrong replay. High replay correctness with low scope coverage means individual replays are clean but partial fixes are slipping through. High evidence completeness and replay correctness with low scope coverage means the verification act is rigorous on the wrong scope. Reading the three together produces a diagnostic the headline number cannot.9,10,13
Fidelity at closure trades with scanner cadence post-closure
Verification fidelity at closure time and scanner cadence after closure are substitutes inside a defensible programme. The pair carry the durability signal between them; cutting both at the same time is the pattern that compounds invisible exposure.
High fidelity at closure, slow scanner cadence after
The closure record carries replay evidence, correct replay context, and full scope coverage. The next scheduled scan against the same target lands a quarter later. The programme can defend the durability of the closure on the strength of the closure-time verification; the next-scan signal is supplementary rather than primary. Most mature enterprise vulnerability programmes operate in this quadrant because closure-time verification scales linearly with finding volume and quarterly scan cadences scale cheaply.
Low fidelity at closure, frequent scanner cadence after
Closures land on weaker evidence but the next authenticated or external scan against the same target runs daily or weekly. The next-scan signal substitutes for the closure-time verification: the programme accepts that some closures are wrong and relies on the cadence to catch the failure mode within days. This quadrant is defensible only when the asset class supports frequent scanning, when the scanner coverage matches the original detection, and when the regression cost between scans is contained. Programmes operating in this quadrant on quarterly-scan assets are deferring the durability question rather than answering it.
High fidelity at closure and frequent scanner cadence after
The strongest defensibility quadrant; the closure carries proof and the cadence confirms the proof holds. The cost is real (verification labour plus scan capacity), and programmes that need this level are typically operating in regulated environments where the audit chain has to read at every quarterly cycle. The intermediate position is to reserve this quadrant for critical assets and to operate the high-fidelity-slow-cadence quadrant for the rest of the estate.
Low fidelity at closure and slow scanner cadence after
The compounding-invisible-exposure quadrant. Closures land on weak evidence; the next scan that could catch the failure mode is months out; regression and partial-fix closures sit undetected through multiple reporting cycles. The headline metrics report healthy closure cadence; the durability signal stays hidden until the next pentest or the next audit cycle catches the population. The intervention is to lift one axis (either fidelity at closure or scanner cadence after) rather than to optimise the headline cadence further.
Fidelity varies by finding class
Verification fidelity is not uniform across the finding catalogue because the cost of high-fidelity replay varies with the vulnerability class. Programmes that report a single aggregate fidelity number hide a distribution that the leadership read and the audit read both benefit from seeing decomposed.
- Configuration findings (TLS settings, security headers, exposed endpoints, default credentials, weak cipher suites) verify cheaply with a one-shot scan and tend to operate at high fidelity. Replay-correctness and scope-coverage are usually satisfied with the same scan that detected the original.
- Injection findings (SQL injection, command injection, server-side template injection, XML external entity, server-side request forgery) verify at moderate fidelity because adjacent payload variants need to be replayed alongside the original. The CWE-class-verification discipline catches the variants the headline payload does not.
- Authentication and authorisation findings (broken access control, privilege escalation, session fixation, insecure direct object reference, missing function-level access control) verify at lower fidelity because the replay needs the original authentication context and a comparable user-state harness. Different-credential replays are the most common failure mode in this class.
- Logic findings (business process bypass, multi-step workflow flaws, race conditions, state machine violations) verify at the lowest fidelity because the replay needs the original user journey and the original application state. Single-payload and wrong-environment replays concentrate here, and self-attestation is most common because the replay cost is high.
- Dependency findings (vulnerable transitive dependencies, outdated runtime versions, vulnerable container base images) verify at moderate fidelity with code scanning if the SCA tool confirms the upgrade path lands the patched version on the affected component. Code-only verification is a common failure mode because the diff shows the version bump but the deployed artefact may still ship the old version under a transitive lockfile.
Reading fidelity by class lets the programme allocate verification effort to the classes where the failure modes concentrate rather than spreading effort uniformly across the catalogue. The leadership report that decomposes fidelity by class also reads honestly to the audit committee, which expects to see where the verification work concentrates and where the verification gap lives rather than seeing a single number that flatters one class at the expense of another.9,10,13
Self-attestation: where it works and where it does not
Self-attestation (the developer or engineering owner certifying their own fix without independent verification) is the most contested closure mode in enterprise verification programmes. It is appropriate for some classes and inappropriate for others. The policy that scales splits self-attestation by severity and asset criticality rather than allowing it everywhere or banning it everywhere.
| Severity | Asset criticality | Defensible closure mode |
|---|---|---|
| Critical | Any | Independent verification with replay evidence; no self-attestation; closure record carries verifier identity distinct from remediation owner. |
| High | Production-critical or regulated asset | Independent verification with replay evidence; self-attestation only with documented exception and approval recorded on the closure record. |
| High | Internal or low-criticality asset | Independent verification preferred; self-attestation acceptable with closure-record attestation field populated. |
| Medium | Production-critical or regulated asset | Self-attestation acceptable; closure-record attestation field populated; periodic spot-check verification of sample. |
| Low or informational | Any | Self-attestation acceptable; closure-record attestation field populated; aggregate trend monitored rather than individual closures. |
The split keeps verification labour proportionate to closure risk while keeping the closure record honest about which closures landed under which evidence regime. Aggregate fidelity reporting then separates the self-attested cohort from the independently-verified cohort so the leadership read shows where the evidence is strongest and where the programme depends on attestation rather than replay.
Partial fixes and the scope-capture discipline
Partial fixes are the highest-frequency low-fidelity pattern in programmes that close findings against the first observed instance rather than against the full surface where the vulnerability manifests. A SQL injection finding raised against one query parameterised against one developer task closes the single-instance verification cleanly, then a scheduled scan or a subsequent pentest finds five sibling queries on the same surface. The closure record reads as verified; the durability data shows the partial-fix signature in the next scan window.
The structural fix is to capture the affected scope on the finding at intake rather than at verification. Scope capture is a small set of fields that the original triage records when the finding is opened.
- File paths or code locations for SAST findings; the verifier checks each named location rather than only the headline location.
- Endpoint patterns or URL templates for DAST findings; the verifier replays against each pattern rather than only the headline endpoint.
- Parameter names or input identifiers for injection findings; the verifier confirms each parameter rather than only the headline parameter.
- Configuration keys or settings names for configuration findings; the verifier confirms each key rather than only the headline key.
- Dependency names or version ranges for SCA findings; the verifier confirms each affected package rather than only the headline package.
Findings that close without scope capture default to single-instance verification and the closure record records the scope-capture gap explicitly. This keeps the auditor reading the limitation rather than inferring it, and it keeps the programme honest about which closures cover the vulnerability class and which cover the headline instance. Scope capture is a small intake-time investment that pays multiple cycles later when the partial-fix signature stops appearing in the durability data.9,10,13
The audit-evidence implications of fix verification fidelity
Audit fieldwork against PCI DSS, ISO 27001, SOC 2, and NIST controls reads verification evidence as a control-effectiveness signal rather than only as an operational artefact. The 2025 and 2026 reading of ISO 27001 Annex A 8.8 and SOC 2 CC7.1 increasingly expects that closures carry the verification artefact on the same record the original finding lives on, that the verifier is named and distinct from the remediation owner where the severity warrants it, and that the closure record carries the replay context (target, credentials, scanner version, rule pack) needed to reproduce the verification.
- PCI DSS v4.0 Requirement 6.3.3 expects the entity to address vulnerabilities through a risk-ranked process; the assessor reads closure evidence as part of that process and an evidence-free closure landscape lowers the assessor confidence that the process is operating.5
- ISO 27001:2022 Annex A 8.8 requires management of technical vulnerabilities; the audit fieldwork increasingly reads closure verification as part of the management evidence, not as a separate artefact. Closures without replay evidence are read as a control gap.7
- SOC 2 CC7.1 expects detection of vulnerabilities and tracking of remediation; auditors reading the trust-services criteria in 2025 and 2026 increasingly expect verification before closure rather than closure-then-verification.8
- NIST SP 800-53 RA-5 and SI-2 expect vulnerability scanning and flaw remediation; the assessor reads the closure record as the artefact that ties the scan detection to the remediation action, and missing verification breaks the linkage.3,4
Programmes whose closure records carry the verification artefact answer the audit question reproducibly across cycles. Programmes whose closure records are date stamps without verification artefact answer the audit question speculatively, which is the pattern that makes the fieldwork response costly and the management-letter findings repeat across years.11
Paired reporting: throughput, durability, and fidelity
The leadership report that survives reporting cycle after reporting cycle decomposes vulnerability remediation into three independent axes rather than reporting a single closure cadence. Each axis answers a different question, and the three together answer the question the closure cadence alone cannot.
| Axis | Question it answers | Source metric |
|---|---|---|
| Throughput | How quickly do findings close. | In-SLA closure rate per severity; median and 90th-percentile MTTR per severity. |
| Durability | Do closed findings stay closed. | 30-day reopen rate, 90-day reopen rate, 180-day reopen rate per severity. |
| Fidelity | Does the closure record carry proof the fix worked. | Evidence completeness, replay correctness, scope coverage per severity. |
The three axes are independent enough that a programme can be strong on one and weak on the others. High throughput with low fidelity is the fast-and-undefendable pattern. High throughput and high fidelity with low durability points to a regression-prone codebase or an environment-drift pattern downstream of closure. High durability with low fidelity usually means the scanner cadence is covering for the verification gap, which works until the next pentest or the next audit cycle. Reading the three together lets the programme allocate intervention to the axis that needs it rather than re-optimising the axis that already passes the benchmark.18,19
How the engagement record carries fix verification fidelity
Fix verification fidelity reads honestly only when the verification artefact, the replay context, and the closure metadata live on the same record as the original finding. The platform pattern that supports this is to pair every retest to the original finding rather than to open a new record, to record the verification method on the closure (independent replay, self-attestation, scanner-confirmed absence), and to keep the activity log carrying the timestamped state changes by user so the closure chain is reproducible at every audit cycle rather than reconstructed from chat and ticket archives.
SecPortal findings management captures the CVSS 3.1 vector, severity band, owner, evidence, asset binding, source class, recurring detection identity, and remediation status on a single finding record. The retesting workflows feature pairs each retest to the original finding rather than opening a new record so the closure evidence attaches to the same identity the original capture lives on and the activity log records the verification state changes on the same chain as the original triage.14,15
The activity log captures the timestamped chain of state changes by user across finding, engagement, scan, document, comment, and team entity types, with CSV export, so the closure act and the verification act are visible as discrete events on the same finding record. The authenticated scanning feature replays the original detection against the same target under the same credential context so the replay reproduces the original finding context rather than approximating it, and the code scanning feature re-runs Semgrep against the new commit so SAST and dependency findings verify against the deployed change.14,16
The compliance tracking feature maps findings to ISO 27001 Annex A 8.8, SOC 2 CC7.1, PCI DSS Requirement 6.3.3, NIST SP 800-53 RA-5, and other framework controls with CSV export, so the verified-fix evidence reads against the relevant control without requiring a separate evidence reconstruction at audit fieldwork.
The operational discipline that turns these features into a defensible fidelity programme is the vulnerability fix verification workflow. It names the four-state verification outcome (verified fixed, partially fixed, not fixed, regressed), the replay protocol that ties closure to the original attack path rather than to a developer ticket, and the closure-record fields that carry the verifier identity, the verification method, the replay timestamp, and the replay evidence so the fidelity question is answered at the moment of closure rather than at the next audit.17
Honest scope: what SecPortal does and does not do for fidelity
The platform discipline that supports fidelity has limits, and the limits matter for the audit conversation. SecPortal keeps the closure record, the verification artefact, the replay evidence, and the framework mapping on one engagement record. It does not invent verification capabilities that require infrastructure SecPortal does not run.
- SecPortal does not automatically classify a closure as verified. Closure is a user action with a verification method recorded by the user; the platform supplies the record and the audit chain, not the classification.
- SecPortal does not block administrative close at the platform level. Closure-discipline policy is programme policy; the platform records every state change in the activity log so the closure-without-verification pattern is observable in the data rather than enforced at the input layer.
- SecPortal does not auto-replay the original payload on demand. Replay is a user action (manual re-test, scheduled scan, code scan trigger); the platform records the result and pairs it to the original finding.
- SecPortal does not integrate with deployment systems to pull commit-to-deploy metadata. The replay target and the commit reference are user-entered on the verification; the platform records them on the closure but does not infer them from a CI/CD telemetry layer.
- SecPortal does not ship packaged Jira, ServiceNow, Slack, PagerDuty, or Opsgenie connectors. The activity log and the finding comments and collaboration carry the closure conversation on the platform; external workflow systems are not synchronised through a built-in integration.
The honest scope is the floor of what the audit conversation can defend on platform evidence alone. Programmes that need higher fidelity than the floor combine the platform record with adjacent verification labour, third-party scanner cadence, or programme policy that names the closure preconditions the platform records rather than enforces.11,12
For internal security and vulnerability management teams
Internal security and vulnerability management leads carry the fidelity question alongside the throughput and durability questions. The pattern that survives reporting cycle after reporting cycle is to make verification evidence a precondition for closure where the severity warrants it, to read fidelity across the three axes rather than as a single number, and to treat fidelity at closure and scanner cadence after closure as substitutes rather than as parallel demands.
- Capture verification mode on every closure record (independent replay, self-attestation, scanner-confirmed absence) so the closure type reads alongside the closure date.
- Record the replay context (target, credential context, scanner version, rule pack) on every replay so the next reader can confirm the replay matched the original detection.
- Capture affected scope (paths, endpoints, parameters, configuration keys, dependency versions) on the finding at intake so partial fixes surface before closure rather than at next scan.
- Read evidence completeness, replay correctness, and scope coverage separately by severity rather than as an aggregate fidelity score.
- Pair the in-SLA closure rate with the 30-day reopen rate and the evidence completeness rate so the throughput, durability, and fidelity axes appear together in every leadership report.
- Split self-attestation policy by severity and asset criticality so verification labour is proportionate to closure risk rather than uniform across the catalogue.
For internal security teams, vulnerability management teams, AppSec teams, product security teams, and security engineering teams, the operating commitment is to keep the verification artefact and the closure record on the same engagement record so the fidelity question can be answered without a metrics-collection sprint. The vulnerability remediation throughput research covers the throughput axis of the same paired-metric frame; the vulnerability reopen rate research covers the durability axis; this research covers the fidelity axis.18,19
For security leadership and audit committees
Security leaders and audit committees read fidelity through the defensibility lens. The leadership read is whether the closure record carries proof the fix worked, not only whether the closure landed on schedule. A programme reporting 95 percent in-SLA closure alongside 40 percent evidence completeness is reporting throughput without defensibility, and the audit committee should read the gap rather than reading the headline.
- Track in-SLA closure rate, 30-day reopen rate, and evidence completeness rate as three separate lines rather than as one composite score.
- Read replay correctness and scope coverage as diagnostic axes when evidence completeness drops below the benchmark.
- Investigate every critical closure with incomplete evidence individually; the target on critical findings is zero closures without complete evidence and correct replay context.
- Pair the fidelity report with the exception register growth to read whether closure pressure is being released into the residual-risk ledger rather than into the verification queue.
- Tie verification tracking to the same engagement record the audit evidence comes from so the leadership read and the audit read are the same record rather than two reports.
The leadership question that drives this discipline is whether the closure record can answer the fidelity question reproducibly across reporting cycles. If it can, the durability conversation is grounded and the audit fieldwork response is routine. If it cannot, the closure record is a date stamp and the fidelity question deflects to a verification-quality conversation that the team has to run on tribal knowledge rather than on data. The audit evidence half-life research covers the evidence-currency dimension of the same operational discipline.
The leadership-side platform discipline that supports this is covered on SecPortal for CISOs and security leaders, which describes how findings, retests, exceptions, and reporting hold the defensible read of programme health between reporting cycles rather than only at quarterly review week. The security engineering handoff latency research covers the upstream dimension that compounds with fidelity gaps when the verification queue depends on a handoff the closure pressure has already stretched. The companion retest cost decomposition research covers the cost side of the same verification cycle, breaking the price of a defensible closure into the seven primary cost components plus the authentication overhead so the fidelity discussion can be paired to the budget discussion rather than left as two separate operational debates.
Conclusion
Vulnerability fix verification fidelity is the third axis of vulnerability remediation alongside throughput and durability. Throughput answers the speed question; durability answers the post-closure question; fidelity answers the verification-act question. The three together separate fast-and-defensible programmes from fast-and-undefendable programmes without requiring a tribal-knowledge interpretation of the numbers. Fidelity fails through eight recurring patterns (status-change-only, self-attestation, code-only, single-payload, wrong-environment, different-credential, stale-scanner, evidence-free closure), and reading fidelity across the three axes (evidence completeness, replay correctness, scope coverage) separates the patterns without instrumenting them individually.5,7,8,9
Treating fidelity as a property of the live engagement record rather than as an assumption baked into the in-SLA closure rate is the highest-leverage discipline for defensible remediation evidence. Verification mode on every closure, replay context on every replay, scope capture on every finding, and paired reporting against throughput and durability each tighten the metric. The platform you use does not have to pick the verification policy or the benchmark for the programme. It does have to keep the closure record, the verification artefact, the replay evidence, and the framework mapping on one engagement record so the fidelity question is reproducible at any moment between reporting cycles.
Frequently Asked Questions
Sources
- NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment
- NIST, SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- NIST, SP 800-53 Revision 5: RA-5 Vulnerability Monitoring and Scanning
- NIST, SP 800-53 Revision 5: SI-2 Flaw Remediation
- PCI Security Standards Council, PCI DSS v4.0 Requirement 6.3.3
- PCI Security Standards Council, PCI DSS v4.0 Requirement 11.3 Penetration Testing
- ISO/IEC, ISO 27001:2022 Annex A 8.8 Management of Technical Vulnerabilities
- AICPA, SOC 2 Trust Services Criteria CC7.1 Detection of Vulnerabilities
- OWASP, Vulnerability Management Guide
- OWASP, Web Security Testing Guide (WSTG)
- NCSC, Vulnerability Management Guidance
- CISA, Stakeholder-Specific Vulnerability Categorization (SSVC)
- MITRE, CWE Common Weakness Enumeration
- SecPortal, Findings & Vulnerability Management
- SecPortal, Retesting Workflow Feature
- SecPortal, Activity Log & Workspace Audit Trail
- SecPortal, Vulnerability Fix Verification Workflow
- SecPortal Research, Vulnerability Reopen Rate
- SecPortal Research, Vulnerability Remediation Throughput
Run high-fidelity fix verification on the live engagement record
SecPortal keeps closures, retest evidence, replay context, and framework mappings paired to one versioned engagement record so the fidelity question is reproducible at any moment between reporting cycles and the chain does not depend on a metrics layer that diverges from operational reality.