Skip to content
Sableframe
IN DEVELOPMENT

DropPilot

Deterministic orchestration for high-demand product drops.

A multi-retailer system for monitoring availability, applying explicit purchasing rules, maintaining session readiness, coordinating permitted checkout flows, and measuring every decision and latency span.

Status
IN DEVELOPMENT
Source
Private
Capabilities
  • Automation
  • Safety systems
  • Observability
DropPilot dashboard with a navigation sidebar and summary tiles for product targets, enabled retailers, healthy and degraded monitors, confirmed orders, and detection latency.
Simulated dataDashboardThe system overview, driven by the built-in retailer simulator.

The problem

High-demand product drops sell out in moments. Watching availability, deciding what to buy within a budget, keeping sessions ready, and completing checkout are all easy to get wrong under that pressure.

DropPilot’s aim is to detect fast, decide deterministically, run only the purchase flows a retailer permits, and measure every step along the way.

The system

  • Availability monitoring

    Workers record every availability check and emit a stock event only when something actually changes.

  • Deterministic rules

    A pure rule engine denies by default and records every decision. No language model can authorize spending.

  • Session readiness

    Sessions move through explicit readiness states, and credentials are referenced rather than stored.

  • Guarded checkout

    Reservations, a final price check before submitting, and a clear line between a submitted order and a confirmed one.

  • Latency tracing

    Per-stage timings from a monotonic clock, keeping retailer time separate from DropPilot’s own processing time.

How it was built

A Next.js and TypeScript interface sits on focused engine packages for monitoring, rules, sessions, cart, checkout, safety, orchestration, latency, and notifications, backed by PostgreSQL.

Retailer adapters declare what they can do, and core logic never branches on a retailer’s name. Each phase of the build is closed by an automated verification gate that records its evidence.

  1. Monitor

    • Availability workers
    • Stock-change events
  2. Decide

    • Deterministic rule engine
    • Spending limits
  3. Prepare

    • Reservations
    • Session readiness
  4. Execute

    • Permitted cart and checkout
    • Order confirmation
  5. Observe

    • Latency traces
    • Audit log
    • Notifications
Every drop moves through the same audited pipeline, with timings recorded at each stage.

Technology

  • Next.js
  • TypeScript
  • PostgreSQL
  • Workers and retailer adapters

Design decisions

  1. Plan retailers together

    Simultaneous restocks become one plan, so separate decisions cannot each pass their own checks and together exceed a spending cap.

  2. Record before submitting

    An order is marked as submitted before the submit call is made, so money can never move without a record.

  3. A kill switch that fails closed

    A database-level guard refuses new spending commitments while the switch is on, and a missing setting counts as on.

  4. No implied liveness

    Views render on request with a refresh control and a rendered-at time, rather than streaming indicators that could overstate freshness.

Selected views

Current state

In development. The engines and interface run end to end against a built-in retailer simulator, and views driven by it are labelled as simulated. A first real-retailer pilot is limited to monitoring with a manual hand-off and is not yet complete. The source code is private.