Expose Evidence Queue SLA Metrics

[Cedarich]

Complexity: Trivial (100)

Description
EvidenceQueueItem and EvidenceStatus model the evidence review pipeline, but there are no
metrics describing how long items wait or how the backlog is trending. Operators cannot tell
whether evidence review is keeping up with intake.

Acceptance Criteria

• Queue depth is exposed per EvidenceStatus
• Age of the oldest pending item is exposed
• Time from intake to decision is recorded as a histogram
• Metrics carry bounded label cardinality
• The metrics are documented alongside the existing observability docs

[shadrackmanfred]

@shadrackmanfred has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer! I'm a senior developer with experience building high-quality, production-ready software. I'd love to take on this issue and deliver a clean, well-tested solution that aligns with the project's standards. Please assign it to me—I'm ready to get started and contribute effectively.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @shadrackmanfred to this issue.

[ibochivincent-lang]

@ibochivincent-lang has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #954 because the evidence review pipeline currently has no clear operational metrics showing whether review capacity is keeping up with incoming work. Queue depth, item age, and end-to-end decision time would give operators a much better view of the system's health.

I will first review the existing EvidenceQueueItem and EvidenceStatus models, the evidence processing flow, and the current observability or metrics implementation to identify the best points for recording these measurements.

I will then add queue-depth metrics grouped by EvidenceStatus, making sure the labels use a small fixed set of status values so metric cardinality remains bounded.

For pending work, I will expose the age of the oldest pending evidence item so operators can quickly identify when the backlog is becoming stale. I will also record the time from initial intake through the final decision using a histogram, allowing the team to monitor review latency and establish useful SLA trends.

I will follow the project's existing metrics and telemetry conventions rather than introducing a separate monitoring mechanism. I will also ensure metrics do not include high-cardinality values such as user IDs, evidence IDs, or other per-item identifiers.

Finally, I will add or update tests for queue depth, oldest-item age, and intake-to-decision timing, including status transitions and empty-queue cases. I will document the new metrics alongside the existing observability documentation so operators understand their meaning and intended use.

My goal is to provide a small, reliable set of evidence-queue SLA metrics that clearly show backlog size, backlog age, and review latency without creating unnecessary monitoring overhead or high-cardinality telemetry.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @ibochivincent-lang to this issue.

[drips-wave]

Congratulations, @simeontech! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @simeontech: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