Architecture decisions

Architecture decision records (ADRs) explain why the maintainers designed Konfidence the way it is. Read them before you change a component, so you know which trade-offs it already makes. Each record covers one decision: its context, the options the maintainers compared, and the consequences.

Every record has a status

Status	Meaning
draft	The author is still writing the record.
proposed	The record is ready for review by the maintainers.
accepted	The maintainers approved the decision. The code follows it.
rejected	The maintainers considered the decision and did not adopt it.
deprecated	A later decision replaced this one. The record stays to explain how the current design came about.

ADR numbers never change and never get reused. Gaps in the list are records that are superseded, internal to the project, or still lack a decision.

Decision log

ADR	Title	Status	Category
ADR-0002	High-level architecture	accepted	Architecture Pattern
ADR-0005	Gateway API integration	accepted	Technology Stack
ADR-0006	OCM integration	draft	Technology Stack
ADR-0007	Multi-landscape support and namespace separation	proposed	Architecture Pattern
ADR-0008	Task engine	accepted	Architecture Pattern
ADR-0009	StageVersion custom resources	proposed	Architecture Pattern
ADR-0012	Activation controller	proposed	Deployment
ADR-0013	StageVersionUsage during vector rollout	accepted	Architecture Pattern
ADR-0019	OCM in vector assembly	draft	Architecture Pattern
ADR-0022	Star and galaxy terminology for control planes	accepted	Project Management
ADR-0023	Monorepo with separate binaries	proposed
ADR-0024	Vector-scoped data distribution	draft	Architecture Pattern
ADR-0025	Release on demand via manual tags	accepted	Deployment
ADR-0026	Merge galaxy and star into a single cluster	accepted	Architecture Pattern
ADR-0027	Landscape and deployment target concept	accepted	Architecture
ADR-0028	Project CRD and multi-tenancy authorization	accepted	Security
ADR-0029	API gateway conventions and design	accepted	Architecture Pattern
ADR-0030	API authentication flows	accepted	Security
ADR-0031	API principles	accepted	Architecture Pattern
ADR-0032	Vector promotions	accepted	Architecture Pattern
ADR-0033	Dependabot for code dependency updates	accepted	Technology Stack
ADR-0034	ArtifactDeployment and Flux resource naming	accepted	Architecture Pattern
ADR-0035	Dashboard technology stack	accepted	Architecture Pattern
ADR-0036	Dashboard UI component and CSS library	accepted	Architecture Pattern
ADR-0037	Ingress routing and activation	accepted	Architecture Pattern
ADR-0038	Select deployers by artifact type instead of DeploymentClass	approved	Architecture Pattern

Propose a new decision

Write an ADR when a change spans several components or is expensive to reverse. Write one too when it sets a pattern other contributors must follow. ADRs live in the konfidence-docs repository. Propose a record as a pull request there.

1. Take the next free number after the highest ADR in the decision log.

2. Create adr-<NNNN>-<slug>.md in src/docs/extend-customize/decisions/.

3. Start the file with this frontmatter, the heading, and the <AdrHeader /> component:

   ---
   id: ADR-<NNNN>
   title: "<Short title>"
   description: "<One sentence: what the record decides>"
   status: proposed
   date_proposed: <YYYY-MM-DD>
   authors: [<github-handle>]
   category: <Architecture Pattern | Technology Stack | Security | Deployment>
   impact: <High | Medium | Low>
   dependencies: [<ADR-NNNN>]
   pageClass: adr
   outline: deep
   ---
   
   # ADR-<NNNN>: <Short title>
   
   <AdrHeader />

4. Write the sections Context, Considered options, Decision and Consequences.

5. Put diagrams into assets/ and reference them as ./assets/<file>.

6. Open the pull request with status proposed.

The maintainers review the record in the pull request. On merge, they set status: accepted and date_approved. The sidebar and the decision log pick up the new file automatically.

List authors by GitHub handle only. Records never name people, internal systems, or private repositories.