Skip to content
BranchesTags

Repository files navigation

SignalScope

SignalScope is a config-driven competitive intelligence backend and reviewer-facing dashboard for tracking public signals across organizations, products, networks, initiatives, and open-source projects.

The default demo dataset is based on Blockstream and related competitors/comparables, but the architecture stays generic: another team should be able to replace the tracked entity set through configuration rather than application rewrites.

What SignalScope does today

SignalScope already delivers a working prototype across the three assignment layers:

  1. Data ingestion
    • modular fetchers for GitHub, query-based news RSS, and changelog sources
  2. Storage and processing
    • SQLite persistence, repeated-run history, deterministic one-shot scheduling, alert materialization, and candidate suggestion persistence
  3. Reviewer-facing delivery
    • a local dashboard for scanning the watchlist, reviewing surfaced changes, comparing entities quickly, checking recent signal evidence, and running refresh actions without reading SQLite directly

Important honesty note:

  • the current dashboard is a reviewer MVP, not a fully expanded multi-page product
  • drill-down pages, richer compare workflows, and a public read-only API remain future work
  • the current scheduler is deterministic one-shot execution, not a long-running daemon

Why this project exists

Blockstream operates across multiple verticals:

  • hardware wallet
  • software wallet
  • sidechain / L2 infrastructure
  • custody
  • research
  • satellite distribution
  • open-source developer tooling

Tracking the competitive landscape across those areas manually is fragmented and time-consuming. SignalScope provides one persisted workspace for:

  • who matters right now
  • what changed recently
  • where to focus next
  • how trustworthy the current source coverage is

Current repository status

The current main branch implements a backend-processing baseline plus a reviewer dashboard MVP.

Implemented now

Ingestion

  • typed JSON config-pack loading with strict unknown-field rejection
  • cross-file validation for entities, sources, bindings, alerts, and schedules
  • fetch runtime by source kind, with optional binding narrowing
  • source fetchers for:
    • GitHub
    • query-based news RSS
    • changelog RSS and GitHub releases
  • optional GITHUB_TOKEN support for GitHub-backed requests
  • deterministic fixture-based and end-to-end tests without live-network CI dependencies

Persistence

  • SQLite bootstrap with embedded migrations
  • catalog/config persistence for:
    • datasets
    • entities
    • relationships
    • sources
    • bindings
    • alert_rules
    • schedule_jobs
  • observation persistence for:
    • fetch_runs
    • metric_snapshots
    • content_items
  • processing persistence for:
    • schedule_runs
    • alert_events
    • candidate_suggestions

Processing

  • repeated same-DB history preservation across fetch runs
  • deterministic one-shot scheduler execution for due jobs
  • persisted schedule_runs
  • alert evaluation over stored history
  • persisted alert_events
  • candidate discovery from repeated news co-mentions
  • persisted candidate_suggestions

Reviewer dashboard

  • local serve mode
  • overview-first reviewer workspace
  • market radar table with search, sorting, filtering, and quick compare
  • review queue for alerts and candidate suggestions
  • recent signals feed with clickable source links
  • source health panel
  • action center for:
    • scheduled refresh + alert processing
    • manual GitHub sync
    • manual news sync
    • manual changelog sync

Still intentionally deferred

The following areas remain out of scope for the current prototype:

  • app-store fetchers
  • social fetchers
  • owner-scoped github.contributors aggregation
  • long-running scheduler daemon/process manager behavior
  • multi-page dashboard navigation and richer drill-down flows
  • dedicated entity detail pages
  • dedicated compare page with arbitrary URL-based selection
  • a public read-only HTTP API surface beyond the internal dashboard action endpoint
  • advanced NLP/entity resolution beyond deterministic heuristics

Design principles

  • Config-driven by default Tracked entities, bindings, schedules, and alert rules come from external configuration.
  • Generic model The system supports organizations, products, networks, initiatives, benchmark groups, and open-source projects.
  • Persist before present UI and later API work read SQLite state rather than live upstream responses.
  • Single-binary deployment No separate frontend build step is required for the current reviewer dashboard.
  • Honest scope reporting The repository should describe what is shipped now, not future intent.
  • Reviewer usability over backend opacity The dashboard should help a non-technical reviewer understand what changed without opening the database manually.

Requirements

  • Go toolchain matching go.mod
  • Python 3 for repository hygiene scripts
  • optional sqlite3 CLI for direct table inspection
  • optional GITHUB_TOKEN for better GitHub API rate-limit headroom

Environment variables

Optional GitHub auth

