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

Evidence Timestamp Staleness

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.

Counts the tenant’s stored timestamp tokens whose TSA generation time (the store time for a token that did not parse) is older than the installation’s re-timestamp window. 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) and on demand through the Timestamp Assurance API.

What it measures

Fails with the count and up to ten bundle ids when any token is older than EvidenceTimestampMaxAge (default 365 days).
Passes when the tenant stores no timestamped evidence.

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

inventory.tokenCount
staleness.maxAgeDays
staleness.staleCount
staleness.staleBundles

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

Common causes

Evidence retained longer than the window without renewal.

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).

This window is a product warning. Counsel fixed the re-timestamp TRIGGER as the earliest loss-of-verifiability event (an algorithm sunset, an expired signer), so a stale token is reported here but is not planned for re-timestamping by itself.

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.staleness")'

# 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)
Re-timestamp Work Pending (doctor.evidence.timestamp.evidence.retimestamp-pending)

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.