Architecture decisions
Important technical choices are recorded as an architecture decision record, a short document per decision. There are currently thirty-nine; one of them has since been replaced by a later decision.
The template
Every decision follows the same structure:
- Context: what was the problem, and why now?
- Decision: what was chosen?
- Alternatives: what was considered and why was it dropped?
- Drawbacks: what does this choice cost us?
- When to reconsider: which circumstance makes this decision obsolete?
Points 3 to 5 are the most valuable. A decision without written-down drawbacks is usually not a decision but a preference, and without a review criterion a choice lingers long after the reason for it has gone.
A decision only counts as established when there is working evidence, not when the document is finished.
Decisions that shape the platform
| Subject | Core of the decision |
|---|---|
| Configurable prompts | Prompts live in configuration, with a variant per tenant, not in code |
| AI gateway | All generation goes through a single server-side entry point, with prompt resolution, model choice and monitoring |
| Search foundation | Rebuild of evidence retrieval: chunking, a semantic index and a bounded selection |
| Evidence chain | References are checked server-side against what the model actually received |
| Grounded synthesis | The heavy analyses also receive dossier evidence, not just simple extractions |
| Tenant model | Data model and permissions matrix for multiple organisations on one platform |
| Latency and time-outs | Streaming, background tasks and model choice per task weight |
| Reporting engine | Block-based document model, strictly additive to existing worksheets |
| Capability model | The connecting layer between strategy and change portfolio |
| Release pipeline | Staging first, with automated gates for migrations and schema parity |
| Test strategy | Which test covers which risk, and when a test becomes mandatory |
| Security gate | Audit log, backups and a demonstrably tested recovery procedure |
| Evidence on the row | The evidence behind a generated text is stored with the text itself, not in a separate log |
| Provenance model | Every AI generation carries its provenance: source, nature, sources, reasoning step and whether a human has written on it; the server decides whether material existed, not the model |
| Anonymous surface | Anyone who is not logged in reads nothing, except what has been explicitly and justifiably released |
| Report model | Four documents per worksheet (view, summary, findings and One-pager), where the summary does not draw on the findings and a report is a snapshot |
| Provenance on acceptance | The provenance mark disappears as soon as a human accepts the proposal; generating from general knowledge is allowed everywhere |
| Risk model | The consultant's approval button is the control; heavy safeguards belong only at the boundary to the customer |
| Time rules for generations | An aborted generation counts as failed, no second full attempt follows, and the ceiling follows from the time band |
| Processes and organisation | Chain, process and action each have one meaning; a process has a department as its owner, KPIs have a single form, and an issue concerns a process, a hand-over or a chain |
| Collaboration model | Participants per canvas with a role, one account in several organisations, and hand-over from consultancy to client in one guarded step; an organisation's administrator manages who may join and does not read along by default |
| Build chain | The web application is built and developed with Vite (version 7), with a pinned build environment and a test suite without a heavy build layer on top |
| Value teams | A value team carries out roadmap tasks and can work across several chains, with an explicit agreement per initiative |
| Second factor | Signing in with an authenticator app: switched on per organisation for administrators, and enforceable for all users |
| Staging topology | A separate test environment with its own database and its own address, alongside production |
| AI models per week | A new model goes on the list, is compared on a test set and replaces the old one per class or per AI button, with fallback |
| The AI layer as a whole | What the call does, with what and through what: model choice, project context and the route with a region setting (worldwide or EU), plus two gates before the call: write role and budget |
| IT worksheet | Six tabs, information domains and a single landscape table; what the platform derives is a proposal and only counts once confirmed |
| Foundations | Isolation per organisation in the database, all text and AI instructions in the database, and no method or sector of its own in the platform |
| One base for the schema | The schema is one base file plus the migrations after it; the older migrations are archive |
Access to the full decisions
The full decision documents contain implementation details and internal trade-offs and are therefore not public. They are available to technical partners under non-disclosure.