GitHub-backed requests work without authentication, but anonymous rate limits are easy to hit during manual review.

export GITHUB_TOKEN=<optional-token>

Reviewer Demo Database (data.db)

For evaluation purposes, this repository includes a pre-populated SQLite database (data.db). This allows reviewers to immediately see the dashboard populated with historical data and candidates, without needing to run the ingestion fetchers manually.

To launch the dashboard using this pre-populated database, simply run:

go run ./cmd/signalscope serve --config configs/demo/blockstream --db data.db

Quickstart

1. Validate the demo config pack

go run ./cmd/signalscope check-config --config configs/demo/blockstream

2. Seed a clean reviewer database

go run ./cmd/signalscope seed-demo --config configs/demo/blockstream --db /tmp/signalscope-demo.db

3. Ingest public signals into the same SQLite path

go run ./cmd/signalscope fetch --config configs/demo/blockstream --db /tmp/signalscope-demo.db --source github
go run ./cmd/signalscope fetch --config configs/demo/blockstream --db /tmp/signalscope-demo.db --source news_rss
go run ./cmd/signalscope fetch --config configs/demo/blockstream --db /tmp/signalscope-demo.db --source changelog

4. Run the deterministic scheduler and processing pass

go run ./cmd/signalscope schedule --config configs/demo/blockstream --db /tmp/signalscope-demo.db

This will:

  • execute due schedule jobs
  • persist schedule_runs
  • evaluate alerts from stored evidence
  • persist alert_events
  • update candidate_suggestions

5. Launch the reviewer dashboard

go run ./cmd/signalscope serve --config configs/demo/blockstream --db /tmp/signalscope-demo.db

Open:

http://localhost:8080

Recommended reviewer demo flow

For the strongest end-to-end walkthrough, use one database path and keep accumulating history in it.

go run ./cmd/signalscope check-config --config configs/demo/blockstream
go run ./cmd/signalscope seed-demo --config configs/demo/blockstream --db /tmp/signalscope-review.db

go run ./cmd/signalscope fetch --config configs/demo/blockstream --db /tmp/signalscope-review.db --source news_rss
go run ./cmd/signalscope fetch --config configs/demo/blockstream --db /tmp/signalscope-review.db --source changelog
go run ./cmd/signalscope fetch --config configs/demo/blockstream --db /tmp/signalscope-review.db --source github

go run ./cmd/signalscope schedule --config configs/demo/blockstream --db /tmp/signalscope-review.db

go run ./cmd/signalscope serve --config configs/demo/blockstream --db /tmp/signalscope-review.db

Inside the dashboard:

  1. start with the Review queue
  2. scan the Market radar
  3. pin two names in Quick compare
  4. inspect Recent signals
  5. confirm Source health
  6. optionally use Action center to refresh data live

Dashboard usage

Review queue

The review queue is the shortest path to user value.

It surfaces:

  • alerts meaningful changes detected from stored history
  • candidates names that appear repeatedly near tracked entities in news and may deserve manual watchlist review

Market radar

The market radar is the main scan surface. It supports:

  • search by name, kind, or vertical
  • type filters
  • sorting by:
    • smart priority
    • latest activity
    • signal coverage
    • recent engineering
    • GitHub stars
    • name
  • quick left/right compare selection

Recent signals

The recent signals panel shows the latest stored content items, including:

  • source family
  • content type
  • entity
  • timestamp
  • direct external link when available

Source health

Source health should be checked before trusting flat or missing metrics.

States are interpreted as:

  • Healthy recent runs look stable
  • Watch some runs failed or the source has not been exercised yet
  • Degraded recent fetches failed consistently
  • Planned source family is reserved but not enabled in the current demo

Action center

The dashboard exposes an internal action endpoint for reviewer convenience.

Recommended first action:

  • Refresh due sources + update review queue

Advanced manual actions:

  • GitHub only
  • News only
  • Changelog only

Important note:

  • this internal /api/action endpoint exists only for the local reviewer dashboard
  • it is not the public API surface planned for later milestones

Command surface

Command Purpose Status
check-config load and validate a config pack implemented
seed-demo create a clean SQLite baseline from the selected pack implemented
fetch run ingestion for one source kind implemented
schedule run deterministic one-shot scheduler execution and processing implemented
serve run the reviewer dashboard on localhost:8080 implemented

