Framework Exercise

Why it exists

Teams apply frameworks constantly, yet the output usually lands in a throwaway spreadsheet, detached from the things it scored. The alternative many tools reach for is worse: they stamp the verdict straight onto the entity, so a feature⭐FeatureProduct SpecificationA product capability or featureView reference → grows a rice_score field. That conflates two different claims. The entity is a lasting fact about the product; the score is a fact about one exercise's view of it on one day. Recording the run as its own node keeps the two apart, so a feature can be scored in March and again in June, by RICE and by MoSCoW, without any single verdict overwriting the entity or the others.

How it works in practice

You apply a framework to a set of entities, for example RICE across the features you are weighing for next quarter. The exercise becomes a node that includes each feature it touches. Each feature's reach, impact, confidence, effort, and resulting score ride on that include link, not on the feature. Run MoSCoW over the same features a month later and you get a second exercise, a second set of links, and a clean before and after, with both feature nodes untouched.

Because a framework can change after the fact, an exercise can keep an inputs_snapshot, a frozen copy of the framework's input spec at the moment it ran. If the framework later adds an input or rescales a field, the historical exercise still renders exactly as it was scored.

The result lives on the link, not the entity

This is the design decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → that makes the type work. A MoSCoW bucket, a RICE number, a canvas slot, a funnel⬇️FunnelGrowthA conversion funnel tracking user progressionView reference → stage: each is a value that exists only inside a specific exercise, so it is a fact about the relationship between the exercise and the entity, not about the entity itself. UPG records it on the framework_exercise_includes_nodeFramework Exerciseincludesany entitycross-domain edge, the same principle that models ownership as an edge rather than an owner field. The link is also polymorphic: an exercise can include any entity type, not only features, so you can score opportunities🚪OpportunityDiscoveryA validated gap worth solvingView reference →, sort needs🫀NeedUserA user need, pain, desire, or constraintView reference →, or run a canvas over business-model entities through one mechanism.

Framework exercise vs. its neighbours

• Framework is the reusable definition: the method, its inputs, and how it presents results. It is a template, identical for everyone who runs it.
• A framework exercise is one dated run of that framework over your entities. The framework is the recipe; the exercise is the meal you cooked on Tuesday.
• The scored entity, a feature, opportunity, or metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →, keeps its own identity. The exercise points at it and records a verdict, but never changes what the entity is.

In the graph

A framework exercise lives in the workspace🏠WorkspaceWorkspaceA spatial thinking space for arranging entitiesView reference → domain, the space for exploration rather than settled product truth. It anchors to a workspace and reaches its subjects through framework_exercise_includes_nodeFramework Exerciseincludesany entitycross-domain, the edge that carries each per-entity result. It moves through three phases, draft, active, and archived, mirroring the life of the analysis it represents. The workspace is deliberately transient: when an exercise surfaces something worth keeping, such as a decision or a reprioritised roadmap🛣️RoadmapProduct SpecificationA strategic plan of features and milestonesView reference →, promote it into the durable graph rather than leaving it to age inside the workspace.