← Instrument galleryD15-HAYGENT-RUN-INSPECTOR

Haygent Run Inspector

A deterministic browser-local research instrument.

DETERMINISTIC FIXTURE · NOT A PERFORMANCE RESULT

Haygent Run Inspector

MECHANISMDeterministic spine containing bounded intelligence slots
AUTHORITYManifest, state packets, permissions, and evidence gates
COMMIT RULEPASS derives only from satisfied evidence objects.
FAIL-CLOSED RULEDenied writes stay denied; exhausted repair produces HALT.
STATEREADY9859e563
spine step0
repair budgetREADY
gate evidence9859e563
  1. READY
  2. RUNNING
  3. ADJUSTING
  4. GATE_FAIL
  5. REPAIRING
  6. PASS
  7. HALT
CONTRACT CONTROLS

Each control executes a declared browser-local transition. Repeated dual-outcome controls alternate deterministically.

FIXTURE ASSERTIONS

NOT YET EXERCISEDModel cannot choose arbitrary next step.

NOT YET EXERCISEDDenied operation is recorded and not bypassed.

NOT YET EXERCISEDPASS derives from evidence, not report prose.

NOT YET EXERCISEDExhausted repair yields HALT with preserved artifacts.

RECEIPTED EVENT LOG

No transition yet. Operate a declared control.

This transparent browser-local instrument teaches the authored state contract. Exercising an assertion demonstrates fixture behavior only; it is not evidence of production performance, compression ratio, model uplift, cognition, safety, or universal correctness.

Purpose

Show a deterministic spine containing bounded intelligence slots, executable permissions, evidence gates, repairs, and truthful HALT.

Mechanism

A manifest drives exact steps. One slot may patch only allowed fields. Gates evaluate artifacts. A failed gate activates at most two repairs and then halts.

Deterministic fixture

A documentation-build job with target jail, one malformed model adjustment, a denied network request, test evidence, and exhausted repair variant.

The fixture must live in content/demos/d15-haygent-run-inspector/fixture.json, validate before the demo renders, and be resettable without a network call. A future live adapter may be added behind a visibly separate mode.

Required controls

  • Inspect manifest
  • Start run
  • Step spine
  • Open packet
  • Invoke slot
  • Attempt forbidden write
  • Evaluate gate
  • Repair
  • Force failure
  • Replay

Visible states

  • READY
  • RUNNING
  • ADJUSTING
  • GATE_FAIL
  • REPAIRING
  • PASS
  • HALT

Every state must have text, iconography, and a non-color-only distinction. State transitions are logged in an in-memory demo receipt visible in the inspector.

Core assertions

  1. Model cannot choose arbitrary next step.
  2. Denied operation is recorded and not bypassed.
  3. PASS derives from evidence, not report prose.
  4. Exhausted repair yields HALT with preserved artifacts.

Layout

The page contains:

  1. a concise mechanism explanation;
  2. the interactive stage;
  3. a state and evidence inspector;
  4. a reset control;
  5. a “what this proves / what it does not prove” panel;
  6. links to the related paper and benchmark contract.

On narrow screens the inspector becomes a bottom sheet. The stage must remain usable at 360 CSS pixels.

Accessibility

  • All operations are keyboard reachable.
  • Pointer gestures have button or keyboard equivalents.
  • Animated transitions honor prefers-reduced-motion.
  • Focus remains visible and returns predictably after sheets close.
  • Diagrams expose concise text alternatives.
  • Status is announced through a polite live region only when the user initiates the transition.

Instrumentation

Record locally:

demo_id
fixture_version
action
prior_state
result_state
validation_result
timestamp_relative

Do not send telemetry. Provide “Export demo trace” as JSON for debugging and reproducibility.

Automated tests

  • fixture schema validation;
  • deterministic reset;
  • every required control transition;
  • every assertion above;
  • invalid and stale fixture handling;
  • keyboard path;
  • 360 px and 1440 px screenshots;
  • zero critical console errors;
  • no request to a paid API in default mode.

Publication boundary

The demo is a reference execution kernel, not proof that every open-ended task fits a deterministic spine.

The interface must never convert illustrative values into a benchmark claim. A measured result appears only when linked to a versioned run receipt.