SOL Lens: Deterministic Agent Migration Evidence | Built with GPT-5.6 + Codex

SOL Lens

See whether your agent actually got better, not merely whether its final answer looks better.

Agent migrations are often evaluated using a handful of polished outputs. That can hide weak evidence, broken constraints, unresolved contradictions, or regressions elsewhere in the workflow.

SOL Lens turns observable agent activity into a replayable semantic graph, evaluates its evidence structure, and returns a transparent PROMOTE, HOLD, or QUARANTINE decision.

Inspiration

SOL Lens grew from a practical question:

How can an engineering team inspect what changed when it replaces one agent or model with another?

Most evaluations concentrate on final-answer quality. That matters, but it does not reveal whether the candidate gathered better evidence, preserved requirements, checked its work, or reconciled conflicting sources.

I had already been exploring these ideas through the SOL Engine, a larger research project about self-organizing semantic graphs and graph dynamics. During OpenAI Build Week, I turned that foundation into a focused, runnable product for agent-migration review.

The result is SOL Lens: a browser-local workbench designed to make migration evidence visible, deterministic, portable, and independently reviewable.

What it does

SOL Lens represents an observable agent trace as atomic semantic units called Logons.

A Logon can represent:

a user requirement
a tool request or result
an evidence claim
a constraint check
a contradiction
a final output

Typed edges record how those units support, constrain, challenge, or feed back into one another.

From that packet, SOL Lens:

validates and normalizes the observable trace
creates a deterministic semantic-graph layout
scores evidence, coherence, and contradiction
compares the candidate with an observable reference summary
applies explicit promotion gates
exports a replayable proof packet
optionally visualizes graph dynamics through Manifold Replay

The authoritative Trace Court and the experimental replay visualization remain deliberately separate. Running the replay can change its telemetry, but it can never rewrite the court verdict.

Start without learning a new file format

A major product goal was making the project understandable to someone encountering SOL for the first time.

Instead of requiring judges to author unfamiliar JSON, SOL Lens includes seven one-click, browser-local teaching packets:

Example	Logons	Structure
Grounded answer	6	Straight evidence chain
Agent migration	10	Branching evidence and merge
Parallel tool fan-out	24	Parallel tool branches
Self-correction loop	48	Explicit feedback cycle
Multi-agent handoff	72	Specialized agent lanes
Conflicting sources	120	Repeated constraint collisions
Program-scale migration	300	Grouped overview and drill-down

These are clearly labeled deterministic fixtures, not live model captures, but they run through the same validator, scoring, layout, court, replay, and export paths as an imported packet.

How we built it

SOL Lens is implemented as a TypeScript and React application using Vite/Vinext, with deterministic evaluation and replay logic running locally in the browser.

Layer	Responsibility
Packet validator	Validates the versioned trace contract and safely normalizes compatible packets
Example library	Supplies seven deterministic trace structures from 6 to 300 Logons
Graph layout	Produces stable, cycle-aware layouts and grouped overviews
Trace Court	Recomputes evidence, coherence, contradiction, and verdict gates
Proof export	Creates a portable packet containing the observable trace and recomputed result
Manifold Replay	Simulates bounded density, pressure, conductance, flux, and damping
Test suite	Verifies validation, scoring, determinism, layout, replay isolation, and UI metadata

The deployed evaluator is credential-free and browser-local. It does not claim access to hidden reasoning or private chain of thought.

The scoring model

For a set of observable Logons $L$, each Logon carries bounded values representing evidence density $\rho_i$, semantic pressure $p_i$, and governance alignment $\psi_i$.

Evidence excludes explicitly contradictory units:

$$ E = \frac{1}{|L_{\neg c}|} \sum_{i \in L_{\neg c}} \rho_i $$

The contradiction rate is based on the portion of the trace marked contradictory, with a small stabilizer $\varepsilon$:

$$ C = \frac{|L_c|} {|L| + \varepsilon} $$

Coherence combines observable evidence, alignment, and pressure:

$H = 0.45E + 0.42\bar{\psi} + 0.13(1-\bar{p})$

The Build Week demonstration profile then applies explicit gates:

PROMOTE: $C \le 0.10$, $E \ge 0.82$, and $H \ge 0.72$
HOLD: contradiction remains acceptable, but a promotion gate is missed
QUARANTINE: $C > 0.20$ or $H < 0.72$

These thresholds are versioned demonstration defaults, not a claim that one universal profile fits every production workflow.

Manifold Replay asks a different question: how might activity propagate through the observable graph? A simplified edge-flux relationship is:

$$ J_{ij} = g_{ij}(p_i-p_j) $$

where $g_{ij}$ is the mode-shaped conductance and $p_i-p_j$ is the pressure difference between connected Logons.

How Codex and GPT-5.6 helped

During Build Week, I used Codex powered by GPT-5.6 as an active development collaborator.

Codex received the build guide, working repository, test failures, interface feedback, and compliance requirements. It helped implement and revise:

the versioned packet validator
deterministic graph layout
seven teaching fixtures
proof-packet export
Manifold Replay
the 37-test suite
documentation and deployment configuration
judge-facing onboarding and video materials

One important iteration began with a technically valid but unfriendly assumption: new users would upload or author JSON. After reviewing the judge experience, I retained the product decision to replace that entry point with one-click teaching packets.

Another important decision was keeping Manifold Replay state separate from the Trace Court. This prevents an experimental visualization from changing an authoritative evaluation result.

GPT-5.6 is a build-time development model in this submission. It is not secretly evaluating packets inside the deployed application. The submitted browser runtime remains deterministic.

Challenges we faced

Making an unfamiliar concept approachable

“Logon,” “SOL packet,” and “semantic manifold” are not concepts a new judge should need to understand before clicking anything. The interface therefore had to teach through examples rather than documentation alone.

Scaling one visualization across very different traces

A six-Logon chain and a 300-Logon program migration cannot use the same presentation strategy. We implemented detail, exploration, and grouped-overview modes while preserving deterministic results.

Supporting cycles without unstable layouts

Self-correction traces contain feedback edges. The layout system had to recognize strongly connected components instead of crashing, inventing depth, or changing positions between runs.

Keeping the verdict authoritative

Manifold Replay is visually dynamic, but it cannot be allowed to mutate the packet or alter the Trace Court. Tests explicitly verify that replay remains isolated from evaluation.

Separating inherited research from new work

The original SOL Engine predates Build Week. A major documentation challenge was connecting SOL Lens to that mathematical and experimental foundation while clearly identifying the workbench, packet contract, court, gallery, and replay interface as the new Build Week product layer.

What we learned

The biggest lesson was that inspectability is also a product-design problem.

A deterministic evaluator is not useful if users cannot understand its inputs, boundaries, or decisions. Clear examples, explicit provenance, visible thresholds, portable proof packets, and honest limitations are part of the technical implementation, not decoration added afterward.

We also learned that a dynamic visualization becomes more trustworthy when it clearly states what it cannot do. Manifold Replay is valuable precisely because it is separated from the authoritative verdict.

Finally, the Codex development loop worked best when it included concrete evidence: repository state, failing tests, screenshots, compliance findings, and retained product decisions. That transformed GPT-5.6 from a generic code generator into a test-driven implementation and review collaborator.