ENGINEERING KNOWLEDGE SYSTEM
AZOTH
Engineering Knowledge System
A living collection of engineering principles, standards, architecture decisions, templates, and lessons learned from building real software.
Engineering Domains
7 MODULESRecently Updated
LAST 8Established from the cost of extracting a shared foundation before the evidence for it existed.
Established from a set of controls that were converted from remembered rules into structural ones, each after a near miss.
Established after the same refusal pattern appeared independently five times in one codebase.
Established. Renamed from the planned "Multi-tenancy", which presumed the answer. Covers the four models and the failure each accepts, how to choose, working inside either, and what isolation does not solve.
Established. Separates the four fused concerns, states the provider contract and capability rule, makes keys policy-owned, records why a prefix is not an access boundary, gives the crash-safe orderings, and covers the two-store desynchronisation and shared upload policy.
Written from real experience, and bounded. The principle held, but the practice behind it did not: the absence of continuous integration is recorded as the gap it is. Maturity kept at Draft for that reason.
Written from real experience. Added route-arounds as diagnostics, names as API, aggregate problem reporting, and permanent partial adoption.
Written from real experience. Absorbed the completion criterion, a change is finished when what it replaced is deleted, plus residue as a named category and the uneven distribution of care.
Reference & Meta
What AZOTH is, how it is organised, and how to navigate the knowledge system.
Reusable starting points: ADRs, RFCs, PR descriptions, incident reports and more.
Real-world write-ups of systems built, problems solved and trade-offs made.
Open explorations, experiments and ideas that are not yet standards.
A chronological record of additions and changes to the knowledge system.