Rarity Index logo Rarity Index case study
Start a Project
Back to systems

System Deep Dive

Snapshot: May 2026

Boosted Charge, placement intelligence with operator proof.

Boosted Charge is a source-backed MVP for choosing physical charging-kiosk locations. The node01 repo proves the forecasting and recommendation shape: 35 engineered features, 7 connector modules, 13 database tables, XGBoost and Optuna training code, an operator dashboard, and a current test run with 145 passing tests.

  • 35engineered features
  • 7connector modules
  • 13database tables
  • 145passing tests
Boosted Charge dashboard proof showing kiosk coverage, ranked venue recommendations, hot spots, model status, and readiness checks

Proof Surfaces

The page now points at the node01 build, not a free-floating claim.

The source repo lives on node01 at /home/joe/Projects/boosted_charge. This public version shows dashboard shape, candidate comparison, feature/model contracts, and the current system map without exposing API keys or private environment values.

Boosted Charge dashboard proof with installed kiosks, trailing revenue, scored venues, model status, and readiness items
Operator dashboard The UI is not just endpoints: it gives operators kiosk coverage, recommendation ranks, model status, readiness checks, and product-shape notes.
Boosted Charge candidate comparison proof with map, ranked candidates, signal bars, and coverage mix
Candidate comparison The recommendation surface shows ranked venues, signal strengths, weaker signals, map context, and portfolio mix instead of a black-box score.
Boosted Charge model contract diagram showing features, XGBoost, Optuna, TimeSeriesSplit, model artifact, and test result
Model contract The training code has XGBoost, Optuna, TimeSeriesSplit, 35 feature names, a registry artifact, and an explicit training-fit diagnostic boundary.
Boosted Charge data contract diagram showing connector modules, database tables, API routes, and dashboard route
Data and API contract Seven connector modules feed weather, venue, event, payment, and demographic signals into 13 SQLAlchemy tables and five API route groups.
Boosted Charge system map showing connectors, features, model training, candidate scoring, dashboard, and public boundaries
System map The map was updated from the old 140-test and 12-table claims to the verified node01 counts: 145 tests and 13 tables.

Forecasting MVP

The model lane is real, with the right caveat.

Source inspection found the feature builder, model trainer, prediction wrapper, registry service, and model management API. The current metrics are training-fit diagnostics, so the public page no longer implies deployed forecast guarantees.

Feature engine
  • 35 features across time, weather, venue, foot-traffic proxy, demographics, and lag history.
  • Feature names are exported by source code and used by the model trainer.
  • Weather defaults and missing-value handling keep inference from failing on sparse data.
Training path
  • XGBoost regressor with default hyperparameters in source.
  • Optuna search path uses time-series cross-validation.
  • Model artifact exists with version, feature names, hyperparameters, metrics, and feature importance.
Claim boundary
  • The model status API labels RMSE, MAE, MAPE, and R2 as training-fit performance.
  • Holdout validation is still a before-production gate.
  • The page sells placement intelligence shape, not a production forecast guarantee.

Data Layer

Connector modules, tables, and API routes are all source-backed.

Connectors
  • Stripe, Open-Meteo, Google Places, Yelp, Ticketmaster, Eventbrite, and Census modules.
  • Connector code uses rate limits, headers, parsing, and health checks where applicable.
  • Public proof names connector modules, not live credentials or private API keys.
Schema
  • 13 SQLAlchemy tables cover venues, kiosks, transactions, weather, metrics, events, demographics, features, predictions, model registry, and candidate scoring.
  • Indexes and uniqueness constraints exist around time, location, external IDs, and score rows.
  • The old 12-table claim was corrected to 13.
API and dashboard
  • Forecast, kiosk, model, candidate, and dashboard route groups exist.
  • The dashboard is static app chrome backed by API-shaped JSON.
  • Swagger docs and local startup scripts are documented in the repo.

Recommendation Boundary

Venue ranking is scaffolded, inspectable, and deliberately not overclaimed.

Current scoring shape
  • Candidate scores split into projected revenue, foot traffic, demographics, competition, and venue quality.
  • Weights sum to one and produce a visible breakdown for operators.
  • The dashboard compares candidates by score and strongest or weakest signal.
Before production
  • Scoring weights still need real performance tuning.
  • Authentication, CORS hardening, HTTPS, rate limiting, and alerting remain production gates.
  • The public proof avoids live customer data and private environment values.

Stack

Python, FastAPI, PostgreSQL, SQLAlchemy, XGBoost, Optuna, and dashboard app chrome.

  • Python
  • FastAPI
  • PostgreSQL
  • SQLAlchemy
  • Alembic
  • Docker Compose
  • XGBoost
  • Optuna
  • TimeSeriesSplit
  • Feature store
  • Candidate scoring
  • 145 tests

Need ML recommendations that an operator can actually inspect?

That means feature contracts, model boundaries, connector discipline, visible scoring reasons, and enough tests to keep the story honest.

Email Rarity Index