Signal pipeline

The signal pipeline turns an incoming item into a public decision, and on a pass, a launch. It runs off a queue so the mock path and the real one are identical.

The queue and the keeper

News flows through a database queue rather than files, so an ingestion service writing rows looks the same to the pipeline as a test generator does. A keeper polls the queue on an interval, atomically claims a pending row so two workers never take the same one, runs the pipeline, and records the outcome on the row: launched, rejected or failed, along with the resulting signal and launch.

The keeper is the launch kill switch. When it is off, items queue up and nothing is scored or launched.

Scoring

Scoring reads the item (for news, the article text) and asks the model which watchlisted stock it is about, a 0 to 100 score, and the token metadata to launch. The result is persisted as a signal, passed or rejected at the configured threshold.

The model sits behind a provider interface, so the concrete model can change without touching the pipeline. Scoring requires a configured provider and errors without one; there is no silent fallback that would fabricate a decision.

On a pass

When a signal passes, the pipeline:

1. Generates a token image (falling back to a bundled default if generation is disabled or fails).
2. Uploads the image and metadata to an IPFS endpoint.
3. Calls the launch orchestrator with the hosted metadata URI.

The launch orchestrator ensures the stock's curve config exists, creates the launch row, drives the venue, and updates the row to its final state. It never leaves a launch stuck in a pending state: a launch ends up curve on success or failed on error.

Real ingestion

The first real ingestion source is a financial news feed, polled through a partner API and always filtered to the watchlisted underlyings, so the feed only carries news for stocks Botify can launch against. Each article is stripped to plain text (title, teaser or truncated body, tickers, source URL) and written as a queued item. The ingester never launches anything itself; the keeper does the scoring and launching.

Two properties keep ingestion honest across restarts:

• Dedup. Each article carries the source's unique id, so an already-seen article is skipped.
• Watermark. The next poll starts just after the newest item already stored, so a restart resumes rather than re-scanning, and the watermark only ever moves forward.