Every claim your team makes, and what stands behind it.
You were probably sent here to find out whether this is real. This page is the mechanism, in order, with an example and a list of the things it doesn't do.
Two sources, one pipeline
What gets read.
What you bring in
Strategy decks, research notes, call transcripts, tickets, survey exports, anything your team already wrote somewhere else. A snapshot of what was true when someone wrote it.
What your team writes here
Opportunities, objectives, solutions, experiments, personas, pain points, ideas, roadmap items — the artifacts produced while doing the work. Live, and checked as it is written.
- We read what your team writesA claim is any statement asserted as true — about a customer, a market, a behaviour, or a result. Both sources feed the same pipeline, so a claim made in an imported research note and a claim made in an opportunity written this morning are treated the same way.
- Those claims get connected into a graphEach claim keeps a link to where it came from: the artifact, the section, the date, the person. Pulling a claim into a roadmap item carries that link with it.
- Each claim is checked against your existing workWhat supports it, what contradicts it, what depends on it. A new interview that undercuts a claim made six months ago surfaces against every decision built on it since.
- Each claim carries its evidence statusAssumed, indicated, or proven. The status is derived from what the graph actually holds, so it changes when the evidence changes.
This runs while you work. The opportunity a PM drafts this morning enters the graph the moment it's saved, and comes back rated against the failure taxonomy before anyone has built anything on top of it.
A worked example
One paragraph, four claims.
"Enterprise buyers churn because onboarding takes too long. Shortening setup to under a day will cut first-year churn by roughly a third, and it's the single biggest lever we have this year."
The paragraph reads as one confident argument. Three of its four claims have nothing linked behind them. The one piece of evidence in the building supports only the part everyone already agreed on — that enterprise accounts churn faster.
The vocabulary
Four evidence statuses, and what each one requires.
Status is a property of the evidence rather than of the person who said it. A claim made by the CEO and a claim made by an intern with the same support behind them carry the same weight.
Where the evidence comes from
The tools your team already uses.
A product's evidence lives across roughly fifteen systems — the CRM, the support desk, the analytics tool, the research repository, the ticket tracker, the places customers actually talk. An integrity system that can't reach them is checking a snapshot that went stale the day it was taken.
Connectors cover the common ones. Beyond that there is a REST API, webhooks, and an integration layer you can extend yourself. We will never pre-build every connector anyone needs, so we leave the door open rather than pretend the list is complete.
Honest limits
What this doesn't do.
- It doesn't decide for you.The graph shows what your evidence supports. Choosing what to build against that is still your job.
- It can't manufacture evidence you never gathered.An artifact full of assumptions comes back rated as an artifact full of assumptions.
- Sage says "I don't know."Where the graph holds nothing relevant, you get a refusal and the empty node that caused it.
If you're reporting back
The short version to forward.
Shorter Loop reads what a product team writes — both the documents they bring in and the artifacts they create while working — and extracts the claims inside them. Each claim stays attached to its source as it moves into roadmap items and decisions, and carries an evidence status of assumed, indicated, or proven, derived from what the underlying graph holds.
The practical effect: you can ask why any roadmap item exists and get the evidence rather than a name, and you can see which parts of a plan rest on things nobody has checked.