Frameworks as Projections
Every framework, reading one graph instead of its own copy
A team runs on frameworks: an Opportunity Solution Tree for discovery, a Business Model Canvas for strategy, RICE for prioritisation. The cost is not the frameworks themselves; it is that each one is its own document. The same opportunity gets retyped into three of them, and then it drifts in all three. UPG treats a framework as a lens over the graph rather than a file to maintain. The entities live in the graph once, and each framework is a projection over them.
“All models are wrong, but some are useful.”
The same nodes, read by three frameworks at once
An opportunity, a solution, a feature, a metric: each typed once in the graph. An Opportunity Solution Tree reads them as a tree. A Business Model Canvas reads the strategic ones into its nine cells. RICE reads the features into a scored table. Each framework projects those shared nodes; none of them stores a second copy.
Because the three views project the same nodes, a change made in one is a change in all of them. The tree and the canvas stay agreed on what the opportunity is, because the graph holds a single opportunity for both to read.
opportunity · solution · feature · metricA tree, a matrix, a scored table: three frameworks, one underlying graph. They read the same nodes through different lenses, so a change in one is a change in all. No copying between tools, nothing to keep in sync.
Frameworks already mapped to the graph
UPG ships a catalog of canonical frameworks, each tagged with the structural pattern it draws (tree, matrix, quadrant, table, funnel, flow, collection) and the entity types it reads. Adopting a framework selects one of these lenses; it does not import a template to fill in.
The catalog grows without changing the graph. A new framework is a new projection over entities that already exist, so it reads the team’s current work the moment it is added.
Seven shapes a framework can draw
Each framework declares two things: the structural pattern it draws and the entity types it reads. Seven patterns cover the field (a tree, a matrix, a quadrant, a table, a funnel, a flow, and a collection), and every catalog framework is one of them pointed at a set of types.
That declaration is also why the catalog grows without touching the graph. A new framework is a new declaration over entities that already exist, so it reads the team’s current work the moment it is added, with nothing to migrate.
A framework declares the structural pattern it draws and the entity types it reads. Seven patterns cover the field: a tree, a matrix, a quadrant, a table, a funnel, a flow, a collection. Adopting one selects a lens rather than importing a template, so a framework projects over the existing graph as soon as it is added.
Frameworks are Layer 4 of the spec: a read-time presentation concern, never written into the file. The graph stays canonical, and each framework is one way of reading it. Follow a thread: