Skip to main content
Eval Labs preserves prompt context, run source, Lucia response, layered human judgment, lifecycle state, reviewer identity, and—when captured—Lucia runtime/model provenance. This page defines the public product contract, not the private database layout.

​
Evidence topology

Eval Labs has several durable evidence domains. Keep them separate:
  • General evaluation evidence — the run, ordered cases, Lucia responses, and Review Queue decisions.
  • Behavioral evidence — intentionally saved Behavioral Observatory labels, distinct from review suggestions.
  • Runtime verification evidence — immutable owner-only observations about a deployed runtime and model path.
  • Fieldwork evaluation evidence — specialized claims, attempts, seals, protocols, execution receipts, cohorts, and recovery lineage.
Each domain has its own lifecycle and authorization boundary. A generic run count does not prove that a Fieldwork cohort, runtime observation, or behavioral label exists.
Browser-local state is compact continuity state, not durable cloud evidence. A local session index, draft, cache, or diagnostic count cannot substitute for an authorized durable write and readback.

​
Source, deployment, and live truth

The source and deployed build were reviewed on 2026-08-12. That review established the intended data flow and public export behavior, but it did not authenticate as every role, recount production records, or perform a new durable write. Use these claims separately:
  1. Source contract — the tracked application and schema define the behavior.
  2. Deployment identity — a specific build is live.
  3. Live durable evidence — an authorized operation succeeded and the same record read back.
Do not upgrade a source or deployment observation into live-data proof.

​
Authorization boundary

The application uses authenticated role and ownership context for durable operations:
  • owner and admin roles can oversee shared evaluation evidence where their privileged scope allows it;
  • the runtime verification surface remains owner-only;
  • evaluator and tester evidence remains scoped to their own allowed work except where owner/admin oversight applies; and
  • an enabled control or visible route does not prove that the durable service will authorize a read or write.
The exact policy predicates and database grants are private implementation detail. The public invariant is fail-closed authorization: every durable operation must be accepted for the authenticated identity, role, ownership relationship, and evidence domain. See Eval Labs Roles and Access Matrix for the role-level product contract.

​
Run and session contract

A run export preserves enough information to identify and interpret the evaluation:
  • stable run identity and title;
  • launch source and test mode;
  • category, subcategory, and suite or template context when applicable;
  • prompt count, ordered case identity, lifecycle status, and timestamps;
  • owning user and applicable ownership-scope version;
  • failure classification and reason when the run did not complete; and
  • captured runtime provenance when the evaluated response supplied it.
Custom and Auto-generated launchers both create runs that flow into the same Review Queue. The launch source distinguishes where the run began; the test mode describes how it executed. Controlled batch runs share lifecycle machinery but represent platform-readiness evidence rather than ordinary evaluator-facing testing. Registry Diagnostics reads existing evidence and derives dataset-membership and review-lane suggestions. Those suggestions are diagnostic output, not saved Behavioral Observatory labels.

​
Ordered case contract

Each prompt becomes an ordered case. The export preserves:
  • stable case and parent-run identity;
  • deterministic order within the run;
  • source and classification context;
  • prompt text and lock state;
  • Lucia response, run outcome, and any typed error;
  • timestamps; and
  • captured runtime provenance when available.
Order must remain stable across hydration and export so that a reviewer can reconcile the exported case with the reviewed item.

​
Review contract

Prompt-level review evidence keeps these meanings distinct:
  • the current draft;
  • the last intentionally saved review;
  • when and by whom it was saved;
  • app-suggested values;
  • guided Employee Review signal;
  • Human Guidance Evaluation;
  • senior adjudication and canon-candidate state; and
  • dirty, completion, and run-finalization state.
A generated but unreviewed item may legitimately have no saved ratings or reviewer identity. A saved review should identify the reviewer who saved that item. The app may suggest. The reviewer must decide. Senior meaning remains separate from employee signal.

​
Runtime and model provenance

