aSPARK-insights
Engineering KPIs from graph and gate evidence — not from ticket metadata.
Engineering KPIs come from ticket metadata today — the only structured data available. Cycle time and velocity say nothing about architecture health or traceability coverage.
insights computes instead from what delivery already produces: the graph and the gate evidence. Real Story→Task, AC→QA and Task→Code coverage, each with its own sample size, plus a mid-cycle board that runs standalone from git alone (no graph needed), a release board that maps every git tag to the features it shipped — with measured release figures and each feature's own documents readable in place — and a feature lens that regroups the same data per feature instead of per release. Flow, architecture-health and policy metrics come next.
- ◆
Sealed snapshots
A snapshot freezes the state of graph and gate evidence — analyzable, comparable, not retroactively editable.
- ◆
Byte-stable rebuilds
Same input, same snapshot. The same determinism commitment the graph makes.
- ◆
CLI & MCP
Build and query snapshots by CLI or over MCP, with no service and no database.
- ◆
Traceability coverage
Real Story→Task, AC→QA and Task→Code numbers, each with its own sample size — an honest null instead of a guessed 0% or 100% when evidence is missing.
- ◆
Release board
Maps every git tag to the .spark features that shipped in it — newest release first, every feature document readable in place, as JSON or as a self-contained, offline HTML page.
- ◆
Measured release figures
Release count, date span, gap median and range, delivered scope — each piece of scope counted exactly once, in its oldest release. No health score, no pass/fail verdict, no trend line.
- ◆
Feature lens
The same data per feature instead of per release: one row per feature with spec date, 5-artifact status and the tag it shipped in, plus a pipeline grouped by gate.
Honest status: v0.12.0 ships real traceability metrics, an offline HTML report, MCP query, a mid-cycle and release board with measured figures, and the feature lens. Flow/cycle-time, architecture-health and policy metrics are not there yet — each blocked on graph or policy respectively, and it is not yet on PyPI. insights builds on graph, not on aSPARK-ci: the two are siblings, not a chain.
Each product has one responsibility and stable interfaces. A weakness in one must never require changes in another.
Does this fit your delivery process?
Start with Core on a pilot project. The workflow, knowledge graph and policy packs are all open on GitHub.