Core Concepts
How Specter turns raw user behavior into verified product improvements.
The Specter Pipeline
Signals
A signal is any user action or event you send to Specter. Signals are the raw data that the analysis engine uses to diagnose problems and propose improvements.
Signal structure
Every signal has a type and an optional payload.
Required
typeWhat happened (e.g. swap_completed, error)Optional
payloadExtra data about the event (any JSON object)context_idRoute signal to a specific contextSignal polarity
Signals are categorized as positive, negative, or neutral based on your context configuration.
swap_completed, thumbs_up, task_done)swap_failed, thumbs_down, error)page_view, feature_used)Contexts
A context describes a specific area of your product. It tells Specter what your product does and which signal types indicate success or failure.
Context configuration
Each context has a name, description, and polarity definitions.
“Multi-step checkout process. Users add items to cart, enter shipping info, and complete payment. Success = completed order. Failure = abandoned cart or payment error.”
order_completed, payment_successcart_abandoned, payment_failedWhy contexts matter
Focused analysis — Specter analyzes signals per-context, so proposals are specific to one area of your product.
Polarity scoring — By defining which signal types are positive vs negative, Specter can measure your positive/negative ratio and detect when things are getting worse.
Auto-routing — Products with a single context automatically route all signals to it. With multiple contexts, include a context_id in your signals.
Manage contexts in Settings → Contexts.
Proposals
A proposal is an AI-generated improvement recommendation based on your signal data. Each proposal includes a diagnosis, suggested change, evidence, and predicted impact.
Proposal anatomy
Every proposal contains five key fields:
Proposal lifecycle
Deployments
When you approve a proposal, Specter creates a deployment record. This captures the “before” state of your signal metrics so Specter can later compare them against the “after” state.
Before metrics
Captured at the moment you approve a proposal, scoped to the last 7 days of signals.
Verification
The verification loop is what makes Specter unique. After you implement a change, Specter automatically compares before/after signal metrics to determine if the change actually worked.
How verification works
You approve a proposal and implement the change in your product.
Specter’s verification cron runs 4 times daily and counts new signals since deployment.
Once enough post-deployment signals accumulate (dynamic threshold based on traffic volume), Specter calculates the after metrics and compares sentiment scores.
The deployment is marked as Verified (improved), Degraded (got worse), or Unverified (no significant change).