ADR 001 — Multi-framework rule book

Status: Accepted Date: 2026-05-09

Context

Secruna originally shipped one rule book — the EU AI Act pack — in rule_book/v1/ with no namespacing. Plan 96 introduced a second framework (RICS) and made it clear the single-pack assumption would not scale: rules, categories, customer-facing copy, and the eval golden set all needed per-framework versions.

Two paths were available:

1. Tag-on-row — keep a single flat rule book, add a framework column to each rule, and filter at evaluation time.
2. Per-framework directory — split the YAML into rule_book/v1/{framework-slug}/ and load each separately.

Decision

Adopt per-framework directories under a shared schema version.

The rule book is now organised as:

rule_book/
  v1/
    eu-ai-act/    (19 rules)
    rics/         (5 rules)
    uk-defence-ai-playbook/   (6 rules)
    ds-05-138/    (in flight)

The loader walks each directory at process start, validates against the shared rule schema, and registers rules in an in-memory index keyed by (framework, rule_id). Per-framework category enums (Plan 96 WI-3) are namespaced under the framework slug.

Consequences

Positive

• New frameworks are added by dropping a directory of YAML files — no schema migration, no orchestration code change.
• Per-tenant subscription gating (Plan 103, ADR 003) becomes a simple filter on framework slug rather than a per-rule allow-list.
• The eval golden set partitions cleanly by framework, so per-rule F1 (Plan 96 WI-8) is computable per framework without joins.
• Customer-facing copy (Plan 90) lives next to the rule it describes, which keeps drift down.

Negative

• Cross-framework rules (rules that should fire on artifacts regardless of which frameworks the tenant subscribes to) have no natural home. We have not needed any yet, but if we did the current layout would push us toward a _shared/ pseudo-framework.
• The loader does more I/O at start-up — once per framework — but the volume is small and the work is one-shot.