Model / System Card – nori
This translation is NOT legally binding and a working translation only. Legally binding and relevant, particularly in case of any discrepancies, is solely the German text.
Version date: 17 August 2026 · Status: Approved
Note on adaptation: nori does not train a model of its own. This card describes the system nori and the foundation models it uses. Statements about the training data of the foundation models are the responsibility of their respective providers, via their respective model cards (see section 4).
1. Overview
| Field | Details |
|---|---|
| Name | nori |
| Provider | azuma healthtech GmbH |
| Purpose | AI-supported analysis of source code against regulatory/security frameworks (e.g. BSI TR-03161, EU CRA, OWASP ASVS). |
| System type | Orchestration/agent pipeline on top of general-purpose foundation LLMs; no model trained in-house. |
| Input/output | Input: source code + optional evidence documents. Output: textual findings (JSON/Markdown), wikis, reports, summaries. |
| Modality | Text/structured data exclusively (no audio/image/video generation). |
| Users | Development, compliance and audit teams. |
2. Architecture
- CLI (
Azuma.Nori.Cli) – orchestrates agents, calls the LLM provider, writes results to.nori/. - REST API (
Azuma.Nori.Api) – policy/control metadata, findings queries, auth. - Admin dashboard (React,
Azuma.Nori.Frontends.Admin) – overview, annotation/feedback. - Agents: wiki builder (knowledge extraction), control evaluator (assessment against control criteria), doc summarizer (evidence documents), summarize/supervisor (summaries).
- Provider abstraction:
LlmProviderFactory/ExecutorConfig(model selection, endpoint, budget caps per phase).
3. Intended use / uses not intended
Intended: supporting, preparatory compliance analysis followed by human review of the findings.
Not intended:
- automated approval/authorization decisions without human oversight,
- decisions about natural persons / profiling,
- use as a safety component of a regulated product.
4. Foundation models used
nori is configurable in a provider-agnostic way. Supported are, among others:
| Provider | Integration | Own model card |
|---|---|---|
| Anthropic (Claude) | Claude Code CLI / API | Provider's model card (external) |
| Google (Gemini) | Gemini CLI / GenAI SDK | Provider's model card (external) |
| OpenAI / Azure OpenAI | OpenAI SDK | Provider's model card (external) |
| Local models (Ollama, vLLM, …) | OpenAI-compatible endpoints | per model |
The model actually used for each run is recorded in run.json (field model).
5. Performance characteristics
Semantic quality is measured via the nori-regression pipeline:
- Metrics: precision, recall, verdict accuracy per control.
- Method: run against a pinned fixture repository, scoring against committed ground truth (
agents/ground_truth/), diff against a committed baseline with a tolerance threshold and human adjudication. - Character: a manually triggered, semantic quality gate (does not block CI); complemented by deterministic integrity tests.
6. Limitations and risks
- LLM inference is not deterministic; findings may contain false positives/negatives – human review is required.
- Quality depends on the chosen foundation model and on the context provided (wikis, control definitions).
- Results are tied to the commit that was analysed (
gitCommitinrun.json).
7. Governance / traceability
- Provenance per run in
run.json(model, git commit/branch, timestamp, score, tokens/cost). - Findings with file/line references.
- Human oversight and feedback loop in the dashboard.