bluegreencity-ki

Architecture Decision Records (ADRs)

This directory contains records of architectural decisions made in the BlueGreenCity-KI project.

What is an ADR?

An Architecture Decision Record (ADR) is a document that captures an important architectural decision made along with its context and consequences.

When to Write an ADR

Write an ADR when making significant decisions about:

System architecture and design patterns
Technology choices (libraries, frameworks, databases)
Data models and formats
API designs
Performance optimizations
Security approaches

ADR Format

Each ADR should follow this structure:

# ADR-NNN: Brief Title

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

## Context
What is the issue we're trying to solve?
What are the constraints and requirements?

## Decision
What did we decide to do?
Be specific and concrete.

## Consequences
What becomes easier or more difficult?
Positive and negative outcomes.

## Alternatives Considered
What other options did we evaluate and why were they rejected?

Naming Convention

ADR files should be named: ADR-NNN-brief-title.md

Example: ADR-001-vector-first-architecture.md

Historical note: adr-2026-07-gui-technologie.md predates this convention (no number, lowercase prefix) and has kept its file name for reference stability.

Current ADRs

ADR-001: Vector-First Architecture
GUI-Technologie (2026-07): Taipy als Entscheidungs-GUI — unnumbered, see naming note; the Taipy decision matches the delivered irrigation_review app
ADR-002: Spatial Database Technology Evaluation — evaluation record; not implemented (PostGIS remains the sole database)
ADR-000: Template - Copy this for new ADRs