The DMZ: Archive Gate — Project Soul

# The DMZ: Archive Gate — Project Soul

## Identity

The DMZ: Archive Gate is a cybersecurity awareness training platform built as a post-apocalyptic data center management game. Developed by Matrices GmbH. Positioned as "Duolingo for Cybersecurity."

**Premise:** A Stuxnet variant (NIDHOGG) crashed the public internet. Players operate the last functioning data center — deciding who gets access, defending against attackers, and upgrading infrastructure. Through gameplay, they acquire real cybersecurity skills without realizing they're being trained.

**Markets:** B2B enterprise (per-seat licensing, 14+ regulatory frameworks) + B2C consumer (free-to-play). One game engine serves both.

## Tech Stack

| Layer | Technology |
|-------|-----------|
| Frontend | SvelteKit 2.x, Svelte 5, TypeScript, PixiJS |
| Backend | Node.js, TypeScript, Fastify 5.x (modular monolith) |
| Database | PostgreSQL (RLS multi-tenancy), Redis |
| Analytics DB | PostgreSQL initially; ClickHouse or TimescaleDB when needed |
| AI | Claude API (phishing content generation) |
| ORM | Drizzle ORM (versioned migrations) |
| Validation | Zod → JSON Schema (Fastify) |
| Build orchestration | Turborepo (pipeline caching, task graph) |
| Package manager | pnpm 9.x (monorepo workspaces) |
| Linting | ESLint 9.x (flat config), Prettier |
| Testing | Vitest (unit), Playwright (E2E) |
| CI/CD | GitHub Actions |
| Infrastructure | Docker, Kubernetes |

## Architecture Principles

1. **Event sourcing from day one** — game engine and event store are inseparable.
2. **tenant_id on every table from day one** — even before multi-tenancy is enforced.
3. **Accessibility is structural** — WCAG 2.1 AA is a legal requirement at launch.
4. **Privacy by design** — pseudonymization and data minimization from the first event.
5. **Modular monolith first** — no premature microservice extraction. Clear module boundaries.
6. **PostgreSQL first for analytics** — defer ClickHouse/TimescaleDB to M7.
7. **Consumer game validates, enterprise game monetizes** — the game must be fun before it can be sold.

## Coding Standards

- TypeScript strict mode everywhere. No `any` without explicit justification.
- Svelte 5 runes (`$state`, `$derived`, `$effect`). No legacy reactive syntax.
- Named exports over default exports.
- Server-authoritative game state. Client mirrors, never owns.
- All API endpoints validated with Zod. All responses typed.
- Structured logging with Pino. Redact PII fields.
- Error codes registry — every error gets a unique code.
- Frontend and shared tests colocated: `thing.ts` → `thing.test.ts`.
- Backend module tests in `__tests__/` subdirectories: `module/__tests__/thing.test.ts`.

## Security Principles

- OWASP Top 10 awareness in all code.
- No secrets in code or commits. Environment variables only.
- CSP headers, Trusted Types, anti-clickjacking.
- Input validation at every system boundary.
- Rate limiting on all public endpoints.
- AI content safety: no real companies, people, URLs, or PII in generated content.

## Tone

All engineering artifacts (commits, PRs, code comments, docs) are strictly professional. The post-apocalyptic theme stays in game code and content only.

## Key Documents

| Document | Path | Lines |
|----------|------|-------|
| Game premise | `docs/story.md` | 59 |
| Business Requirements | `docs/BRD.md` | 1,363 |
| Development Roadmap | `docs/MILESTONES.md` | 565 |
| 14 Design Documents | `docs/DD/` | ~24,500 |
| 14 BRD Research Files | `docs/BRD/` | ~22,200 |

### Design Document Index

| DD | System |
|----|--------|
| 01 | Game core loop and state machine |
| 02 | Email and document system |
| 03 | AI content pipeline |
| 04 | Facility and resource simulation |
| 05 | Threat engine and breach mechanics |
| 06 | Narrative and season architecture |
| 07 | UI/UX and terminal aesthetic |
| 08 | Frontend architecture (SvelteKit) |
| 09 | Backend architecture and API |
| 10 | Database schema and data model |
| 11 | Enterprise multi-tenancy and admin |
| 12 | Analytics and learning assessment |
| 13 | Multiplayer and social systems |
| 14 | Integration and infrastructure |