Assignment ADR-0053/delivery/007, coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc/local. After cleanup and expiry, root requested bounded READ-ONLY diagnosis of exact window c9c9d610-a217-49b4-9e65-96406f60b113. No new proof request, signature, window, activation or configuration mutation occurred. Original UNKNOWN and its separately verified cleanup remain unchanged.
The retained Vercel request log, bounded to 09:38:00Z through 09:39:05Z, returned one record for exact deployment dpl_aDWLBjzq5d72EtCoHavVHub8k6dR and project. It records POST on canonical delivery.sguildswim.com at /api/internal/adr0050/production-proof, epoch1791020301407 (09:38:21.407Z), HTTP404, source serverless, production, cacheMISS. Observable record ID is pkrrx-1791020301407-d4c63d9fa862. No separate request ID is asserted. Message and traceId are empty; nested logs are empty. No runtime error or stack is retained in this readback. The runner's original output preserved only UNKNOWN, without its HTTP status or specific caught error.
Read-only deployment metadata remains READY, exact project/team, production target, source ac047470a91eea55efa6826f7c8ef7b63287efa2, regioniad1 and Node24.x. Its env-name array has164 names and includes all seven temporary proof keys in both runtime/build metadata, plus VERCEL_ENV, VERCEL_DEPLOYMENT_ID, VERCEL_PROJECT_ID and VERCEL_OIDC_TOKEN. Names are not values, so this does not establish actual runtime values or request-context OIDC contents. No env value, credential, bearer or decrypted material was retrieved or recorded. Current project variables were already independently verified absent for all seven proof keys during cleanup.
The exact current adapter/route/service/runtime/repo/config files have zero Git diff from diagnostic sourceac04747; their hashes are recorded in the diagnosis artifact. Adapter admission and config/target checks silently return404, as do caught handler failures before reservation. Service checks signed approval, runtime metadata and SDK file hashes before awaiting restricted-role reservation. Reservation checks owner approval metadata, server clock, exact effective role and privileges. SDK context/acquisition work follows successful reservation. Existing audit readbacks contain the owner approval only, no reserved/completed row.
Consequently, the observable404 is consistent with multiple pre-reservation admission/config/SDK-integrity/DB-reservation denial or exception paths. The exact branch is unknown. A log label serverless establishes the provider's classification of the recorded request; it does not establish handler progress, successful deployed TLS authentication, reservation, SDK execution or workload acquisition. No cache, TLS, Supavisor, provider or build-constant cause is inferred, and no production retry is authorized.
Separate diagnosis artifact: docs/adr0053-workload-proof/results/2026-10-03-tls-acquisition-readonly-diagnosis.json, SHA256 efee4184f508eaa8c55cda5259163323a1eeb140715a704a91f43e0f8c987728. It preserves sanitized request data, exact deployment metadata/name-only evidence, raw local readback pins and source hashes. Original outcome and cleanup artifacts are not rewritten. Root may disposition the retained diagnostic after preserving this evidence. Workload/exchange and activation gates remain open. Root is sole canonical publisher/indexer.