The Modeling Layer
Graph-native context and the operating ontology
Part I: The Modeling Layer
Graph-Native by Design
For small organizations and teams, you can get by with transforming unstructured data: docs, markdown files, decks, spreadsheets, chat threads, transcripts. This is valuable and necessary front-line context processing regardless, but every 'transformation level' is lossy from a cost and accuracy perspective.
This is not optional at a level of scale. An Operating Context System must be graph-native. The tradeoffs of building it any other way are too steep. You may be able to move faster locally (at the speed of spinning up a database), but you lose rich semantic cartilage.
Non-graph-native systems hit hard walls beyond three-hop queries. Complexity increases with expensive queries and table sprawl. Adding and adapting schema is painful. They miss out on the semantic information that is explicit in graph-based systems: the meaning embedded in how things connect, not just what things are.
| Capability | Non-Graph Systems | Graph-Native Systems |
|---|---|---|
| Multi-hop queries | Hard limit around 3 hops | Deep traversal across any number of hops |
| Schema changes | Painful migrations | Additive and non-breaking |
| Semantic relationships | Implied by table joins | Explicit, typed, and queryable |
| AI reasoning surface | Fragmented and flat | Rich and relational |
| Adaptability | Rigid | Evolves with the operating model |
Organizations are not tables. They are webs of structured, semi-structured, and unstructured information across dozens of systems. The same initiative might be called an epic in one tool, a strategic pillar in another, and a project in a third. The relationships between a team, the outcomes they own, the decisions they've made, the customers affected by those decisions: these are inherently relational. A table can't represent that. A graph can.
A graph-native architecture enables something critical: querying across hops. "What work is in-flight for teams whose roadmap intersects with this strategic bet, and what's the delivery confidence on those teams right now in the current quarter?" That's a four-hop question that has to resolve 'time' across dates, months, and quarters. Non-graph systems make this painful or impossible. For AI agents reasoning about organizational reality, this is table stakes.
Being graph-native also means the schema can evolve. Operating models change. New artifact types emerge. Relationships get redefined. A graph-native system is schema-flexible and accommodates this without breaking. A rigid schema system requires painful migrations every time the organization learns something new about itself.
Dotwork was started (a month before the ChatGPT moment in October 2022), with the stubborn belief that making the operating model explicit and actionable was fundamentally a graph problem - in a world where all tools were designed as hierarchies.
The Operating Ontology
Before the knowledge graph can come to life, you need to define the operating model. This is the ontology: the explicit definition of what kinds of things exist in your organization, what properties they have, and how they relate.
The operating model can be designed, observed, or shaped through a blend of both. Many organizations already have people who are very thoughtful about this work. They're in ops functions, program management, chief of staff roles. Sometimes it's a leader. Sometimes the starting point is observing the tools, unstructured exhaust of the work, and existing rituals to take the implicit operating model and make it explicit.
The operating ontology is not a data model. It's a model of organizational meaning. A good ontology captures the artifact types that matter (initiatives, objectives, teams, customers, risks), the relationships between them (an initiative advances a strategic pillar, a team owns an outcome, a decision resolves a tradeoff), and the properties that make those artifacts meaningful (status, owner, confidence level, time horizon). Some of these artifacts already have an explicit home in data - some likely do not. AI amplifies the problem that necessitates making these things explicit in data, but it also provides new tools for processing and maintaining both the knowledge graph and the ontology.
The ontology should be built by people who understand how the organization actually operates, not how leadership wishes it operated, and not a copy of someone else's framework. The organizations that fail here are the ones that import a methodology wholesale and try to force their reality into it. This often happens with tooling as the shoehorn. The operating model should fit the organization, not the other way around.
A critical design principle: model what's real and build from there, not what's aspirational. If teams don't actually track dependencies, don't model "has dependency" as a first-class relationship until the behavior exists. Premature ontological precision is dangerous.