Alerts · Roadmap

The rules that would be worth being told about

Alerts are the feature that makes a market tool useful when you are not looking at it. This page describes the rule set, the delivery model, and the failure modes in full — and none of it is built. There is no channel, no account, and nothing to switch on.

RoadmapThis is a research roadmap item, not a current capability. Nothing described here is running today.

Rule families: 4
Rules described: 10
Channels built: 0
Alerts sent, ever: 0

Status

Nothing on this page exists

This is a design document rendered as a page, not a feature preview with a waitlist behind it.

Roadmap means roadmap

VigPulse has never sent a product alert. There is no alert delivery service, no webhook, no mobile application, and no account system that a rule could belong to. The early-access waitlist is separate: it only reserves launch access and does not create or deliver market alerts.

What does exist today is the published paper ledger, the calculators, and the written explainers. That is the whole current product.

Notification service: None
Accounts: None
Stored rules: 0
Committed date: None

Catalogue

The rules, by family

Each rule below is a condition that can be evaluated mechanically against observations. That constraint is deliberate: a rule that needs a judgement call cannot fire consistently, and an alert that fires inconsistently is worse than no alert.

Edge and score

Roadmap

Edge threshold: Fire when estimated edge on any tracked market crosses a set number of points.
Score threshold: Fire when an opportunity score crosses the playable threshold.
State transition: Fire specifically on WAIT to BET, which is the transition that matters most.

Movement

Roadmap

Velocity: Fire when a market reprices faster than a set rate over a rolling window.
Reversal: Fire when a market moves and then retraces through its starting point.
Divergence: Fire when one book separates from consensus by more than a set distance.

Data quality

Roadmap

Stale book: Fire when a book stops updating, so a frozen quote is never mistaken for a good price.
Coverage gap: Fire when a tracked market stops being priced by enough books to form consensus.

Context

Roadmap

Lineup and injury: Fire on scheduled information events that historically precede repricing.
Promo: Fire when a boosted offer would add incremental expected value to a tracked market.

The important one

WAIT to BET is the transition worth a notification

Most alerts describe a level. This one describes a change of conclusion, which is the only moment where being told something you were not already watching for is genuinely useful.

Why this transition and not the others

WAIT

A row sitting at WAIT is one the pipeline has already looked at and declined to call. It is waiting on something specific: a second book confirming the first, a move persisting rather than retracing, or a scheduled information event landing. When that resolves, the state changes.

That is a discrete, timestamped, checkable event. Compare it to an alert on "edge above two points", which fires constantly on a noisy market and tells you nothing about whether the edge survived contact with the rest of the evidence.

A transition alert also carries a natural expiry: if the row falls back to WAIT or PASS, the alert describing it is stale and can say so.

RoadmapAlert payload — sample shapeSample data

market      BOS -1.5 (illustrative sample row)
transition  WAIT -> BET
score       82/100  (threshold 75)
edge        +1.84 pts  band: medium
half-life   18 min remaining, estimated
price seen  +138  vs fair +128
reason      divergence held across 3 books,
            no reversal in window
state note  analytic label, not advice

An illustration of the fields an alert would carry. No alert has ever been sent and this is not a message anyone received.

The sampled demo board contains 1 BET, 2 WAIT and 1 PASS rows on a fixed snapshot. Those counts come from the illustrative demo dataset, not from a live board.

Anatomy

What a rule is made of

Six parts, and the last four are the ones that decide whether a rule set stays useful after the first week.

Components of an alert rule and why each exists.
Part	Status	Detail
Subject	Roadmap	What is being watched: one market, every market in a sport, or a saved filter such as every run line with a score above a threshold.
Condition	Roadmap	The measurable thing that has to become true. Every condition on this page is a number crossing a line, not a judgement call, because a rule that cannot be evaluated mechanically cannot be trusted to fire consistently.
Threshold	Roadmap	The value the condition is measured against, set by the person making the rule rather than by us. A threshold nobody chose is a threshold nobody understands.
Cooldown	Roadmap	How long the rule stays quiet after firing. Without it, a market oscillating around a threshold produces a stream of alerts describing one event.
Expiry	Roadmap	When the rule stops applying, usually at market close. An alert that arrives after the market it describes has closed is noise with a timestamp.
Delivery	Roadmap	Where it goes and how fast it has to get there. On a signal with a twenty-minute half-life, a delivery path that takes five minutes has already spent a quarter of the value.

