# pg1-instrumented-metrics: Security & Architecture Audit

## Scope

Audit of the instrumented metrics pipeline addition. Focus areas: information exposure, resource exhaustion, and architectural fit.

## Findings

### Information Exposure

| Risk | Assessment |
|------|-----------|
| Signal type names exposed in /metrics | **Low** -- Signal type names are application-defined, not user data. Already exposed via schema. |
| User IDs in UserSignalTimestampMap | **None** -- User IDs are stored in memory only, never serialized to /metrics or /diagnostics output. |
| /diagnostics endpoint | **Low** -- Feature-gated behind `metrics`. Same access model as /metrics (unauthenticated, firewall-protected). Existing warning in http.rs covers non-loopback binding. |

### Resource Exhaustion

| Risk | Assessment |
|------|-----------|
| Per-type counter DashMap growth | **Mitigated** -- Bounded at 256 entries. Beyond 256 types, new types are silently dropped. |
| UserSignalTimestampMap growth | **Mitigated** -- Bounded at 10,000 entries. Sampling-based eviction keeps memory bounded at ~240KB. |
| Prometheus output size | **Low** -- Per-type counters add at most 256 lines. Percentile gauges add 18 lines (6 metrics x 3 percentiles). |

### Architectural Fit

- [x] Follows existing MetricsState pattern (Arc-shared atomics, feature-gated)
- [x] No cross-layer violations (metrics code stays in db/metrics/)
- [x] No new dependencies
- [x] Consistent use of `Relaxed` ordering for statistical counters
- [x] /diagnostics follows same HTTP server pattern as /healthz and /metrics

### Thread Safety

- [x] `UserSignalTimestampMap` uses `DashMap` (lock-free shard reads)
- [x] Per-type counter `DashMap<String, AtomicU64>` is safe for concurrent access
- [x] Eviction races are benign (worst case: slightly over cap, converges on next write)

## Verdict

**APPROVE** -- No security concerns. Resource usage is properly bounded. Architecture is consistent with existing patterns.