← Instrument galleryD13-CONTEXT-COROLLA

Context Corolla

A deterministic browser-local research instrument.

DETERMINISTIC FIXTURE · NOT A PERFORMANCE RESULT

Context Corolla

MECHANISMSpatial work-state projection over one Project Core
AUTHORITYProject object state and provenance
COMMIT RULERelease & Route proposes; covered approval commits.
FAIL-CLOSED RULERotation and Lucky cannot expand consequential authority.
STATENOW213c59b8
selected spoke0
object identityNOW
provenance event213c59b8
  1. NOW
  2. NEXT
  3. DELEGATED
  4. REVIEW
  5. BLOCKED
  6. DORMANT
  7. ROUTE_PROPOSED
  8. APPROVAL_REQUIRED
CONTRACT CONTROLS

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

FIXTURE ASSERTIONS

NOT YET EXERCISEDEvery move records provenance.

NOT YET EXERCISEDLucky cannot perform an uncovered consequential action.

NOT YET EXERCISEDList and keyboard fallback can perform the same state operations.

NOT YET EXERCISEDRotation never changes project truth.

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

Provide a compact spatial grammar for Now, Next, Delegated, Review, Blocked, and Dormant work with Identify and Release & Route.

Mechanism

Objects occupy six states around a center Identify action. Rotation changes focus, not authority. Voice Capture opens a reviewable route sheet before state changes.

Deterministic fixture

A project with nine objects distributed across the six states, two stale dependencies, and one consequential route requiring approval.

The fixture must live in content/demos/d13-context-corolla/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

  • Rotate wheel
  • Select state
  • Identify object
  • Add Capture
  • Release microphone
  • Choose Lucky/Edit/Redo
  • Move object
  • Open provenance
  • Use list fallback

Visible states

  • NOW
  • NEXT
  • DELEGATED
  • REVIEW
  • BLOCKED
  • DORMANT
  • ROUTE_PROPOSED
  • APPROVAL_REQUIRED

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. Every move records provenance.
  2. Lucky cannot perform an uncovered consequential action.
  3. List and keyboard fallback can perform the same state operations.
  4. Rotation never changes project truth.

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

This demonstration evaluates the interaction grammar, not universal productivity uplift.

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