ARCH

Context

Vi trenger en compute-plattform for Arch Audit som integrerer native med D1 (SQLite), R2 (Object Storage), AI Gateway (tokens/cost/latency), Workers AI, og Cloudflare Pages for static hosting. Alle må være på samme edge-nettverk for ultra-lav latency og null egress fees.

Decision

Cloudflare Workers som primær compute. Cloudflare Pages for static frontend. Cloudflare D1 for relational data. Cloudflare R2 for evidence storage. Cloudflare AI Gateway for AI observability.

Alternatives Considered

• Vercel + Neon/PlanetScale + S3: Ingen native D1/R2/AI Gateway binding. Cold starts på Neon. Egress fees på S3. Fragmentert observability.
• Fly.io + PostgreSQL + Tigris: God edge, men ingen native D1/R2/AI Gateway. Må bygge observability selv. Dyrere for vårt use case.
• AWS Lambda@Edge + DynamoDB + S3: Meget dyrt. Kompleks cold start management. Ingen native AI Gateway. Vendor lock-in.

Consequences

• ✅ Enkel stack, én vendor, native integrasjoner
• ✅ Null egress fees (R2)
• ✅ Native AI observability (AI Gateway)
• ⚠️ Mindre mature ecosystem enn AWS/Vercel
• ⚠️ D1 har SQLite-limitter (store JOINs, ingen native RLS)
• ⚠️ Workers AI modellkatalog mindre enn Bedrock/Vertex

Context

Opprinnelig design antog PostgreSQL-style RLS i Cloudflare D1: `CREATE POLICY ... USING (tenant_id = current_setting('app.current_tenant_id'))`. CTO-gjennomgang avdekket at D1 bruker SQLite-semantikk og støtter IKKE `current_setting()` eller native Row Level Security policies.

Decision

Tenant-isolasjon håndheves i application-laget (Worker middleware):

1. Alle tabeller har `tenant_id` som FK
2. Middleware validerer auth → resolver `tenant_id` fra membership
3. Alle data-access funksjoner krever eksplisitt `tenant_id` i spørringer
4. `tenant_id` aldri fra klient — kun fra server-side membership resolution
5. Obligatoriske cross-tenant attack tests (18/18 grønne)

Alternatives Considered

• Database-per-tenant: Cloudflare støtter mange D1-databaser, men schema-migrasjoner, backup, observability, og kostnadskontroll blir komplekst ved 100+ tenanter.
• Vente på D1 RLS: Ingen timeline. Blokerer produktutvikling.

Consequences

• ✅ Fungerer i dag med D1s nåværende kapasiteter
• ✅ Full kontroll og testbarhet (vi eier koden)
• ✅ Cross-tenant tests er eksplisitte og reproducerbare
• ⚠️ Mer boilerplate i data-access lag (men genererbar)
• ⚠️ Må være disiplinerte: ALLE spørringer må ha tenant_id

Context

ROI-beregning er kjerneverdi i Arch Audit. Kunder tror på tall. Hvis en LLM hallusinerer en besparelse på 487 231 kr, mister vi all trovverdighet. Deterministisk matematikk er 100% testbar, sporbar, og forklarbar.

Decision

ROI-engine = pure functions (TypeScript). Ingen LLM i beregningslogikken. Input variabler klassifiseres: MEASURED / CUSTOMER_PROVIDED / DERIVED / BENCHMARK / ASSUMED. Scenarier: LOW / EXPECTED / HIGH. Sensitivitetanalyse per variabel.

Alternatives Considered

• LLM som regner ut ROI: Hallusinerer tall. Ikke deterministisk. Ikke testbar. Ikke auditbar.
• Spreadsheet (Excel/Google Sheets): Ingen versjonering, ingen audit trail, ingen API, manuelle feil.

Consequences

• ✅ 100% unit test coverage mulig
• ✅ Hver krone sporbart til input
• ✅ Scenarier gir transparens (LOW/EXPECTED/HIGH)
• ⚠️ Krever at input klassifiseres riktig (feature, ikke bug)
• ⚠️ Mer kode å vedlikeholde enn "spør LLM"

Context

Mange AI-plattformer bruker "swarm of agents" der agenter prater fritt med hverandre. For Arch Audit (høy risiko, krav på auditability, compliance, human-in-the-loop) gir ubegrenset agent-til-agent kommunikasjon: uforutsigbar state, vanskelig policy enforcement, umulig audit trail, hallusinasjoner propagerer.

Decision

Hermes (Chief Architect) er single source of truth for audit state. 6 spesialiserte agenter mottar oppgaver fra Hermes, returnerer resultater til Hermes. Ingen direkte agent-til-agent kommunikasjon. Policy engine (OPA) evaluerer alle handlinger. Human gates for HIGH/CRITICAL risiko.

Alternatives Considered

• LangGraph / AutoGen / CrewAI: For høyt nivå, ingen governance, Python-only, ingen native Cloudflare Workers support.
• Full A2A/MCP mellom agenter: Skaleres dårlig for governance. Vi implementerer MCP kun ved reelt behov for eksternt interop.

Consequences

• ✅ Full auditability: hvem bestemte hva, hvorfor, med hvilken evidens
• ✅ Policy enforcement i én sentral plass (Hermes + OPA)
• ✅ Deterministisk state machine
• ⚠️ Mer orchestration-kode å skrive
• ⚠️ Begrenser "emergent behavior" (som vi ikke vil ha)

Context

Vi trenger policy-as-code med runtime enforcement i Cloudflare Workers, CI/CD testing, og audit trail. To hovedkandidater: OPA/Rego (mature, Kubernetes-standard) og Cedar (AWS Verified Permissions, entity-based).

Decision

OPA/Rego. Grunner:

1. Mature ecosystem: Kubernetes, Terraform, Envoy bruker det
2. `opa test` innebygd — game-changer for CI/CD gates
3. Rego håndterer komplekse nested JSON naturlig (audit input er komplekst)
4. WASM kompilerer fint i Cloudflare Workers (`opa-wasm`)
5. Teamet kjenner Rego fra andre prosjekter
6. TypeScript support via `rego.ts` / `opa-wasm`

Alternatives Considered

• Cedar: Meget lovende (Rust core, entity-based, native decision logging), men mindre mature tooling, mindre CI/CD eksempler, mindre community eksempler for vårt use case.

  Consequences

  • ✅ `opa test` i CI/CD — policy regressjoner fanges før deploy
  • ✅ WASM i Workers — lav latency runtime eval
  • ✅ Audit trail: alle decisions logges immutable i D1
  • ⚠️ Rego lærekurve (men teamet kjenner det)
  • ⚠️ Bundle size (men < 100KB gzipped)