Signals
Signals is the public-facing audit layer for the iSN.BiZ scanner stack. Every alert produced by our intelligence pipelines is written to a forward-returns ledger at the moment it fires and surfaced here on a delayed feed. The page you are reading is itself the product surface: a live, timestamped record of what the scanners caught, when they caught it, and how the underlying instruments moved afterward. This is not a marketing page describing a product roadmap — this is the ledger.
Signature Key Art
A cinematic visual system rendered for the Signals product surface — pipeline lattices, alert constellations, and forward-return arcs composited on the iSN.BiZ palette of charcoal, blue, and cyan.
Signal Sources
The Signals ledger draws from a fleet of independent scanners, each connected to a distinct primary-source feed. The current public window holds 1,969 tracked alerts across nine active scanners, with a seven-day delay applied between live subscriber publication and public ledger appearance.
The intelligence stack is organized around four production pipeline categories that map directly onto the iSN.BiZ revenue thesis. EDGAR intel ingests SEC filings — 8-K material events, SC 13D beneficial ownership notices, Form 4 insider transactions, and congressional STOCK Act periodic transaction reports — and produces structured filing-event alerts the moment new documents land in the EDGAR feed. Market arbitrage scans prediction-market venues, comparing implied probabilities and event-contract pricing across exchanges to surface mispricings before they decay. Muni bond intel processes EMMA and MSRB disclosure feeds across the roughly fifty-thousand-issuer municipal bond universe, extracting material event notices, continuing disclosure failures, and rating-change indicators. Basis monitoring watches USDA agricultural basis differentials at fourteen elevators across eight states, flagging anomalous spreads against historical distributions.
In the current public window, three of the nine active scanners are publishing alerts. basis-monitor is the dominant contributor, having produced seventy-six alerts of basis_anomaly type. gdpr-intel has produced eighteen alerts of enforcement_action type, watching European data-protection authorities for fines and rulings. fedreg-intel has produced six alerts of forward_regulation type, sourcing from the Federal Register publication queue. The remaining six scanners are armed and instrumented — their forward-return columns will populate as alert windows close and the daily backfill job lands the five-day, twenty-day, and sixty-day return values.
Pipeline Categories
- ✓ EDGAR intel — SEC filings (8-K, SC 13D, Form 4) and congressional STOCK Act periodic transaction reports, alerted at the moment of EDGAR publication
- ✓ Market arbitrage — prediction-market and event-contract pricing scanners surfacing cross-venue spread anomalies
- ✓ Muni bond intel — EMMA and MSRB feeds across the fifty-thousand-issuer municipal universe, surfacing material events and continuing-disclosure failures
- ✓ Basis monitoring — agricultural basis differentials at fourteen elevators across eight states, alerting on anomalous spreads
- ✓ GDPR enforcement intel — European data-protection authority enforcement actions and fines
- ✓ Federal Register intel — forward regulation publication scanner pulling from the Federal Register feed
- ✓ Forward-returns auto-backfill at 5d / 20d / 60d windows for every alert with a resolved ticker
Deep Dive: Signal Architecture
A four-stage pipeline transforms raw primary-source documents into ranked, timestamped, return-attributed alerts. Every stage is logged. Every alert writes one row. Predictions cannot be revised after the fact.
Stage 1 — Raw Source Ingestion
Each scanner connects directly to a primary-source feed. The EDGAR scanners poll the SEC filing index. The basis monitor pulls USDA grain-elevator quotes. The fedreg-intel scanner consumes the Federal Register's daily JSON publication. The gdpr-intel scanner reads enforcement-tracker feeds maintained by European data-protection authorities. There is no third-party aggregator in the path — each pipeline owns its source connection, its rate-limit posture, and its retry semantics. When a source feed is unreachable, the scanner records the gap rather than silently failing, so the ledger remains an honest record of what we actually saw versus what we missed.
Source connections are written in Python with the relevant feed-specific client libraries. The scanner runtime is orchestrated by an internal cron-driven scheduler (the same orchestrator that runs across the rest of the iSN.BiZ automated-pipelines fleet). New sources are added by registering a scanner module, defining the alert-emit schema, and wiring the cron entry — no platform changes required.
Stage 2 — Enrichment and Ticker Resolution
Each raw event is enriched with the metadata required to make it actionable. The enrichment stage assigns the event its signal_type classification (basis_anomaly, enforcement_action, forward_regulation, and others), tags it with its source scanner, and attempts to resolve the affected security tickers where applicable. Ticker resolution is non-trivial — a Federal Register notice on emissions standards may map cleanly to a basket of automaker tickers, while a basis anomaly at a Kansas grain elevator may require a derivative mapping rather than a direct equity ticker. Where resolution fails or does not apply, the ticker field is left empty rather than fabricated.
In the current public window, all alerts have an unresolved ticker field. This is expected behavior at this stage of the pipeline rollout: the basis-monitor, gdpr-intel, and fedreg-intel scanners that are currently publishing emit signals against domains where ticker resolution is the next implementation cycle, not a default behavior. The forward-return columns on those rows therefore remain null until ticker resolution lands and the backfill job has a target instrument to query.
Stage 3 — Cross-Signal Fusion and Ranking
Single-source alerts are commodity output. The edge in this stack lives in the overlaps. A correlator stage operates across the enriched alert stream and identifies when two or more scanners fire on the same name within a short causal window — a congressional periodic transaction report in a ticker that also has a recent 8-K, a forward-regulation notice in a sector that already has a rising basis anomaly, an EU enforcement action against a parent company that has an SC 13D event in the same week. Cross-signal fusion produces a ranking score and a fusion explanation that gets attached to the alert payload.
Ranking is intentionally conservative. A single-source alert is published with no boost. A two-source overlap is boosted modestly. A three-source overlap is boosted aggressively and surfaced at the top of the live feed. This conservatism is by design: we would rather under-rank a real signal than over-rank a coincidence, because the ledger is the marketing material — every false promotion costs credibility that compounds.
Stage 4 — Publish and Forward-Returns Backfill
At publish time, every alert writes exactly one row to the ledger. The row carries the alert date, source scanner, signal type, resolved ticker (or empty), and three forward-return columns initialized to null: return_5d, return_20d, and return_60d. A daily backfill job runs at end-of-session, walks the ledger for rows whose return windows have closed, and populates the forward-return values from market close data. We do not get to revise these numbers. We do not get to delete unfavorable rows. The ledger is append-only.
The public ledger you see on this page sits seven days behind the live subscriber feed. As the dataset matures and the forward-return aggregates become statistically meaningful, that delay will ratchet out toward thirty days — preserving the audit-trail value of the public ledger while protecting the live edge that subscribers pay for.
Signal Categories
Three signal types are currently producing alerts in the public window. Each is emitted by a distinct scanner and represents a distinct edge thesis.
basis_anomaly
Agricultural Basis Anomalies
Emitted by the basis-monitor scanner. Watches the spread between local cash grain prices at fourteen elevators across eight states and the corresponding futures contracts. Anomalous spreads against historical distributions trigger alerts. Currently the highest-volume scanner in the public window with seventy-six alerts.
enforcement_action
GDPR Enforcement Actions
Emitted by the gdpr-intel scanner. Tracks European data-protection authority enforcement actions, fines, and rulings. Eighteen alerts in the current public window. Targets the asymmetry between regulatory event timing and equity-market awareness for affected listed entities.
forward_regulation
Federal Register Forward Regulation
Emitted by the fedreg-intel scanner. Pulls from the Federal Register publication queue, identifying proposed and final rules whose sector exposure maps to listed equities. Six alerts in the current public window. Targets the regulatory-publication-to-market-pricing latency window.
Live Ledger
The dynamic feed below renders directly from data/signals-30d.json. Charts populate as forward-return aggregates land. The table is sortable on every column.
Hit Rate by Scanner
Percent of alerts with positive twenty-day return, by source scanner. Currently empty pending forward-return backfill once tickers resolve.
Median 20-Day Return by Signal Type
The middle return outcome by signal_type — robust to outliers. Currently empty pending forward-return backfill.
Recent Alerts — Public Window
Last hundred alerts, sortable. The public feed currently runs seven days behind the live subscriber feed and will ratchet to thirty days as the ledger matures.
| Date | Scanner | Signal | Ticker | 5d % | 20d % | 60d % |
|---|---|---|---|---|---|---|
| Loading delayed ledger… | ||||||
Implementation Details
The Signals page is the front-end of an append-only ledger. The renderer is intentionally thin; the source of truth is the JSON snapshot generated nightly by the backend job.
Append-Only Ledger Schema
Every alert row carries seven fields: alert_date, scanner, signal_type, ticker, return_5d, return_20d, and return_60d. Rows are written once at alert time. Forward-return columns are mutable exactly once: when the corresponding window closes and the backfill job lands the closing value. After that, the row is immutable.
Snapshot Aggregates
The nightly snapshot writes data/signals-30d.json with a header block (generated_at, delay_days, total_alerts, scanners_active), pre-computed aggregate maps (hit_rate_by_scanner, median_return_20d_by_signal, median_hit_rate_20d), and a recent_alerts array that the renderer slices to the most recent hundred. Aggregates are intentionally pre-computed server-side so the client renderer stays trivial and audit-traceable.
Renderer
The page is rendered by signals.js, a small vanilla-JS module that fetches the JSON snapshot, populates the four hero stat tiles, draws two Chart.js bar charts (hit rate by scanner and median twenty-day return by signal type), and renders the sortable alert table. Sorting is column-driven via data-sort attributes; numeric and date fields sort numerically, string fields sort lexicographically. The renderer is deliberately stateless — reload the page and you get a fresh fetch with no client-side caching.
Delay Window
The current snapshot carries delay_days: 7, meaning rows surfaced in the public ledger fire seven days after they hit the live subscriber feed. The snapshot also exposes the generated_at ISO timestamp, surfaced in the hero Last Refresh tile and the footer. Both values are honest; any drift between the displayed window and the actual ledger contents is a bug, not a feature.
Technology Stack
Operational Posture
Append-Only Ledger
Every alert writes one row at fire-time. Forward-return columns are populated exactly once by the backfill job and never revised. Predictions cannot be edited after the fact — the ledger is its own audit trail.
Pre-Computed Aggregates
Hit-rate and median-return aggregates are pre-computed server-side in the nightly snapshot. The client renderer never re-aggregates — it only displays. This keeps client-side logic small, deterministic, and trivially auditable from the JSON source.
Honest Empty States
When ticker resolution fails, the field is empty — not fabricated. When forward-return windows have not closed, the column is null — not synthesized. When aggregates are pending, the charts render empty — not back-filled with fictitious history.
Cron-Driven Pipeline
Scanners run under the same cron-driven orchestrator that powers the rest of the iSN.BiZ automated-pipelines fleet. Adding a new source is a scanner module plus a cron entry — no platform-level change. The pipeline scales by addition, not by replacement.
Why It Matters
Signals exists because the iSN.BiZ thesis is to be the infrastructure, not the user. The ledger is the storefront for an automated intelligence stack — the picks-and-shovels surface of a multi-pipeline data product line.
Audit Replaces Pitch
Most market-intelligence products are sold on a deck. Signals is sold on a ledger. The same evidence that justifies a subscription is the evidence visible on this page — just shifted seven days later. There is no separate sales narrative because the ledger is the narrative.
Infrastructure, Not User
Each scanner is a pipeline that produces structured output a customer integrates against, not a finished trading recommendation. The product is the data feed, the ranking, and the audit trail. What the customer does with the output is the customer's domain expertise, not ours.
Compounding Surface Area
Nine scanners are armed today. Six are awaiting the ticker-resolution implementation cycle. As each scanner lands and starts publishing, the ledger gains another column of evidence and another category of subscribable signal. The product surface compounds with every scanner that ships.
Subscribe to the Live Feed
The page above is the seven-day-delayed audit copy. The live subscriber feed runs in real time. To discuss data licensing, integration, or pipeline-specific subscriptions, contact iSN.BiZ directly.