diff --git a/.planning/phases/03-api-layer/03-CONTEXT.md b/.planning/phases/03-api-layer/03-CONTEXT.md
new file mode 100644
index 0000000..4033a46
--- /dev/null
+++ b/.planning/phases/03-api-layer/03-CONTEXT.md
@@ -0,0 +1,61 @@
+# Phase 3: API Layer - Context
+
+**Gathered:** 2026-02-24
+**Status:** Ready for planning
+
+<domain>
+## Phase Boundary
+
+Admin-authenticated HTTP endpoints expose health status, alerts, and processing analytics. Existing service processors (jobProcessorService, llmService) emit analytics events at stage transitions without changing processing behavior. The admin dashboard UI that consumes these endpoints is a separate phase.
+
+</domain>
+
+<decisions>
+## Implementation Decisions
+
+### Response shape & contracts
+- Analytics endpoint accepts a configurable time range via query param (e.g., `?range=24h`, `?range=7d`) with a sensible default
+- Field naming convention: match whatever the existing codebase already uses (camelCase or snake_case) — stay consistent
+
+### Auth & error behavior
+- Non-admin users receive 404 on admin endpoints — do not reveal that admin routes exist
+- Unauthenticated requests: Claude decides whether to return 401 or same 404 based on existing auth middleware patterns
+
+### Analytics instrumentation
+- Best-effort with logging: emit events asynchronously, log failures, but never let instrumentation errors propagate to processing
+- Key milestones only — upload started, processing complete, processing failed (not every pipeline stage)
+- Include duration/timing data per event — enables avg processing time metric in the analytics endpoint
+
+### Endpoint conventions
+- Route prefix: match existing Express app patterns
+- Acknowledge semantics: Claude decides (one-way, toggle, or with note — whatever fits best)
+
+### Claude's Discretion
+- Envelope pattern vs direct data for API responses
+- Health endpoint detail level (flat status vs nested with last-check times)
+- Admin role mechanism (Firebase custom claims vs Supabase role check vs other)
+- Unauthenticated request handling (401 vs 404)
+- Alert pagination strategy
+- Alert filtering support
+- Rate limiting on admin endpoints
+
+</decisions>
+
+<specifics>
+## Specific Ideas
+
+No specific requirements — open to standard approaches. User trusts Claude to make sensible implementation choices across most areas, with the explicit constraint that admin endpoints must be invisible (404) to non-admin users.
+
+</specifics>
+
+<deferred>
+## Deferred Ideas
+
+None — discussion stayed within phase scope
+
+</deferred>
+
+---
+
+*Phase: 03-api-layer*
+*Context gathered: 2026-02-24*