Live Cutover Log¶
2026-08-22 — Dispatcher target configured¶
The Railway @nirog/dispatcher service was configured with OCR_WORKER_URL set to https://nirogocr-2vq43ahc.manus.space; its configuration deployment completed successfully. The Core source commit 940ac7c (feat(ocr): prepare Core dispatch for live OCR Ops) was then deployed successfully, passing its /health/live health check. No evidence bytes, secrets, or patient data were used during this configuration operation.
The pending final verification is a deployed Core event through the dispatcher, OCR Ops authenticated intake, Core-issued lease and evidence access, Gemini extraction, human review, and confirmed-only Core receipt.
Controlled-evidence verification status¶
The initial primary-web session showed no active profile, and its client navigation reset before a profile or evidence workflow could be opened. No test evidence, patient record, or OCR job was created by this attempt. The cutover remains deployed; the final verification must use an authenticated Core workflow with a deliberately controlled evidence fixture and a valid profile context.
The authenticated primary-web workspace subsequently exposed one existing controlled profile, Competition OCR Smoke Test, and selected it as the active profile context. No evidence submission has yet been made from that profile.
The Core-owned evidence workspace loaded the same controlled profile and its existing Competition OCR smoke test prescription. The upload control is available; no upload has been submitted yet.
The first browser upload attempt did not submit a file because the generated synthetic fixture was outside the browser upload-accessible workspace. The fixture was moved into the allowed workspace path for a retry; the Core evidence list was unchanged by the failed attempt.
The controlled synthetic PNG upload was accepted by the Core evidence workspace. Immediately after submission, the UI remained in its Core-authoritative loading state and no OCR review packet was yet visible; no human review or Core receipt was submitted.
A browser-side metadata check confirmed that the controlled upload reached Core with a processing evidence status. Its extraction collection was still empty at the time of inspection. The next verification step is to inspect the dispatcher and OCR Ops runtime logs for the emitted Core event and authenticated intake outcome.
Railway dispatcher logs confirmed that the event was claimed and retried, with delivered: 0 and retryScheduled: 1 on successive outbox cycles. This proves Core emitted the event but the delivery has not completed. The current investigation is limited to the authenticated delivery boundary; no additional evidence upload or review action will be made while the retry is unresolved.
The shared-secret precedence correction was published and the OCR Ops health endpoint returned HTTP 200. The dispatcher continued to claim the event but did not report a successful delivery in the observed log window. The next diagnostic step is to inspect the refreshed OCR Ops request log and the Core dispatcher’s current effective secret configuration without disclosing secret values.
The refreshed OCR Ops request log recorded the retried internal event as HTTP 401 after the precedence release. The Core dispatcher service exposes a project-level shared internal worker identity as available but not yet applied to that service; applying the existing sealed shared identity is the next configuration correction. No secret value has been viewed or recorded.
The first attempt to reopen the dispatcher variable page reset the browser session before any variable control was loaded. No additional Railway configuration change was applied by that navigation attempt.
After the Railway session recovered, the dispatcher shared-variable panel confirmed that the sealed NIROG_INTERNAL_WORKER_SECRET is the sole available shared variable and is currently applied to zero services. Its value remains hidden. Applying that existing project secret to the dispatcher is required to replace the stale service-local identity that caused the HTTP 401 delivery retries.
The sealed shared NIROG_INTERNAL_WORKER_SECRET has now been attached to the dispatcher service, changing the panel to one shared variable in use. Railway staged this as one configuration change; the identity value was not displayed. The final apply/deploy action remains pending.
The staged identity configuration was applied with explicit confirmation. Railway completed the resulting dispatcher deployment successfully. The next observation is the pending Core outbox event’s retry outcome against OCR Ops; no further evidence submission is required.
Lease authorization root cause and remediation¶
The Core dispatcher’s active runtime was verified to hold the expected dedicated dispatch credential through a short non-reversible fingerprint, and a direct empty-payload probe against OCR Ops returned HTTP 422 rather than HTTP 401. This proved the dispatcher-to-OCR Ops intake guard was accepting the configured identity.
The recurring HTTP 401 entries on the OCR Ops intake route were then traced to the subsequent Core evidence-lease call made after authenticated intake, not to the intake guard itself. OCR Ops was using the shared internal worker credential for the Core lease, evidence-access, and result calls; that credential did not match the active Core route authorization boundary. The scoped fix introduces a distinct OCR Ops-to-Core credential accepted only by Core's internal OCR lease, evidence-access, and result endpoints, preserving the shared internal credential for its existing review-correlation signing role.
The scoped Core authorization change was covered by Core configuration and HTTP authorization tests, including a runtime-provided credential test. The Core API source release feat(ocr): scope ops lease credential was approved in Railway and entered the build phase. The new scoped credential was configured server-side in OCR Ops and Core without recording its value here. Final verification resumes after the Core API deployment becomes active.
Dispatcher and service-placement verification¶
The rebuilt Railway dispatcher was verified to use the intended public OCR Ops origin and the expected non-reversible dispatch-credential fingerprint. A direct empty-payload request with that same credential returned HTTP 422 from OCR Ops, proving the live private intake guard accepts the identity before schema validation.
The controlled outbox event nevertheless dead-lettered after its retried delivery attempt. Investigation resolved the apparent contradiction: the scoped OCR Ops-to-Core credential was initially added to Railway's separate nirog-core service, while the live protected evidence lease routes are served by the distinct @nirog/api service. The scoped authorization code is active in @nirog/api, but that service showed no configured scoped credential. OCR Ops therefore accepted dispatcher intake but received a 401 from Core when attempting its subsequent evidence lease; the dispatcher surface reflected the synchronous intake failure.
The next controlled step is to configure the already-generated server-only scoped credential on the @nirog/api Railway service, deploy it, requeue the single controlled event, and then verify review-pending creation before any human confirmation or Core receipt delivery. No credential value is recorded in this log.
Corrected Core API credential placement and replay handling¶
The replacement scoped credential is now configured on the actual @nirog/api service and its Railway restart completed successfully. A temporary Vitest authorization probe against an otherwise unknown lease identifier passed: Core rejected the resource lookup rather than the scoped credential, establishing that the credential crossed the intended authorization boundary without reading evidence. A direct identifier-only lease probe for the controlled Core job subsequently returned HTTP 201.
The controlled event was accepted by OCR Ops intake (HTTP 202) after the credential correction. Its first prior OCR Ops job had already been persisted as failed during the earlier lease-authentication incident, which exposed a retry semantics defect: a replayed outbox event returned the stored failed job rather than resuming it. OCR Ops now reopens only a failed, packet-less Core-correlated job on a replay, preserving the same idempotency binding and preventing duplicate review packets or clinical actions. The behavior is covered by a focused test that simulates a temporary lease failure followed by successful replay.
The revised replay behavior is pending OCR Ops publication and controlled live re-verification. The prior short-lived manual authorization lease uses Core’s standard 60-second worker lease duration and has expired; no evidence content was accessed during the authorization probe.
Controlled extraction recovery and receipt-boundary status¶
The controlled job exposed an additional Core recovery gap: an interrupted worker lease remained in the leased state after expiry, making the job unavailable to a later worker. Core now permits a lease claim only when the job is queued, retry-scheduled, or currently leased and its lease expiry is already in the past. The focused Core suite passed after this correction, and the active @nirog/api deployment contains it.
The controlled event subsequently completed the live Core lease, temporary evidence read, Gemini extraction, strict-output validation, deterministic medication match, and Core result submission path. OCR Ops produced a mandatory review_pending packet with an Acetaminophen candidate, then the explicitly attributed verification operator confirmed it. No medication, regimen, diagnosis, reminder, or other clinical record was created automatically.
The initial confirmed-only receipt boundary investigation found that a bodyless correlation POST carrying an application/json content type was rejected by Core's JSON parser before the route handler ran. Core now accepts that empty transport body at the evidence-route boundary while preserving declared request-body validation. The primary web companion permits only the exact profile-, evidence-, and job-scoped correlation route through its authenticated Core proxy.
The controlled correlation request then returned successfully with a short-lived signed assertion. A direct browser-to-OCR Ops receipt attempt was intentionally not retained because it was blocked by the browser's cross-origin boundary; the primary web companion now provides an authenticated, server-side relay for the identifier-only receipt. The relay does not persist or return the assertion.
The first delivery attempts occurred before the updated OCR Ops runtime was active and were rejected because the receipt adapter was incorrectly using the scoped evidence-operation identity. OCR Ops now routes receipt delivery through the separate Core review-boundary identity, while retaining the scoped identity solely for lease, evidence-access, and result calls. After the active deployment was confirmed, the controlled confirmed-only delivery returned a successful transport response. No assertion, credential, review text, or evidence content is retained in this log. Core receipt persistence and the no-clinical-mutation audit remain the final verification steps.
Final controlled receipt verification¶
Core runtime logs recorded the successful internal review-packet request as HTTP 201, which is emitted only after Core persists the identifier-only receipt. The controlled OCR Ops job remains human-confirmed. The Core command and focused regression tests confirm that this receipt path records only review provenance and does not call the medication, regimen, prescription, diagnosis, reminder, or other clinical-mutation paths.
One fresh assertion was then used for a controlled duplicate-delivery check. Core rejected the immutable duplicate, and OCR Ops exposed the result as HTTP 409. The duplicate response is a conflict, not a retry success, and it performs no second receipt write or clinical mutation. The completed flow is therefore: authenticated dispatch, temporary Core lease and evidence read, server-side Gemini extraction, deterministic matching, mandatory attributed human confirmation, one identifier-only Core receipt, and explicit duplicate rejection.
Read-only Core persistence and non-mutation audit¶
The final Core API release added a profile-authorized, aggregate-only receipt audit endpoint. It returns no evidence bytes, assertion, reviewer reason, candidate, or clinical record content. The live audit for the controlled profile/evidence/job returned HTTP 200 with exactly one receipt. It also returned zero records created at or after that receipt across prescriptions, regimens, regimen schedules, reminder schedules, dose logs, inventory movements, and refill alerts. The duplicate verification occurred before this audit and did not change the receipt count. This establishes, from Core persistence rather than transport behavior alone, that the controlled receipt and its rejected replay caused no clinical mutation.