Skip to main content

EsperTech overview

EsperTech is a tenant-aware operator console for a decisioning system. In plain English: it helps your team decide which events to allow, observe, challenge, or block, then explains what happened afterward.

The current application surface, based on the code in app-esper.io, exposes these areas:

  • GitHub-backed operator sign-in
  • Tenant creation, switching, and membership management
  • Source-bound API keys for ingest clients
  • JSON AST rule authoring
  • Versioned encoding plans
  • Entity and session state inspection
  • Decision and event history
  • Replay jobs
  • Audit history

The docs in this portal are written to match the current application behavior, not a future-state roadmap.

What the console is for​

The frontend presents EsperTech as an operations surface for running a backend decision engine. Operators can:

  • choose which workspace they are operating in
  • create credentials for systems that send events into Esper
  • define how incoming requests are translated into usable fields
  • define rules that turn those fields into decisions
  • inspect the state Esper is keeping for an entity or session
  • review what happened in live traffic or in historical replays
  • inspect admin-side changes in the audit log

The simple mental model​

If you are new to the product, this is the shortest accurate way to think about it:

  1. A source sends EsperTech an event.
  2. An encoding plan extracts the important fields from that event.
  3. Rules evaluate those fields and any saved state.
  4. EsperTech records a decision such as Observe or Block.
  5. Operators review the outcome, inspect state, and replay history when needed.

Current information architecture​

The routes exposed by the app are:

  • /login
  • /
  • /tenants
  • /api-keys
  • /rules
  • /encoding
  • /entities
  • /sessions
  • /decisions
  • /events
  • /jobs
  • /audit

Important accuracy notes​

  • Rules are currently authored as raw JSON in the UI. There is no visual rule builder in the present app.
  • Encoding plans are authored through a structured form and stored as numbered versions with statuses Draft, Active, or Retired.
  • The console assumes a backend API defined by VITE_API_BASE_URL.
  • Operator authentication uses a GitHub login flow and stores the returned token in browser local storage.

Who these docs are written for​

These docs assume you are one of:

  • a founder or product lead setting up the first environment
  • an operator responsible for reviewing decisions
  • an engineer or AI agent helping configure the system

They do not assume deep knowledge of the backend internals.

Continue to Quickstart for the fastest path through the app.