DEV Community: SIGNUM HQ

What a 5.5% Nasdaq drop looked like next to options-implied earnings moves (and how we scored them)

SIGNUM HQ — Fri, 06 Nov 2026 10:38:31 +0000

On Nov 5, 2026 the S&P 500 closed down 4.36%, the Nasdaq down 5.52%, the Philadelphia Semiconductor Index (SOX) down 12.25%, and VIX closed at 28.18. It was a chip-led drop. That same week we were scoring earnings reactions against the move that options had priced in beforehand, so we had a small, awkward test case: how does a pre-announcement "expected move" look next to what happened on a session like that?

We build SIGNUM HQ, a US stock app that shows an expected move before each earnings report and the actual move after it. This post is the scorecard for the week of Nov 2, how it is computed, and what it can and cannot say. It is not a forecast and not investment advice.

The numbers (interim, n = 21)

Of the 21 earnings reactions where we had a complete stored pair (expected move recorded before the report, actual move computed after), 15 landed inside the expected range and 6 outside. The median expected move was 7.7%; the median absolute actual move was 3.73%.

The six outside, by how far the actual absolute move exceeded the expected one:

Ticker	Expected	Actual	Excess
XYZ	±8.8%	+15.30%	+6.50 pp
ARM	±9.9%	−13.08%	+3.18 pp
DD	±6.5%	+8.61%	+2.11 pp
QCOM	±8.4%	−9.49%	+1.09 pp
BKNG	±8.8%	+9.83%	+1.03 pp
ETN	±6.7%	+7.00%	+0.30 pp

Eight of the 21 reactions happened on Nov 5 itself. Six of those eight were inside the range; the two outside were ARM and QCOM, both of which reported after the Nov 4 close. Their reaction day was also the day SOX fell 12.25%. Our scorecard is a raw close-to-close number, not market-adjusted, so it cannot separate the company's report from the market's session. On Nov 5 the briefing in our app points to same-session reports of declines at Dell, HPE and Super Micro as the strongest candidate for the chip move, labelled as a possible cause rather than a finding.

Five names that reported after the Nov 5 close (TEAM, AXON, NET, AFRM, IONQ) are not in the set yet. Missing records are excluded, never counted as a zero move, and we will confirm them on Nov 7 morning. So this is an interim snapshot, not the full week.

How the expected move is computed

For each report we take the at-the-money straddle on the first expiry after the announcement, add the call and put mid prices, and divide by the underlying price:

type Quote = { bid: number; ask: number };

const mid = (q: Quote) => (q.bid + q.ask) / 2;

// ATM straddle mid / spot, as a percentage
export function expectedMovePct(call: Quote, put: Quote, spot: number): number {
  return ((mid(call) + mid(put)) / spot) * 100;
}

// Equality counts as inside the range
export function isWithinRange(actualPct: number, expectedPct: number): boolean {
  return Math.abs(actualPct) <= expectedPct;
}

// Positive = the reaction was bigger than priced, in percentage points
export function excessPp(actualPct: number, expectedPct: number): number {
  return Math.abs(actualPct) - expectedPct;
}

Two details matter more than the formula:

The horizons differ. The expected move runs to option expiry (some of these expire days after the report, a few more than two weeks after). The actual move is one regular session, close to close (previous close to announcement-day close for before-open reports, announcement-day close to next close for after-close reports). A range that spans several days is easier to stay inside than a one-day move, so "15 of 21 inside" is not a measure of how accurate the options market is.
It is a size, not a direction. The straddle says how big the move was priced, nothing about up or down.

We also reject any expected-move record that was captured after the release, and anything incomplete is omitted rather than filled in.

What changed in the app

The dashboard now carries a selloff briefing on days like Nov 5: the index moves, VIX, a "Why" line that states a possible cause only as far as the sources support it, and the earnings that finished beyond their options-implied range.

The earnings calendar shows the week's running count and the reminder that the two horizons differ:

We also wrote a short explainer on what to check when US stocks sell off (VIX versus VIX3M, why the chip index can move more than the Nasdaq, and how to read an expected move in a selloff week): When US stocks sell off.

Caveats

The set is interim and excludes missing records.
Raw reactions include the market's own move that day.
21 observations is a small sample; read it as a log, not a statistic.

The scorecard API behind this is public if you want to check the rows: https://www.signumhq.com/api/earnings/scorecard?week=2026-11-02.

Disclosure: SIGNUM HQ is our own product, and this post was generated with AI for the SIGNUM HQ team. Information only, not investment advice or a recommendation to buy or sell any security.

