Architecture & Security Model
azuma nori is engineered around a core principle: Absolute Data Sovereignty. We understand that providing source code to third-party servers is often a non-starter for enterprise compliance audits. To solve this, nori utilizes a localized, multi-agent architecture.
Zero-Code-Upload Security Model
When you run an analysis, your proprietary source code is never uploaded to an Azuma server.
Instead of uploading files to a central Azuma server for parsing, the Standalone Client acts as a local orchestrator. It dispatches API calls directly to your configured Large Language Model (LLM) provider (like Anthropic, OpenAI, or a private on-premise endpoint) using your own API keys. The LLM provider processes the data ephemerally, and the parsed results are returned directly to your local .nori directory.
Where the code snippets are evaluated depends on the model you choose: a cloud LLM sees them under your own account and API key (never through Azuma), while a local or on-premise model keeps them entirely within your own infrastructure.
The Azuma backend receives strictly filtered telemetry (scores, metrics, and completion statuses), but it never ingests or proxies your source files.
The Two-Phase Pipeline
To efficiently evaluate a codebase without exceeding LLM context windows or incurring massive token costs, nori splits the process into two phases:
1. The Indexing Phase (Wiki Builder)
Before evaluating compliance rules, nori runs a "Wiki Builder" phase. This phase scans your directory and builds highly compressed, localized Markdown indices summarizing your architecture, dependencies, and file structures.
Performance Note: Nori applies a context-compression pass during this phase, using heuristics that can compress prose-heavy documentation by up to 60%, drastically reducing the token payload sent in the next phase.
2. The Evaluation Phase (Run Analysis)
Once the Wiki is built, the orchestrator begins evaluating the actual compliance policy (e.g., BSI TR-03161).
Rather than asking a single LLM to evaluate the entire standard, the orchestrator splits the work across multiple bounded sub-agents, each responsible for evaluating a specific subset of the policy's controls. These sub-agents are injected with the local Wiki context, allowing them to search for evidence precisely where it matters.
Analysis-Only Mode
The two-phase pipeline described above is the default project mode (Discovery & Analysis). For teams who want faster, lighter runs — or whose codebase is small enough to evaluate directly — nori also offers an Analysis-Only mode.
In Analysis-Only mode, nori skips the Indexing Phase entirely: no source-code wikis are built. The orchestrator's evaluation sub-agents run the same bounded, per-control split, but they search the repository directly on demand instead of reading from a pre-built Wiki index.
This trades the up-front indexing pass (and its one-time token cost) for evaluation that reads the source live. It suits smaller repositories, quick re-checks, and situations where you don't want to build or maintain a wiki index. The source-code-wiki UI is hidden for these projects; however, any per-document evidence you supply — the "Wiki (Files)" document index built from uploaded specifications and design documents — is still indexed and injected into the evaluators, so that context continues to inform the analysis.
The Zero-Code-Upload guarantees are identical in both modes: whether or not a wiki is built, your source is only ever seen by your own configured LLM provider, and the Azuma backend still receives filtered telemetry only.
Final Summarization
After all sub-agents finish evaluating their assigned controls, their findings are passed to a final summarization step.
This step has one job: aggregate the raw JSON output from the sub-agents into human-readable executive summaries. Crucially, it operates under a strict directive guaranteeing that it must never drop, mask, or summarize away any Critical Failures or Warnings found by the sub-agents. This ensures absolute audit fidelity.