The product family

Core plus six extensions, one responsibility each. Two hook into the loop today (guard, graph), two run standalone (insights, policy), two are planned (ci, memory). Core on its own is a complete, supported setup.

Available

⚙️

aSPARK Core

Shipped

Process. The deterministic Specify → Plan → Act → Review → Keep workflow with quality gates and traceability IDs. Defines how software is built.

View product →

🚦

aSPARK-guard

Shipped

Integrity. Deterministic gate enforcement outside the model, plus a hash ledger over every .spark/ write. Makes the gates hold — and keeps no override invisible.

View product →

🕸️

aSPARK-graph

Shipped

Knowledge. A deterministic engineering knowledge graph connecting stories, tasks, code, tests and releases. Knows what has been built.

View product →

🛡️

aSPARK-policy

Shipped

Governance. Enterprise-owned policy-as-code with hierarchical inheritance — 11 packs, tested JSON Schemas, adopted with one git submodule. Defines which rules every project must follow.

View product →

📊

aSPARK-insights

Shipped

Transparency. Engineering KPIs and delivery analytics — computed from graph and gate evidence, not ticket metadata. Real traceability coverage, a mid-cycle board, a release board with measured figures and a feature lens are in.

View product →

Planned

🔗

aSPARK-ci

Planned

Enforcement. Gate and policy enforcement inside existing CI/CD platforms — GitHub Actions, GitLab CI, Azure DevOps, Jenkins.

View product →

🧠

aSPARK-memory

Future

Memory. Architectural decisions and organizational lessons as durable engineering memory, anchored to the graph nodes they explain.

View product →

Separation of concerns

Core = how it's built. graph = what was built. policy = which rules apply. The core workflow never changes — only the policy changes.

Next step

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.

⚡ aSPARK on GitHub → How it works