If you have an iPhone and want to try it: code EARNINGS gives 1 month of PRO (first 500 redemptions): https://www.signumhq.com/app?code=EARNINGS&from=devto_1106

Model an observation with its expiry and time

SIGNUM HQ — Tue, 03 Nov 2026 14:45:10 +0000

An options observation is more than a numeric value. For an earnings comparison, the symbol, expiry and observation time determine what the value refers to. A value for a different expiry is not a safe substitute for a missing one.

One proposed model separates an observed value and its context from an unavailable state with a reason:

type Observation =
  | { state: "observed"; value: number; expiry: string; observedAt: string }
  | { state: "unavailable"; reason: "missing-source" | "request-failed" | "other-expiry" };

A consumer can then handle a missing source field differently from a failed request. A zero remains a possible observed value rather than a default for every failure.

A concrete case from tonight: AMD reports after the close on November 3. Using the at-the-money straddle for the first expiry after the event (the November 4 weekly, strike 467.5, straddle mid 42.55 against a 466.84 reference price, from the closing mids of the November 2 session), the options market implies a range of roughly plus or minus 9.1 percent. That figure says nothing about direction, and a realized move can land outside it. Its value only makes sense together with its expiry, its basis and its observation time, which is the whole point of the model above.

A useful review follows each state through every consumer, including caches and summaries. Test observed zero, missing input, request failure and another expiry as distinct cases. This is illustrative design, not a description of an implemented SIGNUM HQ schema or a claim that a test has passed.

Disclosure: I work on SIGNUM HQ, a US earnings and options research app, so this is our own product. This post was generated with AI for the SIGNUM HQ development team. If you want to see how the app shows these fields, there is one free month of PRO per device here: https://www.signumhq.com/app?camp=weekend-1101&from=devto_1103&l=en

Missing values are not zero in a small TypeScript model

SIGNUM HQ — Mon, 02 Nov 2026 14:47:41 +0000

This AI-generated design example is illustrative and does not describe deployed SIGNUM HQ code. A feed that is unavailable and an observed zero are different states. Converting both to zero can silently change an average or a condition.

type Reading = { status: 'observed'; value: number } | { status: 'missing' };
function observedValue(r: Reading): number | null {
  return r.status === 'observed' ? r.value : null;
}

Consumers must decide how to display or exclude missing observations. Keep the distinction through parsing, storage and presentation rather than trying to recover it after formatting.

Validate a ratio before formatting it as a percentage

SIGNUM HQ — Mon, 26 Oct 2026 01:49:05 +0000

Disclosure: AI was used to draft this standalone example. It is an input-validation exercise, not a description of code deployed in SIGNUM HQ.

A formatting function can make an invalid input look authoritative. For a ratio that represents a subset of a whole, validating the denominator and coverage should happen before producing a percentage. Missing, non-finite and out-of-range inputs deserve separate outcomes.

from decimal import Decimal, InvalidOperation

def subset_percent(part, whole):
    if part is None or whole is None:
        return None, "missing"
    try:
        p, w = Decimal(part), Decimal(whole)
    except (InvalidOperation, TypeError, ValueError):
        return None, "invalid"
    if not p.is_finite() or not w.is_finite():
        return None, "nonfinite"
    if w <= 0 or p < 0 or p > w:
        return None, "invalid_scope"
    return p / w * 100, "ok"

# Synthetic fixtures, not observed market values.
assert subset_percent("2", "5") == (Decimal("40.0"), "ok")
assert subset_percent(None, "5")[1] == "missing"
assert subset_percent("0", "0")[1] == "invalid_scope"
assert subset_percent("6", "5")[1] == "invalid_scope"
assert subset_percent("Infinity", "5")[1] == "nonfinite"

The subset assumption matters. This function is not a generic ratio validator: growth rates and leverage ratios can legitimately exceed one hundred percent. It also cannot detect a numerator from one session paired with a denominator from another. That requires metadata validation before this arithmetic step.

For a real record, preserve the original inputs, source, unit and observation window alongside the classification. Do not silently clamp a bad percentage into the display range. A separately reported validation failure makes the source problem reviewable.

Reference: https://docs.python.org/3/library/decimal.html

Where the same idea shows up in a product screen

I work on SIGNUM HQ, a US-stock options and earnings app. Its public "Earnings verification receipts" page applies the same habit to a different problem: each row keeps the option session, option expiry, the stored capturedAt timestamp and a "pre-announcement timing unverified" status next to the numbers, instead of presenting every comparison as if it were a clean forecast. The screenshot below is the week of 2026-10-19.

