Between 11 and 16 October 2026 we studied how strong organisations capture, own, use and update operational knowledge, and turned it into a product model. This page summarises what we learned and what we concluded.
The question: what are the smallest building blocks of organisational knowledge that strong companies rely on, and which of them does a first product actually need?
01
The useful unit is an owned, structured piece of knowledge with a purpose, an owner, evidence, a lifecycle and links to the work it supports. A document is only one way of showing it.
02
Across the companies we studied, documentation exists so people can do the work, decide well and learn from failure. Writing more pages is never the goal.
03
One named person is accountable for correctness. Others contribute, review or approve. Unowned knowledge goes stale.
04
Following Toyota's standardised work: the process is the baseline people execute, observe and improve. A change to the process should change how people work.
05
The question is not “was it written?” but “can someone who doesn't know the work do it from this?”. Experts check correctness; beginners expose the steps experts skip without noticing.
06
Keep why a process is the way it is (decisions, context, evidence), and never silently rewrite history. A new decision replaces an old one instead of editing it.
Based on public sources only. We don't claim to know any company's full internal system, and evidence for Toyota, Amazon and McDonald's is mostly second-hand.
We found nine kinds of knowledge (process, work instruction, guide, decision, project brief, training, quality standard, incident, policy). Instead of nine separate systems, the first product needs a shared object model and five building blocks.
Two validators, two questions: the expert checks “is this correct?”, the beginner checks “can I actually do this?”. The owner stays accountable.
Behind the five building blocks sit nine kinds of documentation that strong companies keep. Each answers a different question. We don't build nine separate systems: the first product uses one shared object model with a few specialised forms, and we add types only when real use demands them.
Policy
What must or must not happen?
Process
How do we accomplish the outcome?
Work instruction
How exactly do I perform this task?
The three most often confused: a rule, the way of reaching an outcome, and the exact steps of one task.
What recurring outcome do we produce, and how does the work flow?
Create one when the work repeats, has several steps or people, matters to the business and lives in someone's head.
In the MVP
Exactly how do I perform this task?
In the MVP
What do people need to know to understand or perform this work?
A guide should not turn into a process by accident. If it says “do X, then Y, then Z”, the AI suggests making it a work instruction.
In the MVP
What did we decide, why, and under what assumptions?
Never edited silently. A new decision supersedes the old one, so the history stays intact.
Lightweight in the MVP
What are we trying to accomplish and why?
Later
How does someone become capable of doing this?
Derived from processes rather than written separately.
Partly: built into other objects
How do we know the work is being done correctly?
Starts as quality criteria inside each process.
Partly: built into other objects
What went wrong and what did we learn or change?
The point is that an incident changes the process, instead of being archived.
Later
What organisational rule or constraint governs this work?
Starts as an authority and status on knowledge, not a separate object.
Partly: built into other objects
Field lists are the main fields from doc 3, not the full cards. Different types also follow different lifecycles: a decision is proposed, accepted, then superseded, while a process is drafted, reviewed, tested, validated and finally retired.
Conclusion
Not AI-powered documentation. A system that captures how experienced people actually work, turns it into processes that are owned, backed by evidence and executable, and checks that another employee can follow them. The goal is less dependence on individual experts, not more documents.
Will a company give us access to one expert, one real process and one beginner because they believe turning expertise into a process people can execute is valuable?
Only claims 1–3: capture (AI can extract useful knowledge), structure (into a process precise enough to follow) and transfer (a beginner can use it). Reducing dependency, improvement, replication and scale come later.
70% building a demo you can click through, 30% interviewing customers with it. Target: 5–10 interviews with CEOs, COOs and operations managers, and 3 companies piloting one real process.
Our model is a hypothesis; real companies are the test. We expect them to show us things the model doesn't yet capture, and that is the point.
Main metric: Expert Assistance Rate, how often the beginner needed the expert. Long term: Founder Dependency Rate.
Research documents, oldest to newest. Newer documents override older ones where they disagree.
| Doc | Topic | What it contributes |
|---|---|---|
| 0 / 3 | Mechanism models | GitLab, Toyota, AWS, Google, Amazon, Netflix, Atlassian; nine mechanisms reduced to five MVP primitives |
| 1 | Knowledge primitives research | Evidence-labelled patterns (documented / secondary / inferred / recommendation) and MVP workflows |
| 2 | Research program + CEO/COO questionnaire | Discovery interview design and the first MVP spec |
| 4 | Mechanism catalogue | 15 mechanisms and an MVP acceptance test |
| 5 | Mechanism matrix | Mechanisms across 15 organisations, rated by strength of evidence; 8 canonical mechanisms |
| 6 | Canonical ontology v1 | 12 objects (Process, Step, Knowledge, Decision, Skill, Role, Source, Evidence, Review, Execution, Issue, Version) |
| 7 | Field dictionary + state machines v1 | Design laws, fields, states, AI extraction contract, audit rules |
| 8 | Next-phase recommendation | Stop abstract research; 70% demo / 30% customer interviews |
| 9 | Product evolution roadmap | 10 phases from knowledge capture to a “company OS” |
| 10 | Franchising capabilities | Replication as a later use case; Founder Dependency Rate |
| 11 | Presentation & brand | Knowflow name, palette, deck, interview script, claims discipline, scorecard |
Appendix · Doc 5
How 15 organisations handle documentation, compared on the same attributes. Public sources don't show any company's full internal system, so each row is graded by strength of evidence. Fields and lifecycles are normalised by us; they are not each company's exact schema. The goal is to find the mechanisms underneath, not to copy their documents.
Scroll sideways to see every column.
| Organisation · mechanism | Evidence | Purpose | Trigger | Owner | Core fields (observed / derived) | Lifecycle | Review / validation | Versioning | AI opportunity |
|---|---|---|---|---|---|---|---|---|---|
| GoogleDesign Doc / PRD / project docs | Agoogle.github.io | Explore a proposed design, collect feedback, then preserve design rationale | Significant design/project change | Author / project owner | Problem, context, proposed design, alternatives, feedback, decision, links | Draft → review → implementation → archive | Peer/design review | Docs evolve during work; final design doc becomes historical record | Generate draft from requirements; identify missing alternatives; summarize review; convert final decision into durable record |
| MicrosoftADR / Decision Log / Trade Study | AMicrosoft Learn | Preserve why important decisions were made and prevent repeated debates | Significant architectural/design decision | Decision maker / architect | Problem, context, alternatives, decision, rationale, consequences, confidence, status, date, work required | Proposed → accepted → superseded/deprecated | Design review / PR review | Append-only; new decision supersedes old | Detect decisions in discussions; generate ADR; identify contradictions; link superseding decisions |
| AmazonPR/FAQ + Narrative + Operational Review + COE | AAmazon Web Services, Inc. | Force customer-oriented reasoning; align teams; inspect operations; learn from failures | New product/service, major operational event, recurring business review | Single-threaded owner/team | Customer problem, experience, FAQ, metrics, risks, dependencies, operational readiness, incident impact, corrective actions | Draft → review → decision → execution → operational review → learning | Cross-functional narrative review; operational review | New narratives/records; historical searchable knowledge | Turn conversations into narratives; challenge assumptions; extract risks; generate COE; identify mechanisms needing improvement |
| GitLabHandbook / Handbook-first | AThe GitLab Handbook | Make organizational processes/policies accessible and maintain a single source of truth | Process change, question, new knowledge | Content/function owner; contributors | Purpose, function, process, policy, owner, links, context | Proposal → MR → merge → communicate → update | MR review; handbook update KPI | Git/MR history | Detect undocumented questions; suggest where knowledge belongs; identify duplicates/stale pages; AI search |
| AtlassianDACI Decision | AAtlassian | Make complex decisions accountable and prevent rehashing | Important team/project decision | Driver | Status, impact, stakeholders, due date, Driver, Approver, Contributors, Informed, context, options, pros/cons, actions, outcome | Draft → options → decision → action → outcome | Stakeholder review / approver | Page history; outcome updated as decision evolves | Detect decision participants; populate DACI; summarize options; identify missing approver/owner |
| NetflixContext / Memo / Decision record | Ajobs.netflix.com | Give employees enough context to make decisions independently | Important decision, policy/culture change, major initiative | Informed decision owner / manager | Context, goal, information, decision owner, opinions, dissent, decision, expected outcome, retrospective | Context → discussion → decision → execution → reflection | Informed captain / stakeholders | Memos provide historical context; decision ownership persists | Generate context briefs; retrieve relevant organizational knowledge; surface previous decisions; perform decision retrospectives |
| McDonald'sOperational playbook + hands-on training | Afor the training model; exact playbook schema not public (mcdonalds.com) | Replicate operational standards across franchise/business locations | New operator / location / training cycle | Training organization + operator | Operating standards, procedures, skills, training, practical experience, competency | Training → practice → assessment → competency → ongoing operation | Hands-on training, mentors, competency | Operational standards evolve centrally | Convert expert demonstrations into training; personalized learning; competency assessment; detect location/process deviations |
| StripeStructured documentation / Markdoc | AStripe | Make documentation maintainable, reusable, interactive and machine-validatable | New/change to documentation/product | Documentation authors / engineering | Structured content, metadata, reusable components, links, conditional content | Author → parse → validate → publish → maintain | Schema validation, link validation, CI | Version controlled / generated | Structured generation; schema validation; broken-link detection; semantic consistency; dynamic knowledge presentation |
| ToyotaStandardized Work | Bpublic Toyota principles + Lean literature (oreilly.com) | Establish the current best-known way of performing work and create a baseline for continuous improvement | Process creation/change, quality issue, improvement | Process/work leader + frontline experts | Work sequence, time, work content, standard, abnormalities, equipment/materials, quality criteria | Define → achieve → maintain → improve | Observe actual work; compare standard vs reality | New standard replaces/improves old standard | Observe expert work; generate standard work; detect deviations; identify improvement opportunities |
| ShopifyEngineering RFC | AShopify | Align engineers on technical changes and rapidly build consensus | Significant technical design / performance finding | RFC author | Purpose, context, proposal, risks, alternatives, deadline, reviewers, decision | Draft → async review → feedback → decision | Peer review; explicit veto/deadline mechanism | RFC history / linked implementation | Draft RFC from conversation; identify reviewers; summarize dissent; detect unresolved decisions |
| DropboxDesign Doc | BMedium | Organize thinking, explain why, align team and reduce debate | Every project / significant design | Designer/project author | Goal, problem, rationale, design, related docs, dependencies, feedback | Draft → review → implementation → historical reference | Team review | Connected docs / version history | Generate design docs; connect related artifacts; detect missing rationale; build project knowledge graph |
| UberService RFC / design documentation | AUber | Propose architecture, obtain domain review, prevent duplicate efforts | New service / major architecture | RFC author + domain reviewers | Purpose, architecture, dependencies, implementation details | Proposal → review → feedback → implementation | Domain-expert review | RFC/document history | Generate RFC; find related systems; identify duplicate work; extract architecture decisions |
| NASASystems engineering work products / decision analysis / technical data management | ANASA | Control complex system development across lifecycle and preserve traceability | Project phase, milestone, technical decision, change | Defined technical authority / project roles | Requirements, alternatives, decision criteria, analysis, impacts, reviews, verification, validation, lessons learned, version/security | Lifecycle phases → reviews → approval → implementation → verification → closeout | Formal milestone reviews, verification/validation | Controlled versions; traceability | Trace requirements → decisions → evidence → outcomes; generate review packages; detect missing evidence |
| IBMArchitecture Decision | Bcloud.ibm.com | Preserve architectural rationale and traceability | Component/design choice | Architect / solution team | Options, criteria, selected component, rationale, dependencies, risks, lifecycle impact | Evaluate → decide → document → implement | Architecture review | Historical record / linked design | Extract decisions from architecture discussions; compare alternatives; maintain dependency/rationale graph |
| IntelManufacturing Advantage Service documentation | B/Cpublic material confirms it exists, but much is confidential (Intel) | Define/reference manufacturing processes for Intel products/technologies | Manufacturing/product context | Manufacturing/quality organization | Product/process reference, applicable manufacturing information, controlled access | Create → controlled publication → update/retire | Controlled documentation process | Controlled/confidential versions | Capture manufacturing expertise; detect process changes; role-specific instructions; controlled knowledge retrieval |
The names are misleading. Once you ignore the terminology, the companies keep solving the same few problems.
Google & Dropbox design docs, Amazon PR/FAQ, Microsoft trade study, Shopify & Uber RFCs
Reason about a significant change before committing resources.
Microsoft ADR, Atlassian DACI, Netflix decision owner, IBM architecture decision
Keep what was decided, why, by whom, and what it replaced.
Toyota standardised work, McDonald's playbook + training, SOPs, work instructions
The repeatable way to produce an outcome, and the baseline for improving it.
Shared across all of them: a named owner (separate from whoever created, reviewed or approved it), the context in which it applies, explicit validation, versions that supersede instead of overwriting, and links instead of copies. Different kinds of knowledge also need different lifecycles: a decision is proposed, accepted, then superseded; a process is drafted, reviewed, tested, validated, then retired.
Every important piece of company knowledge should answer:
Takeaway: the differentiator isn't answering “where is our information?” or “ask AI about our documents”. It's answering “can another person actually do the work using what the company knows?”. We don't turn the matrix into 15 templates; each mechanism feeds one shared definition (see the ontology, doc 6).