Failure modes

How alert systems become useless

Every one of these is common, and every one of them is a design problem rather than an engineering problem. Listing the intended response is more honest than promising the feature will simply be good.

Too many alerts

Design risk

Consequence. Every one gets ignored, including the one that mattered.

Intended response. Thresholds default high, cooldowns default long, and the rule editor shows how often a rule would have fired historically before it is saved.

Alerts that arrive too late

Design risk

Consequence. The edge decayed before the notification landed, so acting on it is worse than doing nothing.

Intended response. Every alert carries the estimated half-life of what it is describing, and a rule can decline to fire when the remaining life is shorter than the delivery path.

Duplicate alerts for one event

Design risk

Consequence. A market oscillating around a threshold produces a stream describing a single move.

Intended response. Deduplication by market and condition, plus a cooldown that is part of the rule rather than a global setting.

Alerts that read as instructions

Design risk

Consequence. A notification saying BET is easy to act on without reading anything else.

Intended response. The state, the score, the uncertainty band, and the reason travel together. An alert that cannot carry its context does not get sent.

An alert is not a recommendation

BET, WAIT, and PASS are analytic labels describing what a model concluded about a price. Putting one of them in a notification does not turn it into advice, and no alert VigPulse would send is an instruction to stake money. If a rule set ever ships, that wording travels with every message rather than living on a page nobody reads twice.

Delivery

Channels, and why each one is empty

Delivery is not the hard part of alerting, but it is the part that cannot be faked. Nothing below is connected.

Every delivery channel VigPulse has considered, with its real status. None is built.
Channel	Status	Blocked on
In-app	Roadmap	Requires the application shell, which is not built.
Email	Roadmap	Requires accounts, which do not exist.
Webhook	Roadmap	Would ship alongside any data API.
Mobile push	Roadmap	No mobile application exists or is in development.

In-app alertsComing soonEmail digestsComing soonWebhooksComing soonMobile pushComing soon

Webhook delivery would ship alongside any data API, which is itself a documentation preview with no endpoint behind it.

Prerequisites

What has to exist first

Alerts sit at the end of a chain. Each link below is missing, and the last one is the one that matters most.

Everything alerts depend on, in the order it would have to be built.
Prerequisite	Status	Detail
A continuously running market feed	Not public	Rules evaluate against observations. The public site is a static export with no feed connected, so there is nothing on this side of the wall for a rule to read.
Accounts	Not built	A rule belongs to somebody. There is no login, no user record, and no stored preference anywhere on this site.
An application shell	Not built	Rules have to be created, edited, paused, and reviewed somewhere. The logged-in surface described across this site is a concept, not a build.
Delivery infrastructure	Not built	Sending anything reliably means retries, deduplication, rate limits, and a way to prove what was sent and when. None of it exists.
A reason to trust the alerts	Not established	Alerts amplify whatever the pipeline concludes. With 6 pre-game entries of closing-line evidence, the honest position is that the underlying signal has not been demonstrated yet.

Read the record

Current

The published ledger is the evidence that would justify alerting on anything. It is 33 graded paper entries, 9W-24L, with 6 pre-game CLV readings.

Open the ledger →

Use the math

Current

Thresholds are only meaningful if you can compute what they are measuring. The calculators do the arithmetic an alert rule would run, in your browser, free.

Open the tools →

Say what would be useful

Roadmap

There is no waitlist, no signup, and no notification preference to set. If a specific rule would be genuinely useful to you, describing it in an email is the whole process.

[email protected] →