Public page: https://www.signumhq.com/en/receipts/earnings?from=devto_1026
App: https://www.signumhq.com/app?from=devto_1026

This is an engineering note, not investment advice or a recommendation about any security.

What options price in for MSFT, GOOGL, AMZN and INTC this earnings week, and how last week's five compared

SIGNUM HQ — Sat, 24 Oct 2026 12:01:37 +0000

Four big earnings reports land in the last days of October: Microsoft and Alphabet on Oct 28, Amazon and Intel on Oct 29, all after the close according to the companies' own announcements. Here is what the options market was pricing at Friday's close (Oct 23), how that number is computed, and how the same kind of number did last week. This is a description of option prices, not a forecast and not advice.

The number

Implied move = ATM straddle ÷ stock price. Take the strike nearest the stock price, add the call and put mid prices at that strike, and divide by the stock price. It is a market-implied range for the whole life of the option, and it carries no direction.

Closing mids on Oct 23, expiry Oct 30:

Ticker	Strike	Straddle	Stock	Implied move
MSFT	525	$27.68	$524.51	±5.3%
GOOGL	320	$19.38	$320.21	±6.1%
AMZN	247.5	$19.45	$248.00	±7.8%
INTC	87	$8.63	$86.96	±9.9%

Oct 30 is the first expiry that contains every reaction session (Oct 29 for MSFT and GOOGL, Oct 30 for AMZN and INTC). It also contains the days before the reports, so these are ranges to expiry, not the size of a one-day gap. The weekend and Monday-to-Wednesday option prices will move before the reports, so treat Friday's figures as a snapshot.

How the same kind of number did last week

I store the implied move from the app's earnings page and compare it with the first regular-session reaction after the report. Last week's five names:

Ticker	Implied move	Actual reaction	Inside the range?
NFLX	±9.3%	-5.3%	yes
NEE	±3.3%	-0.7%	yes
IBM	±7.4%	+0.3%	yes
LRCX	±7.1%	-11.8%	no
TSLA	±5.6%	-3.1%	yes

Four of five were inside, and LRCX moved about 1.7 times its implied range. I would not read that as a hit rate, for three reasons:

The implied move runs to the Oct 23 expiry while the reaction is a single session, so the periods differ.
The saved timestamps are not verified to be before each report (the page labels all five "Pre-announcement timing unverified"), so these are reference comparisons, not logged forecasts.
Five names is far too few to say anything about how reliable the options market is.

What I check before comparing any two numbers

Which expiry does the implied move run to?
Which session were the option prices taken from?
Was it saved before the release, and can that be shown?
Is the "actual" a close-to-close move over one regular session?

If one of those is unknown, the comparison gets labelled instead of counted.

Disclosure: I build SIGNUM HQ, a US-stock options app, and used AI to help draft this text. The figures come from the app's public API and earnings page. The app: https://www.signumhq.com/app?from=devto_1024

A timestamp gate for an earnings scorecard: reject observations made after the release

SIGNUM HQ — Wed, 21 Oct 2026 14:47:14 +0000

An earnings comparison can look reasonable while using information that was unavailable before the announcement. A useful first check is temporal: was the expected move actually captured before the event, and has the chosen outcome window finished?

Disclosure: this article was generated with AI. I work on SIGNUM HQ. The Python below is a standalone example using synthetic timestamps, not a description of our production implementation or a claim about forecasting performance.

The example accepts a comparison only when the observation precedes the release and the outcome window is complete.

def comparable(snapshot_at, release_at, outcome_ready_at, now):
    stamps = (snapshot_at, release_at, outcome_ready_at, now)
    if any(t.tzinfo is None or t.utcoffset() is None for t in stamps):
        raise ValueError("timezone required")
    return snapshot_at < release_at <= outcome_ready_at <= now

The strict inequality at the first boundary is intentional. An observation stamped exactly at the release is not sufficient evidence that it was available beforehand. A delayed retrieval of an older observation is different: retain the original observation timestamp instead of replacing it with retrieval time.

Using timezone-aware synthetic UTC timestamps, the local exercise checks five cases: a valid completed window, a post-release observation, an incomplete outcome, an outcome ending before the release, and a timestamp without a timezone. Reproduction: running the example file under Python 3.9.6 on my machine printed scorecard_cutoff: 5 cases passed. No market API is called by the example.

This gate is deliberately small. It cannot verify that a feed's timestamp is truthful, select the correct options expiry, establish whether prices are adjusted consistently, or decide which return window makes sense. Those definitions belong in the comparison record too.

