Architecture Decision Records (ADRs)¶
This directory contains Architecture Decision Records (ADRs) for the FireBreak platform. ADRs document significant architectural decisions, their context, and rationale.
What is an ADR?¶
An Architecture Decision Record (ADR) is a document that captures an important architectural decision along with its context and consequences. They help teams:
- Understand why decisions were made
- Avoid repeating past discussions
- Onboard new team members
- Review and evolve the architecture
ADR Format¶
Each ADR follows this structure:
- Title: Clear, descriptive name
- Status: Proposed, Accepted, Deprecated, Superseded
- Context: What is the issue we're addressing?
- Decision: What have we decided to do?
- Consequences: What are the implications?
- Alternatives Considered: What else did we consider?
FireBreak ADRs¶
Platform & Infrastructure¶
-
ADR-001: Cloudflare Workers Platform
Decision to build on Cloudflare Workers instead of traditional servers
Status: ✅ Accepted
-
ADR-004: Cloudflare Services Integration
Using Cloudflare Images, Stream, R2, D1, and KV for media and storage
Status: ✅ Accepted
Data & Processing¶
-
ADR-003: Multi-Model Consensus
Using multiple AI models (Claude, Gemini, GPT-4) for consensus-based analysis
Status: ✅ Accepted
-
Structured rubric codes for wildfire risk assessment
Status: ✅ Accepted
-
Offline-first architecture with local caching and sync
Status: ✅ Accepted
Technology Stack¶
-
ADR-006: Python/JavaScript Interop
Python backend with JavaScript frontend communication patterns
Status: ✅ Accepted
-
Single repository for backend, frontend, and infrastructure
Status: ✅ Accepted
Multi-Tenancy¶
-
ADR-005: Multi-Tenant Architecture
Complete tenant isolation strategy
Status: ✅ Accepted
-
ADR-008: Tenant Isolation Strategy
Implementation details for tenant data and resource isolation
Status: ✅ Accepted
-
ADR-009: White-Label Frontend Strategy
Per-tenant branding and customization
Status: ✅ Accepted
Development & Operations¶
-
ADR-009: QA Harness & Testing Strategy
Unified testing framework for backend, frontend, and E2E tests
Status: ✅ Accepted
-
ADR-010: Frontend/Backend Separation
Complete separation of concerns between frontend and backend
Status: ✅ Accepted
ADR Index¶
| Number | Title | Status | Date | Updated |
|---|---|---|---|---|
| 001 | Cloudflare Workers Platform | ✅ Accepted | 2024-10 | 2024-11 |
| 002 | Cloudflare Services Integration | ✅ Accepted | 2024-10 | 2024-11 |
| 003 | Multi-Model AI Consensus | ✅ Accepted | 2024-10 | 2024-11 |
| 004 | Rubric-Based Risk Assessment | ✅ Accepted | 2024-10 | 2024-11 |
| 005 | Offline-First Architecture | ✅ Accepted | 2024-10 | 2024-11 |
| 006 | Python/JavaScript Interop | ✅ Accepted | 2024-10 | 2024-11 |
| 007 | Monorepo Strategy | ✅ Accepted | 2024-11 | 2024-11 |
| 008 | Tenant Isolation Strategy | ✅ Accepted | 2024-11 | 2024-11 |
| 009a | QA Harness & Testing | ✅ Accepted | 2024-11 | 2024-11 |
| 009b | White-Label Frontend | ✅ Accepted | 2024-11 | 2024-11 |
| 010 | Frontend/Backend Separation | ✅ Accepted | 2024-11 | 2024-11 |
Creating a New ADR¶
To create a new ADR:
- Copy the ADR template
- Number it sequentially (ADR-011, etc.)
- Fill out all sections
- Submit for review
- Update this index
ADR Template¶
# ADR-XXX: Title of Decision
**Status**: Proposed | Accepted | Deprecated | Superseded
**Date**: YYYY-MM-DD
**Stakeholders**: List of involved parties
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
### Positive Consequences
- Benefit 1
- Benefit 2
### Negative Consequences
- Tradeoff 1
- Tradeoff 2
## Alternatives Considered
What other approaches did we consider?
### Alternative 1: Name
- Description
- Pros
- Cons
- Why rejected
## References
- Links to related documents
- External resources
- Related ADRs
ADR Lifecycle¶
graph LR
A[Proposed] --> B[Under Review]
B --> C[Accepted]
B --> D[Rejected]
C --> E[Deprecated]
C --> F[Superseded] - Proposed: New ADR drafted
- Under Review: Team is discussing
- Accepted: Decision approved and implemented
- Deprecated: No longer recommended but not replaced
- Superseded: Replaced by a newer ADR
Questions?¶
For questions about ADRs or to propose a new decision, open an issue or contact the architecture team.