Back to notes
The Tesseract MemoryTechnical note

Using Python verification while keeping a checked fallback

The gateway can use Python's result, compare it with the local verifier or fall back after a typed failure, while recording which route produced the response.

Published 2 min read
Topics

Choose the result before interpreting it

The gateway keeps both local and Python verification available. Live routing requires the microservice flag, live-verifier flag and Python mode; an optional health requirement can prevent the call. A successful live request returns Python's result with route and mode telemetry. Typed timeouts and service errors select the local verifier.

Shadow mode is for comparison. It returns the local result, calls Python and records differences in outcomes, supported and dropped units, citations and scores. Reranking comparisons record overlap and changes in order. The comparison is synchronous, so it still adds waiting time even though Python doesn't choose the displayed result.

Make fallback visible in the diagnostics

The HTTP client sends a bearer credential and trace ID, expects JSON, and has separate connection and request timeouts. Bounded retries cover connection failures and transient server responses. The total wait can therefore include a health check and multiple attempts, not just one timeout.

Optional logs retain the route, timing, status, payload keys and candidate count rather than the body. Gateway records distinguish live, disabled, shadow and fallback routes, so a working learner response doesn't get mistaken for a successful Python call.

Tests define authentication, server retry, typed timeout, live verification, health rejection, reranker fallback and shadow differences. The client checks that successful JSON decodes to an array; that isn't full PHP-side response-schema validation. Current runtime flags weren't inspected, and health alone wouldn't establish database readiness or answer quality.

Live, shadow and fallback are different results

Both paths can call Python, but only live routing returns the Python verifier result.

Direct callResponse / returnBlocked / denied
Laravel gateway
Local verifier
Python service

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (10)
  1. 01 · Select configured mode → 02 · Live routePython live enabled · Direct call
  2. 01 · Select configured mode → 03 · Shadow routeComparison mode enabled · Direct call
  3. 02 · Live route → 07 · Versioned verification endpointBounded HTTP request · Direct call
  4. 02 · Live route → 05 · Local verificationUnhealthy, timeout or error · Blocked / denied
  5. 07 · Versioned verification endpoint → 04 · Return result with route telemetryLive success · Response / return
  6. 05 · Local verification → 04 · Return result with route telemetryLocal fallback · Response / return
  7. 03 · Shadow route → 06 · Local shadow resultCompute local · Direct call
  8. 03 · Shadow route → 07 · Versioned verification endpointSynchronous shadow request · Direct call
  9. 07 · Versioned verification endpoint → 08 · Comparison metadataCompare remote with local · Direct call
  10. 06 · Local shadow result → 04 · Return result with route telemetryReturn original local result · Response / return

Build context