This page explains which live systems Eval Labs should call and how to verify it.
Current environment rule
Eval Labs production currently targets active Lucia Development:
For promoted validation:
Do not confuse these.
Confirmed routing history:
That interval proves deployed routing drift. It does not prove that every historical run individually used Staging, and no historical run should be rewritten without its own captured provenance.
Active dev endpoint
This is the correct endpoint when testing current dev Engine changes.
Netlify environment variable
Eval Labs uses a Vite environment variable:
For active dev testing, it should be:
Because Vite bakes environment variables into the frontend bundle, changing the Netlify variable requires a redeploy.
Render CORS allowlist
The dev Engine must allow Eval Labs as an origin.
Render dev Engine environment variable:
It must include:
How to verify the live path
In browser DevTools → Network, run a custom prompt and click operator-focus.
Expected:
If the production app points to Staging outside an explicitly authorized promoted-validation window, treat it as a target mismatch and do not trust the run as Development evidence.
If it has a CORS error, the Engine allowlist is wrong.
This Network check proves request routing only. A 200 OK does not prove that a model was invoked or identify the provider-resolved model.
For runtime/model proof, use the owner-only Lucia Runtime Verification panel. It reads meta.runtime and meta.model_runtime from the same /admin/operator-focus response and shows:
The live 2026-07-10 verification returned Verified: configured and resolved model gpt-5.6-sol, model invoked true, deterministic path false, and fallback false.
DevTools Network proof that deployed Eval Labs is calling the active dev Engine and receiving a 200 response.
DevTools Network request header.
DevTools Network response header.