Missing results should remain missing. A stock that has not completed the selected outcome window is not an observation of zero movement. Similarly, “inside the expected magnitude” is not a profitable options trade or a correct directional prediction.

For a real scorecard, I would keep the pre-event reference, release timestamp, expiry, outcome definition and data revision together. That makes the comparison inspectable before anyone summarizes it as a hit rate.

Reference: Python aware and naive datetime objects.

Product context, from the team that wrote this example: Earnings verification receipts, a public page that keeps the pre-announcement record, expiry and outcome window next to each comparison.

How we decide which earnings options records count as pre-announcement

SIGNUM HQ — Tue, 20 Oct 2026 14:49:04 +0000

AI disclosure: this article was drafted with generative AI for the SIGNUM HQ team, then checked against the public page it describes.

An earnings story is easy to tell after the fact. "The options market priced a 4% move, the stock fell 5.6%." But when did we record that 4%? Before the release, or after we already knew what happened? If we cannot answer that, the comparison tells a reader nothing. (Those numbers are real: they are the C row further down, and its range was reconstructed after the release, which is exactly why the question matters.)

We built a public page to make the answer inspectable: Earnings verification receipts. This post explains the record-keeping rules behind it, using the week of Oct 12 as the worked example. It is a description of method and limits, not a claim about forecasting skill.

Two numbers, two different horizons

For each scheduled report the page shows:

Options-implied range: the at-the-money call plus put price divided by the stock price. It describes option pricing through the option's expiry. It is not a SIGNUM forecast.
Actual reaction: one regular-session close-to-close change. For a before-open release, that is the previous trading close to the release-day close. For an after-close release, the release-day close to the next trading close. Extended-hours prices are excluded.

The horizons differ on purpose, and the page says so: the implied range runs to expiry, the reaction covers one trading day. "Within range" simply means the absolute reaction was no larger than the range.

What counts as "pre-announcement"

The row that matters is the storage timestamp (capturedAt). Only a capture stored before the known release time qualifies. If the company gives no exact time, the rule is deliberately conservative: before 00:00 ET on the release day for a before-open report, or before the regular close for an after-close report.

Everything else is labeled rather than dropped:

Status	Meaning
Pre-announcement record	Stored before the release by the rule above
Later reconstruction	Rebuilt from end-of-day chains, or stored after the release
Pre-announcement timing unverified	Ambiguous same-day capture
No record	Nothing comparable, and the row stays visible

The conservative rule can leave a genuinely early record in the "unverified" bucket. We accept that, because the opposite error (promoting a record that was really written after the fact) is the one that makes the whole page worthless.

The week of Oct 12 as data

Twelve announcements were scheduled. The page counted 4 pre-announcement pairs, 6 later reconstructions, 1 unverified timing and 1 missing comparison.

Stock	Options-implied range	Actual reaction	Status
ASML	±5.5%	-3.94%	Pre-announcement, within
MS	±4.0%	-2.75%	Pre-announcement, within
TSM	±3.7%	-1.80%	Pre-announcement, within
BAC	±4.2%	-4.76%	Pre-announcement, outside
C	±4.0%	-5.60%	Later reconstruction, outside
JNJ	±3.6%	-5.73%	Later reconstruction, outside

The last two rows are the reason the categories exist. C and JNJ both moved more than their ranges, but their ranges were rebuilt from end-of-day chains, so the page shows them for reference and keeps them out of the pre-announcement counts. Mixing them in would change the tally, and it would change what the tally means.

Guardrails we kept

Two sources for closes. Both closes come from one data vendor and are checked against a second source with a 0.1% tolerance. Rows without that confirmation are marked.
Daily bars are final only after the session. A reaction is not computed until the bar has had time to settle.
Missing stays missing. PLD had no announced release timing, so there is no reaction window and the row shows "No record" rather than a guess.
Not an immutable ledger. Records are kept for 120 days, and manual reconstruction, price corrections and overwrites are possible. A complete revision history is not available, and the page says that too.

A sketch of the classification

This is an illustration of the rule, not our production code:

type Timing = "bmo" | "amc";

function qualifies(
  capturedAt: Date,
  release: { at?: Date; timing: Timing; day: string; regularCloseET: Date },
): boolean {
  if (release.at) return capturedAt < release.at; // exact time known
  return release.timing === "bmo"
    ? capturedAt < startOfDayET(release.day) // before 00:00 ET on release day
    : capturedAt < release.regularCloseET;   // before the regular close
}

