Progress Tracking in One Place.
A test result is more useful when I can find it beside the work it describes. BETA reads reports from test runs, records their history and links the results to the project's documentation and next steps.
Keeping test data separate
BETA strictly separates real field/bench evidence from mock/demo data. If a report is flagged as synthetic, it is quarantined and prevented from artificially inflating progress metrics.
Runs on Plain Python
A dependency-free Python server (built on http.server / ThreadingTCPServer) serves JSON data and generated HTML from local SQLite workspaces. Everything it needs ships with Python itself.
Ollama Integration
An optional Ollama model can review the local project data and suggest next steps. Those suggestions are labeled as advice; the dashboard still calculates progress from the recorded measurements.
Evolving the Dashboard.
The CLI Limits
The tool started as the "OMEGA proof generator", a simple command-line script. When the ecosystem grew to include hardware and team coordination, the CLI could no longer show the state of more than one project at a time.
Generated Web UI
Moving to a local web dashboard was required to visualize the sprawling data. BETA generates static HTML plus a JSON data feed served by a small stdlib server, which let the tool track itself (using BETA on BETA) alongside unrelated hardware projects.
How reports reach the dashboard
Data Ingestion Analytics Engine Dashboard UI ────────────── ──────────────── ──────────── report.json files ──┐ Quarantine & Sanitize Serve Local Dashboard Project Scans │ Calculate Deltas (stdlib http.server) GitHub issues + CI ─┼─► SQLite DB ──► Daily Snapshot + Trend ─► JSON ► Action Tracker AI Sessions ──┘ Generate Reports Trend Lines
One Command Interface.
A single PowerShell helper (dev.ps1) wraps the Python CLI behind a validated set of verbs that cover the day-to-day loop. It bootstraps and configures workspaces, ingests external report.json artifacts and project info, records measured evidence and work sessions, runs the test suite, serves the dashboard, and invokes the local AI analyst.
.\dev.ps1 doctor # environment + workspace checks .\dev.ps1 init-project # bootstrap a tracked workspace .\dev.ps1 evidence-template / record-evidence # capture measured runs .\dev.ps1 record-work # log a work session to the ledger .\dev.ps1 test / run-tests # BETA suite, or allowlisted per-project test commands .\dev.ps1 github-import / import-tests # pull issues + milestones, CI / test results .\dev.ps1 snapshot-project # persist a dated snapshot for trend lines .\dev.ps1 refresh / serve # rebuild + serve the local dashboard .\dev.ps1 ai / ask / manage-ai -Model gemma4:latest # advisory Ollama
Raw python -m beta <command> calls still work; dev.ps1 is a convenience layer over the same engine. The Python package itself ships with zero third-party dependencies.
Metrics That Trace to Data.
BETA calculates its metrics from the reports it has accepted. Each metric links back to the data behind it, and the dashboard gathers the resulting tasks into a prioritized list.
Evidence Quality
Correctness, effectiveness, efficiency, evidence coverage, backlog health, and regression load, plus per-claim coverage and data-quality checks (baseline availability, repeatability, scenario diversity, sample size).
Run Throughput
Ingest throughput, near-worst-case write and read times, station coverage, bathymetry, mesh routes, portal payload, database bytes per observation, and wire savings (compared run-over-run against the same scenario).
Project Velocity
Evidence velocity, repeat depth, connected-source coverage, active-measurement coverage, and AI availability, alongside PM metrics for runs/scenarios tracked, improved vs regressed metrics, and open P0/P1 work.
Metrics → Prioritized Backlog
The Plan, Manager and AI screens turn findings into tasks. Each task records where it came from, its priority, what to do next and what result would show that it helped. Missing measurements and other blockers remain visible. Suggestions from the AI are labeled separately.
When measurements are missing
BETA reports progress only as far as the evidence supports it. That choice has a deliberate, visible cost: until real field or bench evidence is provided, the charts can be entirely blank.
Showing what has not been measured
A project with no accepted reports shows Needs data and empty charts. A metric that has not been measured is labeled that way. This makes the missing work visible without suggesting a result that was never collected.
What Gets Quarantined
Reports carrying demo, synthetic, simulated, fixture, mock, dummy, fake, example, placeholder, template, or draft markers (plus the OMEGA-specific local-proof and coastal-demo tags) are quarantined before metrics run. (smoke is treated as a soft marker.) They stay visible as audit inputs but never drive charts, scores, or AI analysis.
Where a result came from
Every dashboard JSON and exported report records the BETA version, analysis schema, data-version ID, project config versions, real vs quarantined report counts, and the Ollama model used for advisory review, so you can tell which model and which data shaped a result without treating model output as proof.
Tracking Its Own Drift
When dashboards or reports are generated, BETA appends compact workspace/project records to version-history.json and compares the latest scoped record against the previous one, calling out material changes such as a different AI model, new real evidence, fewer quarantined reports, or a changed config version. BETA also persists a dated project snapshot each day, so every tracked metric carries a trend line over time. Each tracked project (for example omega and beta itself) gets its own scoped page and data feed; the workspace dashboard is only a project selector and does not combine metrics across projects.