There’s a question most product teams can’t answer: is our product definition in good shape?
Not “do we have documentation?” — teams always have documentation. Not “have we shipped the roadmap?” — shipping is a different thing. The question is: does our shared model of what this product is accurately reflect what we’ve built, why we built it, and what we still need to build?
For most teams, the honest answer is: we don’t know. We have docs, we have tickets, we have Figma files. Whether any of that adds up to a coherent, current, trustworthy description of the product is something nobody has ever measured.
That’s the problem. And it’s more expensive than it looks.
Why Product Quality Is Hard to Measure
Software engineering has quality signals everywhere. Test coverage tells you how much of the code is verified. Type safety tells you how many contracts are enforced at compile time. Lint and static analysis catch inconsistencies before they hit production.
Product knowledge has none of this. You can feel when a product definition is in bad shape — the team is asking questions that should already be answered, decisions keep getting re-debated, engineers are guessing about edge cases — but there’s no metric that surfaces this before it costs you a sprint.
The reason is structural. Traditional product documentation is prose. Prose can’t be validated. You can read it, you can judge it, but you can’t run a program against it that says “this rule contradicts that flow” or “this feature has no way to measure success.” There’s nothing to check.
A structured product graph is different. When every feature, need, rule, flow, and metric is a typed node connected by explicit relationships, the structure itself becomes checkable. You can ask: is this feature justified by a user need? Does this need have a human behind it? Does this flow have a clear exit point? Is this metric actually connected to a live data source?
Those checks produce a signal. And once you have a signal, you can have a score.
The Four Dimensions of Product Health
Specor’s Product Health Score aggregates everything its AI agents observe into a single 0–100 number, updated in real time as the product evolves. It’s built from four dimensions, each representing a different way a product definition can be in or out of shape.
Coverage — Are the dots connected?
Coverage measures whether the semantic graph is actually wired together. Features should link to the Needs they fulfill. Needs should trace back to a Persona — a real person with a stake in the outcome. Capabilities should have Features under them. Flows should have Steps.
A low coverage score usually means one of two things: either the product is genuinely underspecified (a lot of things exist but haven’t been connected to their purpose), or the graph is being used as a flat list rather than a semantic model. Both are problems, and they have different fixes.
The question coverage asks is: can you trace every piece of the product back to a human reason for its existence?
Consistency — What are the agents saying?
Consistency is the inverse of what the AI agents are finding. Every pending error or warning suggestion is evidence of an inconsistency somewhere in the product model — a conflict between two rules, a flow with no terminal step, a metric that measures something irrelevant to the feature it’s linked to.
The consistency score isn’t just a count of issues. It’s weighted by confidence: a high-confidence error (the agents are sure this is a real problem) hurts the score more than a speculative warning. Resolving issues improves the score in proportion to how certain and how severe they were.
The question consistency asks is: if an AI agent read your product model right now, how many things would it flag as wrong?
Completeness — Is the graph actually filled in?
Completeness measures the quality of what’s in the graph, not just whether things are connected. A node with a placeholder title (“New Feature”) or no description contributes almost nothing to team understanding. A Metric node that’s defined in the graph but not connected to any live data source is declared but not operational.
Completeness catches the difference between a graph that looks complete and a graph that actually is. Nodes need real names. They need descriptions. And Metrics — which only exist to measure success — need to be bound to actual data, or they’re just intentions.
The question completeness asks is: if someone new joined your team and read this graph, would they understand the product?
Freshness — Is this still being maintained?
Freshness is the dimension that makes the other three matter over time. A product graph that hasn’t been touched in 90 days is a product graph that’s becoming a fossil. The world has changed. The team has shipped things. Decisions have been made. None of it is in the model.
Freshness tracks two signals: how recently nodes have been updated, and how recently a commit has been sealed. Commits are how the team marks “we’ve reviewed and approved this version of the product.” If no commit has been sealed in months, the graph may still be accurate — but nobody has verified that it is.
The question freshness asks is: is this a living product model, or a snapshot that’s quietly going stale?
What a Good Score Looks Like in Practice
A score of 80+ means the graph is in genuinely good shape: the team’s reasoning is visible, the agents aren’t raising alarms, the content is real, and the model is being actively maintained.
A score in the 60–79 range usually means one dimension is dragging the others down. Coverage might be high but freshness is low — the graph is well-connected but hasn’t been touched since the last major release. Or consistency is fine but completeness is struggling — lots of nodes with placeholder titles from a batch import that never got cleaned up.
Below 60 is where teams start feeling the cost in meetings, re-debates, and engineering questions that should have been answered by the spec. The score doesn’t cause those problems — it’s just a number. But it surfaces the structural issues that do.
The Difference Between a Score and a To-Do List
It’s worth being clear about what a health score is and isn’t.
It isn’t a to-do list. Specor’s AI agents generate specific, actionable suggestions — “this feature has no metric,” “these two rules conflict,” “this flow has no terminal step.” Those are things you can act on directly.
A score is a summary. It tells you whether things are getting better or worse, whether one dimension is consistently lagging, whether a product you inherited is in better shape than you feared or worse shape than you hoped.
The goal isn’t 100. A score of 100 would mean every feature is fully traced to a persona and need, every metric is live-connected, every suggestion has been resolved, and the graph was updated yesterday. That’s theoretically possible but probably means the team is spending more energy on the model than on the product.
The goal is a score you trust, moving in the right direction. And the direction matters more than the number.
Why This Didn’t Exist Before
The reason product health scoring hasn’t been a thing until now is that it requires a structured product model to operate on. You can’t run coverage checks on a Notion page. You can’t check persona traceability in Jira. You can’t measure freshness in a system where nothing is versioned.
The score is only possible because the underlying model is structured, versioned, and machine-readable. The AI agents can check it because it has a schema. The freshness signal exists because every change is a commit event. The metric binding rate is measurable because Metrics are typed nodes with explicit bindings, not a number someone typed into a doc.
This is what it looks like when product knowledge stops being prose and starts being data.
There’s a related layer that operates at the branch level rather than the node level: Product Intelligence. Where the six Spec Quality agents check individual nodes in real time, Product Intelligence scans the whole branch on every commit seal — catching compliance gaps (SOC2, OWASP), missing UX flows, and analytics issues that only become visible when you look at the full picture. Read about how Product Intelligence works →