Justin Scheibel
Back to selected work

Product Systems Lab | Interactive decision workflows

See how a decision-support product behaves when the happy path stops being enough.

Step through deterministic simulations that turn product rules into inspectable decision workflows. Each action exposes the facts, validation boundary, state transition, and event history behind a reliable interface.

Open the simulators
Models
Three public-safe decision workflows.
Engine
Deterministic, local, and dependency-free.
State
Decision facts, phases, actions, and event history stay visible.
Boundary
No accounts, production data, tracking, or network writes.

Why this exists

A decision-support system becomes clearer when its rules can be operated.

These models translate the public TrailScope and Poolhouse case studies into inspectable behavior. They show how requirements become structured facts, validation rules, state transitions, and recovery behavior—the same disciplines behind reliable analytics products and working applications. They are illustrative state models, not replicas of production code or live product data. The simulations send or retain no visitor or product data.

  • Accepted actions advance to one predictable state.
  • Blocked actions explain the rule and preserve the accepted state.
  • Reset returns the model to the same initial conditions.

Operate the models

Operate three bounded decision workflows.

Try the blocked action when it appears; the event log will show what the system protected.

Model 01 | Local-first recovery

TrailScope route to durable local output

Prepare a route, move it to the watch, continue recording offline, save local history and GPX/FIT before delivery, then let the phone catch up.

Read TrailScope case study
Read the complete TrailScope sequence
  1. Route draft: local GPX/FIT is blocked because no completed record exists.
  2. Route ready: the phone has a local route and the watch still needs confirmation.
  3. Watch ready: both devices agree on the route before recording.
  4. Recording offline: checkpoints continue locally after connectivity is lost.
  5. Saved locally: history and local GPX/FIT become durable before phone delivery.
  6. Delivery pending: local output stays available, but an offline transfer cannot be marked sent.
  7. Delivery merged: a bounded phone import catches up without replacing newer workout state.
  8. Durable record: local GPX/FIT remains available after delivery recovers.

Model 02 | Trusted shared state

Poolhouse pick to refreshed standings

Run schedule-aware client checks, preserve independent backend core-rule rechecks, present a closed window, and apply bounded automated scoring state.

Read Poolhouse case study
Read the complete Poolhouse sequence
  1. Pool setup: the client blocks submission until it presents an open pick window.
  2. Picks open: schedule-aware client checks reject incomplete or ineligible choices.
  3. Pick saved: backend ownership and core-rule rechecks precede the atomic write.
  4. Window closed: the client blocks a late replacement without implying a universal server deadline check.
  5. Refresh pending: bounded automated scoring exposes an explicit pending state.
  6. Scores refreshed: refreshed state applies while finality remains separate.
  7. Standings final: the round closes with validation and scoring state still inspectable.

Model 03 | Privacy-first recovery

Poolhouse standings recovery boundary

Preserve a labeled last-known-good snapshot through a transient refresh failure, but clear retained private results as soon as viewing authority is lost.

Read Poolhouse case study
Read the complete standings-recovery sequence
  1. No snapshot: a failed refresh cannot invent or imply saved results.
  2. Unavailable: failure without a last-known-good snapshot is disclosed directly.
  3. Current results: a successful refresh becomes the last-known-good snapshot.
  4. Saved-results warning: a transient failure may retain that labeled snapshot while authority is valid.
  5. Current again: retry success or an unchanged response restores current state.
  6. Access blocked: authority loss clears retained private rows and stops refresh behavior.
  7. Guard test: an attempt to show retained results after revocation remains blocked.

Public proof boundary

The model makes the reasoning inspectable; private implementation detail stays private.

The simulations use public product concepts already described on this site. They do not expose production architecture, telemetry, member data, customer data, or live application state.

Read the product-simulation note Read the local-first note Read the trusted-state note Connect on LinkedIn