Anything that fails this check and came from an end-of-day chain becomes a later reconstruction. The unverified bucket exists for captures the rule cannot place on either side.

What the counts are not

The counts do not measure investment performance or prediction accuracy. Four pairs in one week is a very small sample, and an implied range that runs to expiry is not meant to bound a single day. The useful part is the audit trail: for every row you can see the option session, the expiry, the capture timestamp, the source and both closes, and decide for yourself how much weight it deserves.

I work on SIGNUM HQ, a US stock and options research app. The page described here: https://www.signumhq.com/en/receipts/earnings?from=devto_1021

How we compute session VWAP from 1-minute bars when the data feed does not give you one

SIGNUM HQ — Sun, 18 Oct 2026 09:27:48 +0000

Our stock app showed a "VWAP" number for every ticker. For a while that number was a lie. This is a short write-up of how we found out, and how we now compute session VWAP from 1-minute bars when the data feed does not give you one.

The VWAP row on the stock command screen, now computed from 1-minute bars.

What was wrong

The market-data snapshot we use has a vwap field on the daily aggregate, but it is empty for a lot of tickers, during the session and on weekends. At some point someone (me) filled the gap with the usual shortcut from a daily bar:

vwap ≈ (high + low + close) / 3

That is the typical price of one bar. It is not a volume-weighted average of anything. It happens to land near the real VWAP on quiet days, which is why nobody noticed. On a day with a big gap and a late-session fade it can be off by a lot, and it was labelled "VWAP" in the UI.

We removed the fake value. The field then became null everywhere and the screen showed an em dash. Honest, but useless. So the real fix was to compute it.

The computation

VWAP for a session is the sum of price times volume divided by the sum of volume, over the regular session only. We already cache the 1-minute chart bars per ticker for the chart screen, so we reuse them and make zero extra calls to the data vendor.

// bars: 1-minute bars, each tagged with its ET date and session (PRE | REG | POST)
function sessionVwap(bars) {
  const reg = bars.filter(b => b.session === 'REG' && b.volume > 0 && valid(b));
  if (!reg.length) return null;
  const day = latest(reg.map(b => b.etDate));          // newest trading day only
  let pv = 0, vol = 0;
  for (const b of reg.filter(b => b.etDate === day)) {
    pv  += ((b.high + b.low + b.close) / 3) * b.volume; // typical price x volume
    vol += b.volume;
  }
  return vol > 0 ? pv / vol : null;
}

Pre-market and after-hours bars are excluded on purpose. They are thin, they print at odd prices, and most people mean "regular session" when they say VWAP.

The guards that took longer than the formula

The formula is five lines. These were the parts that actually broke:

1. During the session, show only today's value. An early version merged the previous trading day's value when today's bars were not there yet (right after the open, or when the cache was stale). A VWAP that silently mixes two days is worse than a dash. During market hours we now accept only bars with today's ET date, and otherwise return null.

2. Treating null from the source as authoritative wiped good data. On weekends the vendor returns vwap = null for every ticker. A change that said "if the source says null, show null" erased Friday's perfectly valid session VWAP. We reverted it. The rule is now: decide by the session date, not by whether a field is null.

3. Holidays are not weekends. On a weekday market holiday there are no new bars, but the "latest trading day" logic must still point at the previous session. We wired the exit check to a US market holiday calendar so a Monday holiday keeps showing Friday's VWAP.

4. Stale cache refresh without a stampede. If the minute-bar cache is old, we refresh it in the background rather than making the user wait. The first version used "read lock, then set lock", which has a race: two requests could both refresh. It is now a single atomic SET key NX EX 60 per ticker, and if the lock is not acquired we simply do not call the vendor.

Tests that mattered

Empty bars (volume 0, null prices) are skipped, not treated as zero.
A PRE-only or zero-volume series returns null, not 0.
Two bars with known prices and volumes give an exactly checkable VWAP.
A "closed" lookup time and a "last trade" time are separate inputs. One of our tests failed because it used the 20:30 ET query time as the trade time. The test was wrong, the product code was fine.

Takeaways

A cheap approximation with the real name on it is a bug, even if it looks right most days.
When a field is missing, decide what "missing" means (before open, holiday, vendor gap) before you decide what to display.
Reusing data you already cache is the cheapest way to avoid new vendor calls and new rate limits.

This is from the data layer of SIGNUM HQ, a US-stock app I build solo (options flow, dark pool prints, earnings calendar).

Disclosure: I used an AI assistant to help draft and edit this post. The incident, the code and the conclusions are from my own project.