A Polygraph engine

polyvers — evolve a live system without breaking what's already running

The moment you change a state machine's definition, every instance already running it is still running the old one. polyvers classifies the change, seeds it against real in-flight state pulled from the live fleet, and gates the deploy on the verdict.

The pipeline

What goes in, the stages it runs, what it leaves behind. Step through the stages to trace the run.

fig 10
polyvers
gate the deploy on the fleet the last version left behind
Verifying a version is one problem. The order half-shipped and the session half-negotiated are still running the old one.
evolve
01
Classify
A content-hashed diff of the artifact family fires compatibility lanes — shape, vocabulary, intent, semantic, migration, composition — and each lane names exactly the gates it demands. A cosmetic edit fires none, and the report says so.
→
02
Corpus
Fleet states are the test inputs: polyrun archive exports (the honest tier) or BFS-synthesized old-machine states (the weakest tier — disclosed as such).
→
03
human fills holes
Migrate
Scaffolded from the shape diff: complete for pure additions, throwing TODO holes for the rest. Validated fleet-wide — pure, accepted, projection-equal — then the corpus swaps to post-migration states.
→
04
Lane gates
Round-trip, pointwise comparison, and cross-version stimuli: everything the old version could still deliver must land on the new machine as accepted, or as a named observable reject.
→
05
Seeded check
The headline gate — explore exhaustively from LIVE states rather than init. Can any instance the fleet holds be driven to a violation under the new rules? The v1-reachable / v3-unreachable landmine hunt, mechanized.
consumes
old + new artifact families · fleet snapshots (archive or synthesized)
produces
compat-report.{json,md} — exit 0 is the gate · migrate.cjs scaffold · rollout matrix
Refusals over vacuous passes: an empty corpus, missing invariants, an unreadable stimulus set or a bounded exploration is a failing verdict with the reason named — never a silent green. No API key anywhere.

How it works

The step most verification tooling skips entirely.

1

Classify the change

Every version diff is sorted into a compatibility lane before anything else happens: additive, migrated, or breaking.

2

Seed the live fleet

The new definition is checked against snapshots of instances that are actually running right now, not a clean synthetic dataset.

3

Gate deploy on the verdict

A breaking change with no valid migration for in-flight state is blocked before it ships, named offenders included.

Fits with: The step after polygraph or polygen has verified the new version in isolation — polyvers is what verifies it's safe for the fleet that's already live.