TRUSTWEAVE SDK · 10 SEPTEMBER 2026
Shared host observability verified
Request traces, protected metrics, admission timing and pool diagnostics now have a reusable SDK implementation and executed host-level evidence.
Why the score increases
The preceding 9.0 assessment covered ledger metrics, safe status-list logs and local notification delivery. It still lacked a reusable host implementation for tracing, queue/pool diagnostics and protected export. This change closes those implementation gaps and adds verification under contention and exporter failure.
The 9.6 / 10 score is an engineering assessment of SDK instrumentation and local operability. It uses the same six-category rubric as the previous review. It does not mean the deployed service achieved a 99.9% SLO, that production retention was enforced, or that the on-call route was qualified.
- Six embedded HTTP hosts now expose an additive
withObservabilityconfiguration method. - Two real HTTP hosts produce correctly related spans and deliver authenticated OTLP protobuf to a local collector.
- Queue limits, cancellation, connection-pool wait/failure, protected scraping under overload and exporter backpressure have executed tests.
- Six new host alerts and explicit reference SLO definitions add actionable operational checks.
Scoring rationale and unchanged category weights · Previous assessment
Implementation
The new HostTelemetry collector uses fixed labels and bounded arrays. Its coroutine-aware spans record the host, phase, bounded HTTP method, outcome and generated request ID; request URLs, credentials, authorization headers, provider messages and stacks are excluded. Incoming request IDs are ignored. Remote trace parents require an explicit trusted-ingress setting; baggage is never extracted.
HostObservability exposes the metrics route only with a configured secret. Metrics remain available while application admission is saturated. Full queues and admission timeouts return 503 with Retry-After. Cancelled work returns permits. The optional DataSource wrapper measures acquisition without changing returned connections or transaction behavior.
Status-list errors reuse the host-generated request ID, linking the response body and header to the existing safe log and to the trace. Integration is explicit; existing server constructors and defaults remain unchanged. API comparison found exactly one added method per existing server, with zero removed signatures. The module is included in the BOM, but its runtime capability-catalog maturity remains unassessed; no supported-only deployment claim is introduced.
Executed evidence
| Check | Observed result |
|---|---|
| Coroutines and data exclusion | 40 concurrent requests; unique generated IDs; parent/child correlation survives dispatcher changes; private fixture fields absent. |
| HTTP to HTTP to collector | 2 real Netty hosts, 10 requests, 10 distributed traces and 40 related spans; authenticated OTLP HTTP/protobuf export; unauthorized collector request denied. |
| Admission correctness | Full-queue rejection, queued cancellation and 1,000 timeout/cancellation contenders across 100 cycles; no leaked permits. |
| Pool diagnostics | Actual single-connection Hikari/H2 pool saturated; waiting and acquisition timeout visible; subsequent query succeeds after release. |
| Management during overload | Actual status-list server rejects additional work while authenticated metrics stay reachable; error response, log and span correlate. |
| Bounded storage and exporter failure | 20,000 requests on 8 workers cause no metric-series growth. A blocked exporter with a 32-span queue drops excess spans observably while 10,001 phase operations complete. |
| Alert rules | 32 assertions pass for burn-rate windows, queue tail, pool saturation/missing instrumentation and healthy/idle/cancelled cases. Runtime metrics pass promtool exposition validation. |
OTLP summary · Decoded wire traces · Concurrent traces · Metric sample · Exporter drop evidence · Prometheus checks
Tests and compatibility
| Module | Tests | Failures / skips |
|---|---|---|
| observability | 9 | 0 |
| credentials/plugins/status-list/server | 5 | 0 |
| credentials/vc-api-server | 7 | 0 |
| credentials/oidc4vci-server | 14 | 0 |
| credentials/avp-authorization-server | 16 | 0 |
| did/registrar-server-ktor | 1 | 0 |
| trust-registry/trust-registry-server | 12 | 0 |
All 64 tests passed with zero failures, errors or skips. Seven affected modules passed lint and ABI checks; the BOM also passed lint. Existing lint baselines were not expanded. The whole SDK and SaaS test suites were not rerun. Previous intent-ledger and Alertmanager evidence remains historical and is not counted as a new run here.
Suites, source hashes, API additions and limits · Build log with commands
Updated scorecard
| Category | Before | Now |
|---|---|---|
| Security and access control | 9.0 | 9.0 |
| Observability and diagnosability | 9.0 | 9.6 |
| Reliability and scale | 9.0 | 9.0 |
| Configuration and data | 9.0 | 9.0 |
| Deployment and release | 8.5 | 8.5 |
| Testing and documentation | 8.5 | 8.5 |
The total is 53.6 / 6 = 8.9333, rounded to 8.9 / 10. Only observability is reassessed; the other categories are carried forward. The remaining 0.4 in observability retains meaningful operational limitations:
- Validate the deployed topology, actual provider/SaaS coverage and representative load. Application admission timing excludes earlier proxy, network and Netty queues.
- Agree SLO targets and tune alert thresholds with the deployment owner. The supplied 99.9% availability and 100 ms queue p95 are reference defaults.
- Enforce and verify backend retention, telemetry access and deletion. Proposed durations do not configure production backends.
- Verify firing, resolution and escalation through the real on-call route. Local collectors and receivers do not establish production delivery.
Each host must supply its exporter and bounded batch processor. This library does not install an OpenTelemetry SDK globally, start an exporter automatically, or create a durable audit ledger.