Architecture

Authoritative reference: docs/platform/architecture. This handbook page summarises the system from a developer's vantage point.

Bounded contexts

Noxys is decomposed into bounded contexts, each owned by a repo:

Context	Owner repo	Responsibility
Detection	noxys-extension	In-browser Tier 1 Risk Signal detection (MV3 service worker)
Backend detection	noxys-api	Tier 2 (Presidio) + Tier 3 (async SLM) detection
Policy	noxys-api	Policy evaluation, action enforcement, default-deny logic
Catalog	noxys-api + noxys-console	AI service catalog (sanctioned / under review / blocked)
Console	noxys-console	Admin SaaS — IAM, policies, alerts, audit, reporting
Customer documentation	noxys-doc	doc.noxys.cloud (this site)
Marketing	noxys-website	noxys.eu marketing + ADR registry
Infrastructure	noxys-infra	Terraform + Ansible for VPS / staging / production

Data flow (happy path)

[Browser]                            [Backend]                       [Storage]
                  prompt
+-----------+   ────────────► +------------------+   metadata    +-----------+
| extension |─Tier 1 detect─►| FastAPI / Node   |─────────────► | Postgres  |
| MV3 sw    |◄ allow/coach ──| policy engine    |   redacted    | (RGPD-    |
+-----------+   /block       +------------------+   prompt      |  scoped)  |
                                       │                          +-----------+
                                       │ events
                                       ▼
                                  [Console]
                                  alerts UI

Key invariants:

1. The extension does not send raw prompts to the backend by default — only redacted text + structured metadata.
2. The backend never stores raw prompts unless the tenant has opted-in (per-tenant KMS).
3. Policy evaluation is deterministic — given the same inputs, the same decision must result. No flaky model calls in the critical path.

Three deployment methods (hard-scoped)

We support exactly three deployment methods. Proposals for a fourth must be rejected unless they fold into one of these.

1. Browser extension — primary method, Chrome/Edge/Firefox via MV3.
2. Endpoint agent — for sanctioned-only enterprise environments where extensions are not deployable.
3. Network proxy — for SaaS-only enterprises that intercept egress at the perimeter.

See ADR-008 (deployment methods).

Detection tiers

Tier	Where	Tech	Latency target
Tier 1	Extension service worker	Regex + JS pattern matching	<10ms
Tier 2	Backend, sync	Presidio + custom recognizers	<100ms
Tier 3	Backend, async	Self-hosted SLM (LLM-as-judge)	<2s

Tier 1 detections gate the user-facing coaching flow; Tier 2 produces the persistent audit record; Tier 3 produces high-confidence labels for trend reporting and triage.

Storage classes (prompt persistence)

Per the pricing tiers memo and transparency report, prompts can be stored in 4 classes:

Class	Description	Default for
aggregate	Counts only, never the prompt	Free
hashed	SHA-256 of prompt + signal category	Free
redacted	Prompt with Risk Signals replaced by tokens	Pro / Ent
raw	Full original prompt, KMS-encrypted	Ent on request, opt-in only

Cross-cutting

• Authentication: OIDC (Microsoft Entra ID, Google Workspace) via SSO.
• Authorization: role-based (Admin / Viewer) — see console docs.
• Audit: every admin action emits an audit event (24-month retention per ADR-013).
• Telemetry: Sentry for errors; OpenTelemetry for tracing — no PII in spans.
• i18n: EN canonical, FR sibling files for customer-facing docs (-fr.md suffix).

Diagrams

Authoritative diagrams live in noxys-website/docs/architecture/. This page intentionally does not duplicate them — it links to them so they have one canonical version.

• High-level system diagram → noxys-website/docs/architecture/system-overview.md
• Detection pipeline → noxys-website/docs/architecture/detection-pipeline.md
• Data flow + storage → noxys-website/docs/architecture/data-flow.md