For newly executed runs, Eval Labs can preserve runtime evidence returned with Lucia’s answer. The public provenance contract includes:
  • target endpoint and environment classification;
  • Engine service, build, and version identity;
  • request identity and verification time;
  • configured and provider-resolved model identity;
  • whether a model was invoked or the response followed a deterministic path;
  • whether fallback behavior occurred; and
  • task-level attempt, response, parsing, and model-resolution outcomes.
The configured model identifies configuration, not execution. Provider-resolved model evidence plus invocation/task outcomes is required to claim that a model actually ran. Deterministic-path and fallback evidence remain separate. Current JSON exports carry captured provenance with the run and affected cases. CSV and Markdown exports do not carry the full provenance object. The live verification on 2026-07-10 recorded a successful GPT-5.6 Sol model path with no deterministic bypass or fallback. That is a dated observation, not a guarantee about every later or historical run.
Historical records are not backfilled. When provenance was not captured, Eval Labs must say that it was not captured. Do not infer an endpoint, environment, Engine build, model, or invocation path for that run.

​
Confirmed routing drift

Configuration and deployment evidence establishes that the confirmed uninterrupted production-routing drift toward Staging began on 2026-05-04. Routing was corrected to Development and live-verified on 2026-07-10. That interval is routing history, not proof that every run in the interval used Staging. Only evidence captured with an individual run can establish its runtime.

​
Exporter and reviewer identity

The exporter is the person who produced the file. The saved-by reviewer is the person who intentionally saved a prompt review. One person may export a run reviewed by another, so the two identities must not be collapsed. Exports retain only the limited identity needed for authorship and audit: the product user identifier, email, and display name. Role metadata governs access; it is not review authorship.

​
Expected empty values

Empty values are normal when the corresponding event has not happened. Examples include:
  • no failure classification on a successful run;
  • no saved reviewer on an unreviewed prompt;
  • no ratings before scoring; and
  • no runtime provenance on a historical run that predates capture.
Treat an empty value as suspicious only when the workflow step should have populated it.

​
Export formats

Export controls for JSON, CSV, and Markdown results The export formats serve different purposes:
  • JSON preserves the richest nested run, case, review, lifecycle, identity, and captured-provenance contract.
  • CSV supports tabular analysis while flattening nested evidence.
  • Markdown supports human-readable review packets and summaries.
Do not infer that a field is absent from durable evidence merely because a flattened format omits the full nested object. The format and version must travel with the export so downstream readers can interpret it correctly.

​
Durable persistence contract

The durable service preserves run lifecycle, ordered case context, prompt-level review evidence, and authorship. Behavioral Observatory labels remain a separate evidence domain, with one saved label per reviewer per run item. For any durable evidence claim, all of these must hold:
  1. the authenticated operation is authorized for the intended evidence domain;
  2. the service confirms the write;
  3. the UI reports success only after that confirmation;
  4. the same evidence hydrates after refresh; and
  5. failed or ambiguous writes remain non-committable and are not counted.
The internal database tables, columns, policy expressions, migrations, and hydration order are intentionally not part of this public contract.

​
Dated readiness evidence

The May 2026 platform gate recorded 60 completed runs, 3,000 expected prompts, 3,000 durable run items, 3,000 non-empty Lucia responses, and 3,000 reviews for the tested reviewer context. That result established agreement among durable evidence, the tested UI, and the tested owner-scoped browser context at that gate. It is not a current production count, a complete authorization audit, or human Lucia-quality approval. No authenticated current-count query was run during the 2026-08-12 documentation review.

​
Browser-local compaction contract

Completed cloud-backed runs should not leave full item-level payloads in browser-local storage. Local continuity state should remain minimal, ownership-scoped, and replaceable from durable evidence. The May 2026 gate observed a compact local index for all 60 owned sessions, no retained full item-level payloads, and no visible other-owner or ownerless sessions in the tested browser context. That dated browser observation does not prove current record counts, another account’s isolation, or durable authorization completeness.

​
Export interpretation rule

Every export must preserve these separate meanings:
Do not collapse these into one score or one generic review field.