There’s a class of problem that per-node AI agents were never designed to find.
The six Spec Quality agents in Specor are reactive: they fire when a node changes, check that node in context, and surface specific issues — a missing metric here, a conflicting rule there. They’re fast, they’re cheap, and they catch a lot. But they have a structural blind spot: they see individual nodes, not the whole product.
Compliance and UX gaps live at the product level. You can’t tell that a product has no login flow by looking at a single Feature. You can’t detect a missing authentication rule for the Checkout feature just by reviewing the Checkout node in isolation — you have to know which personas are involved, which rules govern it, and what’s absent. That’s a branch-level question, not a node-level question.
That’s what Product Intelligence does.
What it looks for
When you seal a commit — or trigger it on demand — Product Intelligence runs a sweep of your entire branch. It builds a complete picture of your product graph, including every node, every relationship, and every live metric reading, then runs a battery of deterministic checks against it.
The initial set covers the gaps that matter most for early-stage SaaS products:
Compliance & Security
- Auth gap (SOC2 CC6.1): a Feature involving user personas with no authentication rule governing access
- Missing audit trail (SOC2 CC7.2): destructive or sensitive features with no audit-log rule
- Rate limiting gap (OWASP A01): public-facing features with no rate-limit rule
- Admin no privilege rule (SOC2 CC6.1): admin-oriented features without an explicit access-control rule
UX & Flows
- No login or signup flow for a product with user personas
- Destructive actions (delete, remove, permanently) with no confirmation step
Product Completeness
- A login feature exists but no password reset path is defined
Analytics Insights (when metrics are connected)
- Metrics below their defined targets
- Metric data that has gone stale
- Features with no metric to measure their success
Why deterministic, not LLM
Every check in this first set is deterministic. It’s a graph query: does this feature have a neighboring rule whose title contains “auth” or “authentication”? Does a flow exist whose title contains “login” or “sign in”? Is this metric’s live reading below its target?
No LLM is invoked. No AI credits are consumed. This keeps the sweep cheap enough to run on every commit without thinking about it — and it keeps the results reproducible. Run the same sweep twice on the same graph and you get the same findings.
That matters for compliance use cases specifically. When a SOC2 auditor asks “what controls do you have on user access?”, you want to point to a verifiable, deterministic check — not a probabilistic one that might give a different answer next week.
The findings are framework-tagged at creation time. A finding about a missing authentication rule carries SOC2 CC6.1 as its reference. A finding about a rate-limiting gap carries OWASP A01. When you open the Product Intelligence inbox, you see exactly which framework each finding maps to, without having to look it up.
Separate from Spec Quality, on purpose
The Product Intelligence inbox is distinct from the Spec Quality inbox. This distinction is intentional.
Spec Quality is for PMs and the team doing the daily work: keeping the spec clean as it evolves, catching naming collisions, resolving conflicts between rules, making sure every feature has a metric. The findings are per-node, immediately actionable, and often generated in seconds after a change.
Product Intelligence is for a different audience — and a different cadence. It’s for the PM who’s preparing for an audit, the CPO reviewing a new feature domain before launch, or the engineering lead asking “does our spec say anything about rate limiting?” It runs on commits, not on every edit. The findings are strategic, cross-cutting, and take longer to address because addressing them means adding nodes and relationships to the product model, not just tweaking a title.
Mixing these two streams in one inbox would dilute both. So they stay separate.
What “Mark Addressed” means here
Spec Quality suggestions often have a structural fix: add a metric node, change a title, remove a duplicate. Product Intelligence findings don’t. Telling you that Checkout is missing an auth rule doesn’t fix it — you have to go add a Rule node, write it correctly, and link it to the Feature.
That’s why the actions on a Product Intelligence finding are “Mark Addressed” (resolve — I’ve fixed this in the spec) and “Dismiss” (reject — this doesn’t apply to my product). There’s no auto-fix. These are things that require judgment, and Specor doesn’t pretend otherwise.
The findings expire naturally: once you add the missing rule or the missing flow and re-run the analysis, the check no longer fires and the finding closes itself.
The broader intent
Most product specs are written by people who are thinking about features, not threat models. That’s appropriate — PMs shouldn’t become compliance experts to write a good spec. But the spec does encode enough information to catch the most common gaps automatically, if something is looking for them.
Product Intelligence is that something. It reads your product graph the way an informed reviewer would, asks the structural questions that matter for compliance and UX, and tells you what’s missing — before your users find out, or before your auditor does.
If you’re already using Specor, the next sweep runs automatically on your next commit. If you want to run it now, the “Run Analysis” button is in the Product Intelligence tab.
For the full list of checks and what we’re planning for P1 and P2, see the Product Intelligence docs.