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 tier is what sets the rules each one answers to.
Decided¶
Immutable once accepted. What was decided is superseded, never rewritten.
| 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¶
Living and owned. Edited in place, with a changelog.
| 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, RFC 2119, 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¶
Living, and must mirror reality. Verifiable against the estate.
| 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, repo, 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¶
Living, and must be rehearsed to stay true.
| 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.