The default types¶
Eighteen knowledge types ship with the framework. A corpus adopts the ones it needs by naming them in types: in
.corpus.yaml. kac never writes a declined type's schema file, so nothing arrives to
be ignored.
Adopting all of them is not expected. A corpus running one product might stand up four and never want the rest. It can also declare a type of its own that the framework has never heard of. What follows is what you get without deciding anything.
They are grouped by tier, because a type's tier sets the rules its records follow. The four tiers says what each tier asks of a record.
Decided¶
| Type | Folder | What it holds |
|---|---|---|
| ADRs | adrs/ |
An architecturally significant decision affecting more than one repository, and the reasoning behind it |
| Postmortems | postmortems/ |
What actually happened during an incident: timeline, impact, root cause, contributing factors, actions |
Normative¶
| Type | Folder | What it holds |
|---|---|---|
| Policies | policies/ |
A high-level engineering commitment: the what and the why, largely stack-agnostic and changing rarely |
| Standards | standards/ |
The rulebook, imperative, BCP 14, with concrete examples and a conformance checklist |
| Controls | controls/ |
How a standard's rules are verified: the mechanism, the frequency, and the evidence it leaves |
| Deviations | deviations/ |
A knowing departure from a rule, the person who accepted the risk, and the date it is reviewed |
| NFRs | nfrs/ |
A non-functional requirement (availability, latency, RPO, RTO) stated with how it is measured |
| Fixes | fixes/ |
A problem with a resolution somebody has verified, and the record of who verified it |
Descriptive¶
| Type | Folder | What it holds |
|---|---|---|
| Offerings | offerings/ |
What you offer a customer and why, as a hub linking to what implements, tests and constrains it |
| Services | services/ |
One deployable component: purpose, repos, platform, environments, dependencies, data stores, owner |
| Integrations | integrations/ |
An external system you depend on: the contract, the auth, the failure modes, their SLA and your fallback |
| Data | data/ |
Which service owns which data, how long it is kept, how sensitive it is, and where personal data flows |
| Tools | tools/ |
The approved-software register: what is chosen, rejected or deprecated, and the version ranges you stand behind |
| Glossaries | glossary/ |
The ubiquitous language. Terms whose meaning is specific to you, or which are easily confused |
| Explanations | explanations/ |
Narrative that helps you understand how something works, or why it is shaped the way it is |
| Reports | reports/ |
A question about the corpus answered over the whole of it, with the judgement a person added |
Procedural¶
| Type | Folder | What it holds |
|---|---|---|
| Processes | processes/ |
A planned procedure followed deliberately: releasing, onboarding, provisioning, rotating a secret |
| Runbooks | runbooks/ |
An incident-time procedure read under pressure: terse, imperative, structured as a decision tree |
The pairs that look alike¶
Several of these sit close enough to be confused, and the schema declares the distinction on the type it belongs to. An ADR is the decision and its reasoning, frozen. A standard is the rule that results, kept current. A process is read at a desk, and a runbook at three in the morning.
A corpus's own taxonomy page renders every such pair it holds both sides of. The distinctions you meet are therefore the ones your own types actually raise.
Adding one of your own¶
A type is a YAML file in .schema/ declaring its fields, its tier and its rules, and nothing upstream has to agree.
Taxonomy says what it takes, what it costs, and where the decision belongs.