KI Project Organization Back to start
🇩🇪 🇬🇧

Technical architecture

Repository, control artifacts, and evidence structure

The architecture of this project is less a classic product architecture and more a combination of work architecture, knowledge architecture, and evidence structure. It creates the conditions that allow AI-enabled development to remain not only productive, but later also verifiable and auditable.

System view

Three layers that jointly support control and traceability

1. Control layer

Jira manages status, roles, sequencing, history, approvals, and active work.

2. Knowledge layer

Rules, requirements, test strategy, review process, and open points preserve the project logic over time.

3. Artifact layer

Code, HTML documentation, handover files, and DOC, DEV, and QA results provide the concrete outputs.

Repository

How the file structure supports the organization

Sources/             technical artifacts and sample code
Tests/               Platzhalter für automatisierte Prüfungen
docs/                HTML and Markdown documentation
project-control/     Anforderungen, Teststrategie, Reviews, offene Punkte, Resultate
project-rules/       binding role and process rules

Why this separation matters

  • control knowledge remains separate from product code
  • Documentation can grow without overloading the project core
  • Resultate und Handover-Dateien bleiben als auditierbare Artefakte greifbar

Technische Einstiegspunkte

  • Package.swift als technischer Startpunkt
  • Sources/HelloWorldCLI/main.swift als minimales lauffähiges Beispiel
  • docs/project-documentation.html als redaktioneller Starteinstieg

Betriebsarchitektur

How the project remains stable, readable, and auditable in daily work

Stability here does not come from large technical platforms, but from small, clearly defined control points: Jira status, role separation, linked artifact paths, and visible open points. This combination prevents knowledge from existing only in volatile chat histories or implicit assumptions.

Especially important is the rule that central project files are updated only on an approved basis. This prevents unconfirmed review opinions or preliminary technical ideas from flowing unchecked into the permanent project baseline. For safety-adjacent, critical, or later certified systems, this separation between working state and approved baseline is essential.

Lifecycle

Which lifecycle cases the architecture accounts for

Rule update

A change in `project-rules/` leads to rollout tickets, read-back confirmations, and, where needed, follow-up adjustments in documentation artifacts.

Review-Rückkopplung

Findings from DEV, QA, PM, or executive reviews are translated into manageable improvement tickets and then incorporated into artifacts in a targeted way.

Onboarding new roles

New contributors can get started via `README`, role rules, the documentation set, and the appropriate Jira work list.

Architekturgrenzen

What this architecture deliberately does not claim yet

Not yet fully defined

  • binding technical conventions for later implementation work
  • eine feingranulare Produktarchitektur jenseits der Projektorganisationsbasis
  • eine abgeschlossene mehrstufige Release- oder Deployment-Architektur

Why this restraint matters

  • it prevents speculative documentation
  • sie hält die Projektgrundlage ehrlich und anschlussfähig
  • it makes visible which decisions still need to be made later