The dataset

Every analysis on RAI·N·avigator reads from one file, `src/data/knowledge-graph.json`, currently at version 2.13.0 (dated 2026-08-28). It carries 475 nodes across 16 node types, joined by 1716 edges of 24 edge types, for an average of 7.2 edges per node.

• 88 regulation nodes and 53 standard nodes — the legal and technical-standard layer.
• 45 use-case nodes across 17 sectors — the catalogue.
• 2 role nodes, 15 control-objective nodes, 33 evidence-artifact nodes.
• 56 architectural component nodes, 28 pattern nodes, 19 blueprint nodes.
• 31 threat nodes and 17 vendor-category nodes.
• 29 jurisdiction registry nodes and 8 non-binding policy-instrument nodes.

Structural integrity is measured, not assumed: this build carries 0 orphan nodes and 0 broken references. Those two counts are read from the same generated projection this chapter cites — see the "Correctness measurements" chapter for what else is measured.

The regulatory layer is not just "AI law": it spans AI (20), data protection (28), cyber & resilience (8), online safety & platform law (4), product safety & liability (5), financial services (11), sector, market & employment law (12). — because a use case's obligations rarely come from a single regime.

How it is built and shipped

src/lib/kg/data.ts loads the JSON once, types every node and edge, and exposes lookup helpers (N, byType, outE, and friends) that the rest of the app imports — no page re-parses or re-derives the raw graph.

A build step (scripts/generate-catalog.ts) projects that graph into src/data/catalog.generated.json: aggregate counts, the release timeline, upcoming deadlines and per-layer breakdowns. This handbook, /correctness, /graph-stats and the landing page all read that same projection, so a count on one page cannot silently disagree with the same count on another.

Curated changes land through the community proposal pipeline (see chapter 6): a diff is applied, a new graph version is written, and the projection is regenerated. There is no live database write path into the graph JSON itself outside that pipeline.

Access model: the graph is open to USE and to inspect claim by claim — every node, citation and reasoning trace is publicly browsable, and each conclusion you run exports as your own dossier, test plan, evidence work list or Annex-IV skeleton. Bulk export of the graph itself is not offered; full-graph and large-projection downloads are platform-admin affordances. Honest limit: the reasoner runs in your browser, so the graph JSON ships in the app bundle and a determined actor can recover it from network traffic. The lockdown removes the convenient bulk copy — it is not a technical guarantee. Moving the reasoner server-side would change that, at the cost of latency and offline use; that remains an open architectural decision.

See the live graph statistics page →

Browse the 48-release changelog →

Four traversal directions

The entry hub at /start presents four traversal directions through the graph, at increasing distance from "I have a use case":

The fifth: the Risk & Value Evaluator

Alongside the four traversal routes, /evaluator adds the business-risk perspective a pure compliance review leaves out: deterministic PRIO/ROAI scoring, FAIR-AIR expected loss, compliance cost bands, a 3-year return-on-AI-investment figure, and a verdict drawn from one of five decision pathways (proceed, scope down, standard controls, fast-track, or re-architect / terminate).

It shares the same reasoner and the same evaluator pipeline ("src/lib/evaluator/pipeline.ts") that the four traversal routes call into for their own cost and confidence figures, so a use case scored here and a use case scored through Route 1 read off the same numbers.

Browsing instead of asking: /catalog

/catalog is the read path rather than an analysis route: it lists all 45 authored use-case profiles across 17 sectors so a reader can pick a close match instead of describing their own system from scratch, then hands off into the same reasoner as Route 1.

The registry

The jurisdiction registry lives in the graph itself (meta.jurisdictions), never hand-typed in application code, so no page can claim coverage the graph does not carry. This graph version records 29 jurisdiction entries across 7 regions: Cross-jurisdiction (1), Europe (5), North America (5), Latin America (1), Asia-Pacific (9), Middle East (2), Africa (6).

The busiest entries in the current catalog projection: European Union (29), Cross-jurisdiction bridges (25), United States (federal) (20), China (7), Germany (7), Singapore (6).

The four maturity tiers

Every jurisdiction is placed on one of four tiers — a statement about legal status, deliberately not a quality score:

Enforcement intensity is recorded as a separate axis — enforcement high, enforcement medium, enforcement low, not yet enforced, dormant in practice — because a binding law with no active enforcement reads very differently from one with active fines.

Why tier and enforcement feed the confidence model

Maturity tier and enforcement intensity together decide how fast a jurisdiction's legal picture moves (its "churn class"), which in turn sets how many months a verification stays trustworthy before the confidence model marks it stale — see the revalidation windows in the next chapter.

The three bands

