aSPARK-policy
Turn PDFs into enforceable rules. Markdown explains the standards, a policy.yaml activates them, and every aSPARK agent consumes the same policy.
Turn PDFs into enforceable rules.
Markdown explains the standards, a policy.yaml activates them, and every aSPARK agent consumes the same policy — no duplicated prompts, no custom agents.
Adoption = one git submodule into .spark/policy. No Python, no tooling to run.
Hierarchical inheritance — predictable, not interpreted
| Case | Behavior |
|---|---|
| Scalar on two levels | more specific level wins |
| Lists | merged (!override to replace) |
| final: true | locked — lower levels may only tighten |
Corporate → business unit → department → project. final exists for the compliance case: a regulated org guarantees a rule holds in every project — without auditing each one.
A project combines packs across several axes — compliance, language, framework, cloud, architecture, platform. Grouped by category on disk, but every import id stays flat: aspark:owasp, never aspark:compliance/owasp. Your own packs live under company:.
External standards — one per regulated industry: payments (PCI-DSS v4.0), automotive cybersecurity (UN R155 / CSMS), plus cross-industry OWASP and ISO 27001.
MISRA sits on the language axis, next to Java — not in an industry bucket. A safety-critical C/C++ coding standard is exactly that: a coding standard, not an industry category.
Feed the Developer directly; react additionally switches on the existing ux lens.
Bind to the Engineering Manager. There is no cloud lens in Core yet — until then they are plain constraints.
Engineering Manager and Reviewer — likewise without a lens of its own so far.
The axis for platform standards is laid out in the catalog. SAP is the first pack on it.
Two kinds of pack — and only one may be locked
| Kind | final? | Examples |
|---|---|---|
| universal | yes | owasp · iso27001 · pci-dss · un-r155 |
| baseline | never | java · misra · spring · react · aws · azure |
The distinction decides what may be locked. The OWASP Top 10 is a fact of the industry — a corporate level may set it final. A baseline pack pinning Java 21 is a default, not a standard: every organization has its own conventions, so a baseline is a scaffold to tighten — never a lock.
Honest about scope: the packs are aSPARK's own summary interpretation of the standards — they reproduce no licensed rule text. UN R155 is deliberately anchored on the public UN regulation, not the paid ISO/SAE 21434. A pack is not a certification artifact: neither a QSA assessment nor a type approval.
Policies become quality gates instead of advisory documents — and every violation names the policy and rule it comes from. That's what makes the trail auditable.
Honest status: aSPARK-policy is usable at v0.2.0 — the format, JSON Schemas, rule anatomy (id/severity/scope/check) and 11 packs are in place, adopted with one git submodule, no Python and no tooling to run. What's still missing is machine enforcement: the validate CLI and the /charter binding. The policy is readable, inheritable and auditable today — but no agent picks it up automatically yet.
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.