Runtime notes

  • fetch --source selects by canonical source kind, not config source ID
  • repeated fetch runs against the same SQLite path preserve prior observation history
  • seed-demo is the explicit reset/bootstrap path when a clean dataset is desired
  • fetch returns a non-zero exit code when any selected binding fails
  • schedule returns a non-zero exit code on partial or failed scheduled execution
  • the current scheduler is deterministic one-shot execution for reproducible review and CI
  • serve automatically bootstraps the database and synchronizes the selected config pack before starting

Current source coverage

GitHub

Implemented coverage includes:

  • repository-scoped metrics
  • owner-scoped aggregation
  • optional token auth
  • persisted snapshots for:
    • stars
    • forks
    • open issues
    • contributors (repo-scoped)
    • commits in the last 30 days
    • commits in the last 90 days
    • latest release date
    • public repo count (owner-scoped)

News RSS

Implemented coverage includes:

  • query-based RSS search
  • deduplicated content persistence
  • news.article_count
  • candidate discovery from repeated co-mentions

Current documented provider:

  • Google News RSS search

Changelog

Implemented coverage includes:

  • GitHub releases
  • RSS changelog feeds

Normalized content types include:

  • release
  • changelog_entry

Persistence model

The SQLite write side currently includes:

Catalog/config state

  • datasets
  • entities
  • relationships
  • sources
  • bindings
  • alert_rules
  • schedule_jobs

Ingestion/observations

  • fetch_runs
  • metric_snapshots
  • content_items

Processing

  • schedule_runs
  • alert_events
  • candidate_suggestions

Manual SQLite inspection

The current reviewer workflow is intentionally inspectable.

Ingestion history

sqlite3 /tmp/signalscope-review.db "SELECT id, source_id, binding_id, status, started_at, finished_at, records_written, metrics_written, content_items_written FROM fetch_runs ORDER BY id DESC LIMIT 20;"
sqlite3 /tmp/signalscope-review.db "SELECT binding_id, metric_key, metric_value_num, metric_value_text, scope_key, captured_at FROM metric_snapshots ORDER BY id DESC LIMIT 20;"
sqlite3 /tmp/signalscope-review.db "SELECT binding_id, item_type, title, url, published_at, discovered_at FROM content_items ORDER BY id DESC LIMIT 20;"

Scheduler and processing

sqlite3 /tmp/signalscope-review.db "SELECT id, schedule_job_id, source_id, status, fetch_runs_started, fetch_runs_succeeded, fetch_runs_failed, started_at, finished_at FROM schedule_runs ORDER BY id DESC LIMIT 20;"
sqlite3 /tmp/signalscope-review.db "SELECT id, alert_rule_id, entity_id, source_id, severity, status, observed_at, triggered_at, resolved_at FROM alert_events ORDER BY id DESC LIMIT 20;"
sqlite3 /tmp/signalscope-review.db "SELECT id, alert_rule_id, candidate_key, display_name, discovered_from_entity_id, source_id, mention_count, first_seen_at, last_seen_at, status FROM candidate_suggestions ORDER BY id DESC LIMIT 20;"

Validation

Run the full validation suite with:

make ci

Or run the steps manually:

python3 ./scripts/trim-whitespace.py --check
go vet ./...
go test ./...

Repository structure

Important paths:

cmd/signalscope/          # CLI entrypoint
internal/config/          # config loading and validation
internal/fetch/           # source fetchers and fetch runtime
internal/schedule/        # deterministic one-shot scheduler runtime
internal/alerts/          # alert and candidate processing
internal/storage/         # SQLite bootstrap, persistence, sync, and processing state
configs/demo/blockstream/ # default reviewer dataset
docs/                     # architecture, data model, configuration, and roadmap
migrations/               # embedded SQLite migrations

Documentation

Primary documents:

Release history currently documented in:

What is strongest in this prototype

If you are reviewing this project as a user rather than a backend specialist, the most valuable parts today are:

  • the review queue
  • the market radar
  • the ability to refresh due sources and update alerts in one click
  • the source health context
  • the fact that all visible conclusions come from persisted SQLite state, not ad-hoc live request handling inside the UI

Attribution

Competitive Intelligence Dashboard, Plan B Network 2026, initiated by Aron Clementi. Contributor: Cristian Garcia (@CrisSTEM).

Disclaimer

SignalScope uses public APIs and public web feeds. Data can be incomplete, delayed, sparse, or noisy. This tool is for informational and reviewer purposes only and comes with no warranty.

License

MIT. See LICENSE.

About

Config-driven competitive intelligence dashboard for tracking public signals, historical metrics, alerts, and competitor intelligence.

Resources

Readme
MIT license

Contributing

Contributing
Activity

Stars

1 star

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages