checkId: doctor.evidence.timestamp.evidence.retimestamp-pending family: doctor-check/v1 service: evidence-web scope: tenant severity: warning tags: [timestamping, evidence, re-timestamp, queue, tenant]

Re-timestamp Work Pending

Stella Ops is self-hosted software. It does not issue electronic time stamps or provide any qualified trust service. This deployment performs local verification using operator-supplied evidence. Unless an approved jurisdiction-, provider-, service-, and deployment-specific claim profile applies, qualified status is not determined.

Reads the tenant’s re-timestamp work queue: pending items past their planned time by more than the grace, failed items, and the oldest planned time. Planning enqueues candidates daily; nothing executes them until remediation is approved, so pending work is an honest operator signal. Default severity when it fails: warning. Tenant-scoped: one result per tenant under that tenant’s row-level security, recorded by the worker schedule tenant-evaluation (hourly); planning runs daily and on demand through the Timestamp Assurance API.

What it measures

Fails when any pending item is overdue by more than RetimestampOverdueGrace (default 1 day).
Fails when any item is in the failed state.

The check never reports a pass for a value it does not have. When its source cannot be read it reports unhealthy with the message Source unavailable (<reason>): <detail>. No verdict can be reported. and the evidence keys source.state=unavailable, source.reason (one of source-not-configured, source-configuration-invalid, unavailable-by-sealed-policy, source-material-invalid, source-read-failed) and source.detail.

Evidence keys

retimestamp.pendingCount
retimestamp.overdueCount
retimestamp.failedCount
retimestamp.overdueGraceDays
retimestamp.oldestPlannedAt

Every value is a bounded measurement or pointer; no token bytes, trust material or credentials appear in evidence.

Common causes

Candidates were planned and remediation is not enabled (expected until it is approved).
A previous execution attempt failed.

Configuration

Thresholds live in Evidence__TimestampAssurance__Policy__* and default to the values the retired Doctor plugin used (carried verbatim so a cadence or threshold change is always a visible edit).

Planning derives candidates from counsel’s loss-of-verifiability events only (an algorithm sunset, an already-expired signer) under the queue’s content key, so a daily re-plan never duplicates work.

How to verify

The five tenant checks are evaluated for the caller’s tenant only, under that tenant’s row-level security, and served by the Timestamp Assurance API through the gateway (evidence:read; a fresh run needs evidence:create). The worker also records a run per tenant every hour under the key schedule:tenant-evaluation:<bucket>.

# Latest recorded run for your tenant
curl -sS -H "Authorization: Bearer $EVIDENCE_READ_TOKEN" \
  https://stella-ops.local/api/evidence/v1/timestamp-assurance/status \
  | jq '.checks[] | select(.checkId == "doctor.evidence.timestamp.evidence.retimestamp-pending")'

# Evaluate now (idempotent on the key; a replay returns the same run)
curl -sS -X POST -H "Authorization: Bearer $EVIDENCE_CREATE_TOKEN" -H "Content-Type: application/json" \
  -d '{"idempotencyKey":"manual:'"$(date -u +%Y%m%dT%H%M%SZ)"'"}' \
  https://stella-ops.local/api/evidence/v1/timestamp-assurance/runs

Token Signer Expiry (doctor.evidence.timestamp.evidence.token-expiry)
Token Deprecated Algorithm (doctor.evidence.timestamp.evidence.deprecated-algorithm)

This is a local evidentiary classification of the token and issuing service at the stated time. It is not the output of a qualified validation or qualified preservation service and does not determine the legal effect of the underlying release, document, or transaction.