Files
production-analytics/docs/roadmap.md
T

77 lines
3.9 KiB
Markdown

# Roadmap
## 0. Bootstrap (this milestone)
Establish package boundaries, architecture documentation, example calculation
configuration, basic domain/protocol models, tests, and an optional local
TimescaleDB Compose design.
## 1. ENLYZE API exploration client/CLI (completed baseline)
A read-only, GET-only raw inspection CLI and fixture sanitizer are implemented.
Exploration established a K7 candidate mass-flow signal and speed gate; the
evidence and remaining uncertainties are recorded in `docs/enlyze-api.md`.
Continue to record sanitized fixtures for newly verified semantics.
## 2. Live material-consumption MVP (in progress)
The integration engine, ENLYZE gateway, single-cycle polling service, atomic
JSON checkpoint store, and configured continuous foreground polling runner are
implemented and covered by synthetic tests. Configure the validated K7 instance
in `config/k7-material-consumption.yaml`; start it with
`production-analytics run material-poll --config config/k7-material-consumption.yaml`.
Runtime options select the polling interval, state directory (default: ignored
`data/state/material/`), and existing secrets-file handling. Only one writer may
poll each machine/order state key.
The runner now persists cumulative material-consumption snapshots for Grafana in
PostgreSQL using `db/schema.sql`. JSON remains the restart checkpoint; PostgreSQL
stores derived time-series snapshots only. No Timescale-specific features are used.
A new order may first appear with a non-zero total after initial sample integration.
Grafana dashboard validation remains pending. No HTTP endpoints, application
containers, daemonization, or schedulers have been added.
Detect the currently active Production Run and production order, continuously
ingest new ENLYZE samples, maintain persistent incremental integration state,
and store/expose cumulative material consumption for Grafana. Implement this
as generic rate integration (`material_rate * elapsed_time`) subject to
configured machine/process-specific validity conditions, so it can serve more
than one machine/material pair. The first validated implementation is K7:
integrate `Stundenleistung Anlage` (kg/h) only while `Geschwindigkeit
Gesamtanlage > 0.5 m/min`; do not use `Anlage läuft` as the primary gate.
Bento 1 bentonite-powder consumption is the next analogous use case. Select
and validate its ENLYZE source variable and gating logic from process data
before implementing it; neither is defined yet.
## 3. Persistence foundation
Design and migrate a TimescaleDB schema for derived metrics/events, calculation
runs, Production Run/order context, and incremental state. Add Grafana-oriented
query examples.
## 4. Historical replay/backfill
Enable bounded historical Production Run replay and production-order analysis
using the same generic integration engine as live processing. Integrate each
Production Run separately and aggregate derived values at the production-order
level; never bridge gaps between runs. Include rerun/provenance behavior and
tests against sanitized fixtures.
## 5. Peak detection (first detector completed)
The generic configurable sawtooth detector is implemented: it retains the
current maximum, closes a cycle after a configurable below-peak fraction has
actual sample support for a configurable elapsed duration, and emits one
completed peak. Its pure state can later be persisted for incremental use. It
has been validated with a clean K7 roll-length reference signal and a more
variable Bento 2 roll-weight robustness signal; the latter includes plateaus,
non-zero resets, and varying peak heights without detector special cases.
## Later
State/cycle durations, rolling statistics, threshold events, derivatives, and
specific-consumption calculations. An optional historical mass-balance
refinement is actual QA/QS basis-weight data from SQL, replacing static article
basis weight; it is not required for the live material-consumption MVP.