- 10When are specifications not enough?
- 11Where is the state of the work kept?
- 12Who prepares a change before coding starts?
- 13What does impact analysis tell you, and when does it run?
- 14How do coding agents use the graph?
- 15How is each change checked, and how does the graph stay current?
- 16Who decides which work agents do?
- 17How do managers see what people and agents are doing?
- 18What happens across many products?
- 19What about existing systems and technical debt?
- 20What changes for the team?
- 21What results have teams seen?
Home / Follow the story / Scene 6: The four layers
Transcript
6. The four layers
For an application in use, the knowledge graph has four layers, and each layer is called an ontology: a structured description of one kind of knowledge. The Functional Ontology holds personas, outcomes, scenarios, steps and actions, and the Product Owner keeps it. The Design Ontology holds screen components and their building blocks, page templates and user flows, kept by the UX Designer and the design system owner. The Architecture Ontology holds services, boundaries, dependencies, data stores and integrations, kept by the Architect and the tech lead. The Code Ontology holds modules, classes, functions, endpoints and database schemas, kept by the Engineering Team. Links connect the layers, so one search can follow a user action through to the screen component, the service and the code function behind it. On one user story about email alerts, following those links found fourteen affected parts of the architecture and fifteen code changes across five repositories. The search runs before any code is written. Every item in the graph cites its source: the document, design frame, ticket or code file it came from.
On the site: The Four-Layer Ontology · Cross-Layer Traversal · Citations at Every Layer
Choose a path
The full video in six parts and an appendix, one part at a time.