Architecture Decision Records (ADRs) for Zammad-AI

We document all fundamental architectural decisions for our projects as ADRs. If you don't know if you should create an ADR, the answer is probably "yes".

ADR List

• ADR 01: System Architecture
• ADR 02: Two-way processing of tickets
• ADR 03: Vector Database Selection
• ADR 04: Knowledge Management System Selection
• ADR 05: Knowledge Base Indexing Strategy
• ADR 06: Multi-Usecase System Architecture

Background

Background information on ADRs:

• GitHub
• Heise

Template

We essentially follow MADR, but add a status field.

# ADR XX: < short description of the decision >

| Status      | proposed | < accepted | rejected | deprecated | superseded by ADR <n> >
| ----------- | -------- |
| Author      | < initials > |
| Voters      | - |
| Drafted     | < date > |
| Timeline    | tbd |

<!-- optionally reference related ADRs -->

## Context and Problem Statement

< explain the context of the decision >

The following criteria are relevant for the decision:

- < criterion a >
- < criterion b >
- < criterion c >

## Considered Options

- x
- y
- z

## Evaluation

### x

- **Criterion a**: < evaluation >
- **Criterion b**: < evaluation >
- **Criterion c**: < evaluation >

< repeat for other options >

## Overview

| Criterion   | Option x | Option y | Option z |
| ----------- | -------- | -------- | -------- |
| Criterion a | ++       | +        | --       |
| Criterion b | -        | ++       | +        |
| Criterion c | +        | +?       | +        |

## Decision Made

< state and justify the decision >