Skip to content

Core Integration Audit Notes

Initial live observations

On 2026-08-22, the deployed Nirog web smoke endpoint returned its expected evidence-ID validation response rather than a Core configuration error. This confirms that the web deployment has a configured Core bridge and can evaluate its server-side Core request path.

The deployed OCR Ops API was independently reachable at /api/v1/health. The Railway browser project page did not expose deployment information in the available session, so a credentialed, live receipt submission has not been attempted during this audit.

Code-contract observations

The OCR Ops NirogCoreReceiptGateway targets Core's POST /api/v1/internal/ocr/lab-review-packets endpoint with the matching worker-secret and idempotency headers. Its payload contains only the signed correlation assertion, confirmed decision, provenance, reviewer reference, hashed reason, timestamp, and version/trace metadata.

Core accepts only confirmed packets at that endpoint, verifies the short-lived correlation assertion and worker secret, records a receipt idempotently, and emits an identifier-only audit/outbox event. Focused Core and OCR Ops contract tests passed during the audit.

Live boundary evidence

The OCR Ops deployment has a configured Core internal URL and a worker identity of the expected length. A malformed receipt request reached the live Core route and was rejected by request validation. A schema-valid receipt request without the worker header returned 401, confirming the protected route is reachable and rejects unauthenticated traffic.

The same deliberately invalid assertion with the configured worker identity reached the receipt command but returned an unexpected 500 rather than the expected invalid-assertion client error. It did not create a receipt because its assertion did not match any Core-issued correlation. This should be corrected to a stable 4xx problem response before an end-to-end receipt test is enabled.

Integration conclusion

The receipt contract is implemented and its Core route is reachable, but the systems are not yet connected as an operational pipeline. OCR Ops creates only its own demo jobs and exposes a manual, confirmed-only receipt delivery endpoint. The primary web/Core flow instead queues Core OCR jobs for the legacy workers/ml worker. Neither Core nor Nirog Web currently calls OCR Ops to create a job, issue and relay a correlation assertion, submit a review, or deliver a receipt.

Required next increment

  1. Add a Core-authorized job-intake endpoint to OCR Ops that accepts a Core evidence/job correlation and an opaque evidence reference; do not transfer document bytes through the public web app.
  2. Have Core issue the short-lived correlation assertion as part of the internal job dispatch contract and have the OCR Ops adapter retain it only until a human confirms the matching review.
  3. Introduce a Core dispatch/outbox consumer that invokes the OCR Ops intake endpoint and records retry-safe delivery state. The existing Core workers/ml path should remain the active pipeline until the new dispatch is independently proven.
  4. Map the confirmed OCR Ops review back to Core through the existing receipt endpoint, with an end-to-end synthetic test covering dispatch, review, receipt, audit event, and retry/idempotency behavior.
  5. Normalize malformed or invalid correlation assertions in Core to explicit client-safe 4xx problems; production clients must never receive a generic 500 for an invalid external assertion.