Knowledge layers¶
Conductor must keep different kinds of knowledge separate because they have different authority and lifecycles.
| Layer | Example | Authority |
|---|---|---|
| Core model | Workstream, stage, inventory, authorization | Conductor architecture |
| Organization policy | Secret management, deployment defaults, approval roles | Hector-approved corpus/profile |
| Initiative state | Outcome, active workstreams, next action, evidence | Notion |
| Software delivery state | Repository, PR, checks, release, deployment | GitHub |
| Estate description | Existing app purpose, capabilities, lifecycle, links | Notion asset registry with source provenance |
| Descriptive history | What happened and why | Notion events plus authoritative artifact links |
| Experience | Blocker, workaround, failure, repeated question | Conductor feedback store |
| Candidate policy | Possible new or changed pattern | Non-binding until governed approval |
Layer authority¶
Knowledge at a higher layer constrains lower layers. Knowledge at a lower layer cannot override higher layers:
Core model ← Conductor architecture (immutable)
↓ constrains
Organization policy ← Hector-approved corpus/profile
↓ constrains
Initiative state ← Notion (live work contracts)
↓ informs
Delivery evidence ← GitHub, editorial tools, client folders
↓ informs
Estate description ← Notion Asset registry
↓ feeds
Experience ← Conductor feedback store
↓ generates
Candidate policy ← Non-binding improvement candidates
Related documents¶
- System components (the runtime architecture):
../reference/authority/authority-model.mdownership table - Organization profile (core vs org layering): organization-profile.md