No UI component may hardcode a band; every band the product shows is computed by src/lib/kg/confidence.ts from five weighted factors carried on the nodes and edges already in the graph, aggregated weakest-link across the whole derivation chain.

The five factors and their weights: Source tier (30%), Verification age (20%), Status certainty (25%), Community hardening (10%), Derivation kind (15%). Source tier and status certainty dominate, because only a primary, in-force text can be called law — the rest modulate how much that claim has been checked.

Revalidation windows

A verification date stops meaning anything once a jurisdiction's law has plausibly moved past it. The revalidation window is derived, not guessed:

The evidence dossier

Any conclusion can be exported as an Evidence Dossier: the verbatim inputs, every hop of the traversal with its citation (or an explicit "uncited" marker — silent gaps are refused), the graph fingerprint (version, date and a SHA-256 content hash computed at build time), and a reproducibility statement.

The guided-workflow dossier

/workflow orchestrates rather than reasons: it reads out of things that already exist — the reasoner's conclusion, the penalty model, the evidence layer, the crosswalk, the evaluator cost bands, the confidence model and the evidence dossier — and assembles them into one document. A section with nothing in the graph for a given case says so instead of narrating around the gap.

Required artifacts are grouped by class: Documents & files, Assessments, Test reports, Log records, Process records, Registry entries.

Open the guided workflow →

The test-plan generator

/test-plan derives WHAT must be proven straight from the graph across seven derivation families, and never invents legal content — every emitted scenario must resolve to at least one origin node in the graph or it is not emitted:

• Obligation-derived
• Threat-derived
• Jurisdiction-differential
• Evidence-verification
• Boundary and classification
• Conflict resolution
• Negative (must-not-do)

The generator also computes an honest coverage summary: it names the applicable obligations for which the graph derived no test, rather than reporting a single percentage and stopping.

Open the test-plan generator →

Credits

The credit ledger has exactly two sanctioned write paths, both server-side — a member cannot mint or burn a credit from the browser. Prices and earnings are presentation constants mirrored in the server-side spend/award functions:

Only the first two endorsers of an item earn a credit for validating it — a review, not applause.

The recognition ladder

Ranks are milestones, not scores — there is deliberately no point total or leaderboard. They are derived from accepted contributions counted by the database: New contributor → Verified Contributor (1+ accepted) → Reviewer (5+ accepted) → Domain Steward (25+ accepted, plus curator-confirmed stewardship of a domain). The curator-granted Expert role is a separate axis reflecting professional credentials, not accepted-contribution volume.

Verification and disputes

A member can submit a verification (a fresher status, date and source for an existing node) or a dispute against a claim. Accepting a verification requires the curator role, re-validates the payload server-side, and writes it as a new active graph version through a non-destructive diff — the same security shape as every other accepted proposal.

Open the verification queue →

Browse contributors and their accepted work →

The 6 walkers

Every name, schedule and purpose below is read at render time from WALKER_INFO in src/lib/agents/walkers.ts — this handbook never hardcodes the walker count or roster, so it cannot go stale if a walker is added or renamed.

Budgets

Each weekly run is capped by hard budget ceilings for searches, LLM calls and proposals, configurable by environment variable with safe defaults. A walker that exhausts a budget stops for the week rather than continuing uncapped; the same walker cannot start a second run in the same ISO week for idempotency.

Where the runs are visible

Read the full agentic architecture page →

See the run history →

The golden suite

The golden validation suite runs authored expectations against the deterministic reasoner across 7 case categories: Externally-authored scenarios, Jurisdiction pairs, Temporal status, Adversarial input, Degenerate input, Confidence calibration, Role pairs. It reports a matrix — exclusion precision, inclusion recall, flag recall, and known-failing cases accepted with a named owner — deliberately never a single accuracy percentage, because that would hide exactly what the suite exists to expose.

Mutation testing

A recorded mutation run (2026-08-28, graph 2.13.0) injected 8 mutants per operator across 7 fault operators — 56 mutants total, 20 killed by the 60-case suite (reaching 309 of 475 graph nodes, with 58 nodes actually asserted on). Named survivors are published rather than folded into a rate, because a kill rate without its survivors hides exactly the faults nobody has written a case for yet.

The fault operators: applies-in-flip, status-force-in-force, triggers-delete, triggers-spurious, tier-shift, gate-invert, crosswalk-swap.

See it live

Open /correctness →

Interactive architecture view

Every control and component node may carry two optional authored fields — an enforcement layer and a one-phrase slot in the request path. The canvas on the /describe result and in the workflow dossier reads those fields off the nodes the footprint actually resolved and lays them out across 6 layers: Client / UI → Gateway / Interceptors → Application / Orchestration → Model / Retrieval → Data → Observability / Governance. Of 71 control and component nodes in the graph, 69 carry a placement; the remaining 2 are listed under “not yet placed” rather than guessed into a layer.

Each placed element opens a panel with what it is, the legal anchors it operationalizes with their citations, the evidence nodes that prove it, and its testable check — all read from the graph, nothing authored per use case. Elements are tab-focusable and open with Enter, and the whole canvas degrades to a plain per-layer list on small viewports and in print.

Compliance artifact pack

From the same footprint the app generates implementation templates: an oversight-interceptor config for Art. 14, a reason-record JSON Schema for Art. 86 and adverse-action notices, an evaluation and bias-log spec for Art. 9/10/15, a vector-ACL retrieval probe spec, and a PCCP corridor record implementing Art. 43(4). Each is bundled into the workflow dossier and downloadable individually.

An artifact appears only when the obligation it operationalizes is in the footprint and the tier actually carries that duty — a minimal-risk case gets no adverse-decision letter schema. Every artifact carries a header block with the graph version and hash, the use case id, the date, and the sentence that it is an engineering starting point, not legal advice.

Compliance gate manifest for CI

compliance-gate.json is a projection of one use case's obligation chains — obligations → controls → evidence — into gates that a CI step can assert on. Each gate carries its legal anchors with citation URLs, the evidence it requires, a human-readable check, and a blocking flag that is true only where the obligation is mandatory for the resolved tier. A prohibited outcome collapses the manifest to a single hard gate with its legal basis.

The export is a footprint projection, not the graph: it contains only the nodes this one conclusion resolved, so it stays inside the extraction lockdown. It validates against a published JSON Schema that ships with the app.

# Example only — assert on the manifest in your own pipeline.
- name: Check RAIN compliance gates
  run: |
    jq -e '.gates | map(select(.blocking)) | length as $n
           | if $n == 0 then true
             else error("\($n) blocking compliance gate(s) unsatisfied") end' \
      compliance-gate.json

Product classes, not vendor rankings

The market layer models 17 product CLASSES as the stable objects, each mapped to the control objectives it genuinely addresses, with a note stating the basis of every mapping. Named products are not nodes: they are structured, disputable examples on the class they belong to, carrying vendor-stated claims with an as-of date. Selection metrics are class-level — how a buyer should choose inside a class — never a score across named companies.

• We do not rank vendors and do not reproduce third-party quadrants or market-position labels; an integrity rule fails the build if such a label appears in the data.
• We do not assert any vendor's regulatory coverage. Vendor-to-article edges do not exist, and there is no coverage-depth or audit-ready field. Mapping happens at class level only.
• A certification renders as a certification only from a structured, verifiable certificate or registry reference with the date it was checked. Prose containing the word “certification” is an ordinary claim.
• When nothing resolves, we say nothing resolved and why. There is no arbitrary shortlist standing in for a recommendation.
• Vendor data never moves a confidence band: vendor classes are not law-bearing and carry no verification status, and a regression test asserts that bands and hop scoring are identical with and without the market layer present.
• Where a listed product's scope overlaps this platform's own, that overlap is disclosed on the entry — and the panel states once that RAIN operates in this category too and does not rank its competitors.

This is not legal advice

The reasoner is deterministic and reproducible — the same inputs and the same graph version always produce the same conclusion, byte for byte — but determinism is not correctness. A defensible starting position still needs a qualified reviewer before anyone acts on it, which is exactly what the confidence bands (chapter 4) are built to flag.

Coverage boundaries

• Verification currency: of 184 law-bearing nodes, 128 (70%) carry a verified status as of the latest recorded check — the rest are on record without a recent re-check.
• Jurisdiction depth is uneven by design: entries marked "thin coverage" in the registry (chapter 3) are known gaps, not silent ones.
• Vendor and stack examples are a structured, disputable compilation, never nodes with obligations of their own: "Community-maintained, disputable examples — not an endorsement and not a ranking. Alignments are as claimed by vendors or the source compilation, not verified by RAIN; a certification is shown as a certification only where a certificate or registry reference is recorded."
• Practice-derived claims (an artifact or a scenario the text does not name, but a documented practice supplies) are marked as such everywhere they surface, and carry a lower confidence factor for it.

What the validation suite does and does not prove

It proves: the reasoner's behaviour matches a set of authored expectations for the scenarios in the golden suite, including adversarial and degenerate inputs, and a bounded set of injected faults is caught by that suite (chapter 8's mutation report).

It does not prove: that every legal claim in the graph is correct today, that the graph's coverage is complete for any jurisdiction, or that a conclusion is a substitute for professional advice. A passing suite is a statement about the derivation logic, never about the underlying law.