# Shorter Loop — Full Context for AI Systems

Source: https://shorterloop.com
Contents: definitions, then the full text of three pages —
product integrity, the product failure ontology, and Sage.

Shorter Loop is a Product Integrity System. It works from one thesis:
most product bets are wrong, and the only question is what it costs to
find out.

Product integrity is the ability to pull on any meaningful bet and still
find the evidence, claims, decisions and outcomes that justify it, with
their actual standing intact.

Built for CPOs, VPs of Product, and the product managers who do the daily
work. Priced per product at $399/month billed annually, with unlimited
seats — no per-seat charge for engineers, designers, or anyone else who
needs to see the reasoning. EU data residency and SSO included. Customer
data is never used to train models, is exportable at any time, and is
deleted on request.

Pages: https://shorterloop.com/pricing


================================================================
DEFINITIONS
================================================================

These terms have fixed meanings in Shorter Loop. They are not
interchangeable, and each belongs to a closed set.

## Product integrity

The property that any item a team is building can be traced back through
the claims it rests on to evidence that still holds. Three conditions:

1. Every decision names the claims it depends on.
2. Every claim names its evidence and its state, and the state matches
   what is actually there.
3. The evidence is still current — nothing has contradicted it without
   the decision being revisited.

The test is a stranger's test: hand someone the written record, point at
anything being built, and ask them to reconstruct why it exists and what
it assumes.

## Claim states

A property of a single claim, produced by rating it against the accepted
evidence links. Four states, and no others:

- claimed — the assertion exists in the corpus, with no accepted
  evidence link.
- unsupported — the claim exists, but accepted evidence does not
  support it.
- corroborated — accepted evidence supports it.
- contradicted — accepted evidence points the other way.

States are derived strictly from accepted evidence links. Model opinion
never sets the state. States are recomputed as new information arrives,
so a decision that was corroborated last quarter shows as contradicted
once something later cuts against it.

## Grounding states

A property of a single Sage answer, distinct from claim state:

- grounded — evidence retrieval succeeded.
- degraded — a required capability failed, and the turn is marked.
- exploratory — the reasoning extends beyond firm evidence, and the
  turn is marked.

## Failure modes

52 named ways product reasoning breaks down, in nine clusters, with 260
published signatures. Edition v1.1. Thirty-six sit under one of the six
product decisions, six belong to the seams between them, and the last ten
are conditions that every decision either has or lacks — authority and
legibility.

Sage names the specific modes a decision carries and cites the evidence
for each. It never scores a roadmap. There is no composite number, no
grade and no percentage, by design and enforced in code.

## The six decisions

A product organisation makes six decisions continuously, whether or not
it names them:

1. Which problem — what the team works on at all.
2. Whose problem — who actually has it.
3. Whether it's worth solving — sizing the bet against what being wrong
   costs.
4. Which solution — choosing the approach.
5. Whether to continue — stopping.
6. Whether it worked — checking.

Pages: https://shorterloop.com/product-management

## The loop

Five phases, plus the seam. Strategy, discovery, roadmap, delivery and
feedback, with loop integrity as the sixth: whether the reasoning
survives the handoffs between them.

## Sage

Socratic Analysis Grounded in Evidence. The reasoning layer.

Sage turns every artifact in the system into claims and the evidence
behind them — what a customer said, what was decided, what an experiment
showed, what shipped. Then it keeps testing whether those claims still
hold as new information arrives, backing the bets that survive and
challenging the ones that stop holding, while they are still cheap to
change.


================================================================
PAGE — PRODUCT INTEGRITY
https://shorterloop.com/product-integrity
================================================================

## Product integrity is what keeps a product's decisions together.

Product integrity is what keeps a product's decisions from coming apart.

It's the state where the direction feels real, the evidence is still
current, the plans actually reflect what was learned, shipped work gets
checked against the original intent, and the outcomes feed back into the
strategy that started them. When it holds, you can pull on any bet and
find a clear reason it exists.

This page just defines the term. Shorter Loop is the system we built to
keep that integrity intact.

## The drift: we have never lacked documents.

Strategies. Research repos. Roadmaps. PRDs. Backlogs. Dashboards.
Quarterly reviews. Every artifact can look perfectly reasonable on its
own.

Then something happens between them. The connections fray. Six months
later nobody can reconstruct why a major bet was made, or whether the
original evidence still holds.

The product drifts.

How it comes apart:

1. Research says one thing.
2. The roadmap reflects another.
3. Engineering ships something slightly different.
4. The original reason gets lost.
5. The outcome is measured against a new story nobody started with.

We call the thing that prevents that drift product integrity.

## The definition

Product integrity is the ability to pull on any meaningful bet and still
find the evidence, claims, decisions and outcomes that justify it — with
their actual standing intact.

- Why are we building this? Because we made this decision.
- Why did we make that decision? Because we believed these claims.
- Why did we believe those claims? Because this evidence supported them.
- Is that evidence still true? Here is what we know now.
- Did the thing we shipped actually work? Here is what happened.

You will still ship the wrong thing sometimes. Customers will still
surprise you. Integrity means you can still see what you believed, why
you believed it, what you built because of it, and what reality did to
that belief.

## Why "integrity" — the word has dual meanings here.

A product needs both.

Structural integrity: it holds together under load.

Pull on a roadmap item and its reasoning is still attached. Trace a
decision backwards and you find the claims and evidence underneath. Trace
it forward and you see what shipped and what actually happened. Those
links hold through handoffs, reorganizations, plan changes, and time.

Intellectual integrity: the organization tells itself the truth.

A claim stays labeled as a claim until evidence moves it. Evidence is
carried with its standing — claimed, corroborated, unsupported or
contradicted. Weak signals do not harden into fact because they appeared
in enough decks. When reality contradicts the bet, the record changes.

Structural without intellectual: every decision is beautifully documented
and the reasoning is still wrong. Intellectual without structural: people
are honest and thoughtful, and six months later nobody can reconstruct
why anything happened. You need both.

## Where the tools stop

Product management tools have optimized the parts. Each tool tells you
something true about its slice of the process. Product integrity lives in
the gaps between those slices.

- A research repository tells you what customers said. Integrity
  requires knowing which decisions still depend on it, and at what
  standing.
- A roadmap tells you what the team intends to build. Integrity requires
  knowing why those items still deserve to be there.
- A delivery system tells you whether something shipped. Integrity
  requires knowing whether what shipped still represents the original
  bet.
- Analytics tell you what happened. Integrity requires knowing whether
  what happened changed what the organization believes.

## Three tests

For an important decision to have integrity, three things must be true.

1. The decision can be traced to the claims it depends on.

Pick something meaningful on the roadmap. You should be able to retrieve
the actual reasoning beneath it — retrieve, not remember. These are not
answers to "why is this here?": "Sarah wanted it." "The enterprise team
asked for it." "We discussed this last quarter."

2. The claims can be traced to evidence, and represented honestly.

A claim is not evidence merely because somebody wrote it down. The system
should preserve what supports a claim and how strongly. An assumption
still looks like an assumption. Limited evidence does not quietly become
corroborated. Contradicted claims do not survive on roadmap inertia.

3. The evidence is still current.

Evidence has a half-life. Customers change, markets change, competitors
move, usage changes, technology changes, the product changes. A decision
made from sound evidence six months ago can be a bad decision today. New
evidence can challenge old reasoning. Decisions depending on that
reasoning can be revisited.

## Check for yourself: follow one bet through the product.

The same team, the same evidence, the same feature, the same result. In
the first column the reasoning stays attached. In the second it does not.
Nothing in the second column is anyone's mistake — it is what happens by
default.

With product integrity, the reasoning stays attached:

- Claim: mid-market customers abandon onboarding because integration
  setup takes too long.
- Evidence: interviews repeatedly mention setup complexity. Analytics
  show a significant drop during integration configuration. Support
  tickets contain repeated requests for implementation help.
- Standing: corroborated, and recorded as exactly that.
- Decision: reduce the time required for customers to complete their
  first integration.
- Bet: guided integration setup, expected to increase successful
  onboarding and improve 30-day retention.
- Outcome: integration completion improves 18%. Retention barely moves.
- Reading: the solution worked. The original causal belief did not.
- Return: the evidence changes. The claim changes. The understanding of
  the problem changes. Eventually the strategy may change.

Without it, the same bet in a normal product stack:

- Research: integration setup is identified as the problem. A
  presentation summarizes the research.
- Roadmap: the research becomes an "onboarding improvements"
  initiative.
- Drift: three months later the initiative has become a guided setup
  wizard.
- Handoff: engineering receives requirements for the wizard, not the
  original evidence.
- Scope: scope changes during implementation. Nobody checks whether
  those changes affect the hypothesis.
- Ship: the wizard ships. The delivery ticket closes.
- Signal: analytics show more users completing integration. The team
  celebrates.
- Silence: retention remains unchanged. Nobody goes back to the original
  claim.
- Memory: six months later, somebody says "we already fixed onboarding."

The organization has accumulated information. It has lost the reasoning.

## Where it has to hold

Integrity is not a box you tick. It has to survive across the product
lifecycle — in five places, and then in a sixth that no single tool owns.

In each phase, what the team believes about customers and problems
remains attached to the evidence behind it. Claims are distinguishable
from assumptions. Contradictions remain visible. Weak signals do not
become facts through repetition.

And then there is the sixth: loop integrity.

Each phase can work well while the product as a whole loses integrity. A
team can conduct excellent discovery and build a roadmap unrelated to it.
Make a sound strategic decision and hand engineering requirements that no
longer reflect it. Execute beautifully and never check whether the thing
worked.

The damage happens in the seams: strategy to research, research to
decision, decision to roadmap, roadmap to delivery, delivery to outcome.
Loop integrity is whether the reasoning survives those handoffs.

No individual point tool can see that chain on its own. Most product
stacks were designed to manage artifacts. They were not designed to
preserve the relationships between them.

## The symptoms: how you notice it is broken.

None of these look like a crisis. That is what makes them expensive.

The roadmap has no visible reason behind it. Ask why an initiative exists
and you get a person's name, a meeting, or an old presentation instead of
evidence.

Research finishes and nothing changes. The study gets written up.
Insights get shared. Everyone agrees they are interesting. The roadmap
remains exactly the same.

Assumptions quietly become facts. Someone says "customers need this."
Three months later the roadmap says "customers need this." Six months
later the strategy says "our customers require this." Nobody can find the
evidence that originally justified the statement.

Strategy and roadmap silently diverge. Both are current. Both look
reasonable. They describe different companies.

Scope changes alter the bet. What engineering ships is materially
different from what discovery validated. Nobody notices, because the
requirement changed but the reasoning did not.

"Done" means shipped. The work reaches production. The ticket closes.
Nobody returns to ask whether the expected outcome occurred.

New evidence contradicts an old decision. The new evidence gets filed.
The old decision remains untouched.

The same decisions get re-litigated. Teams repeatedly reopen arguments
because the reasoning behind the original decision was never preserved
somewhere people can retrieve it.

Leadership changes and product memory disappears. A new leader arrives.
The organization remembers what it is building. It cannot explain why.

## What this is not

Product integrity adds almost no process. Product teams work under
uncertainty. They make bets. Some of those bets fail. That is the job.

Integrity keeps uncertainty from being dressed up as certainty, and keeps
the original reasoning available when reality forces an update.

It is not another stage gate or review ceremony. It does not force teams
to document every conversation. It does not chase a perfect single source
of truth. It does not require certainty before anyone can make a
decision. It does not try to stop people from being wrong.

It is knowing which claims are actually carrying a decision, preserving
why a bet was made so the organization can revisit it, and letting new
evidence change the organization's mind.

## The system: Shorter Loop is a Product Integrity System.

Most product software stores artifacts. We store the relationships
between them.

1. Evidence → claims. Evidence stays connected to the claims it
   supports.
2. Claims → decisions. Claims stay connected to the decisions that
   depend on them.
3. Decisions → bets. Decisions stay connected to roadmap bets.
4. Bets → work. Roadmap bets stay connected to the work that implements
   them.
5. Work → outcome. Delivered work stays connected to its intended
   outcome.
6. Outcome → belief. Outcomes return to the beliefs and strategy that
   created the bet in the first place.

That creates something most product organizations do not have today: a
living record of why the product is becoming what it is becoming.

So when new evidence appears, you can see what it challenges. When a
roadmap changes, you can see what reasoning changed with it. When
something ships, you can see what outcome it was supposed to create. And
when reality disagrees with the original bet, the learning can travel all
the way back through the system.

Product integrity does not make you right. It makes it harder to stay
wrong.

You will still make bad bets. Customers will still surprise you. Markets
will move. Experiments will fail. Assumptions will turn out to be false.
That is product development. The difference is whether the organization
learns from those failures, or simply piles the next roadmap on top of
them. Product integrity keeps the reasoning attached long enough for the
organization to learn.

## The ten-minute self-test

- Pick one committed roadmap item and name the decision behind it.
- Retrieve the claims that decision depends on — retrieve, not remember.
- Find the evidence beneath each claim and check whether it is still
  current.
- Wherever you cannot get to the next link, that is where integrity
  breaks.


================================================================
PAGE — THE PRODUCT FAILURE ONTOLOGY
https://shorterloop.com/failure-ontology
================================================================

## We named 52 ways product work can go wrong so your team doesn't have to keep re-discovering them.

They usually begin with a reasonable-sounding claim: "Users need this."
"This is our highest priority." "We know what to build." "We will know it
worked when we ship it."

This catalogue describes 52 recurring ways product reasoning breaks down,
and the warning signs those failures leave in briefs, PRDs, roadmaps,
research reports and backlog items.

52 failure modes. 9 clusters they corrupt. 260 published signatures.
Current edition v1.1.

## What a failure looks like in practice

A normal-looking brief can hide weak reasoning. A brief can identify a
user need, propose a solution, include an estimate and define success,
and still rest several of its claims on missing evidence, untested
assumptions or decisions made too early.

Worked example — a draft brief for a unified customer view. Leadership
has identified a clear need. Users are said to want a single place to see
everything about an account. The proposal is a consolidated account
dashboard surfacing activity, contract status, open tickets and health
score in one panel, estimated at six weeks. The stated rationale is that
the dashboard will drive better retention conversations. Success criteria
are that the dashboard ships to all customers by end of Q3, with positive
feedback from the account management team. Alternatives considered: none,
because the CRO has been clear that this is the priority for the half.

Five claims in the document. Eight modes across four of them, and one
claim that comes back clean:

- The unsupported user need — 1 mode.
- The solution commitment — 3 modes.
- The engineering estimate — clean.
- The untested assumption — 2 modes.
- Shipping mistaken for success — 2 modes.

A single claim can carry more than one failure. The solution claim
carries three, because committing without alternatives and committing on
authority are separate failures that arrived in the same sentence.

## How it's organised: failures are grouped by the decision they corrupt.

A product organisation makes six decisions, continuously, whether or not
it names them. Thirty-six of these modes sit under one of the six. Six
belong to the seams between them. The last ten aren't decisions at all —
they're conditions that every decision either has or lacks.

1. Which problem — failures in choosing what the team works on at all.
   9 modes.
2. Whose problem — failures in specifying who actually has it. 4 modes.
3. Whether it's worth solving — failures in sizing the bet against what
   being wrong costs. 3 modes.
4. Which solution — failures in choosing the approach. 13 modes.
5. Whether to continue — failures in stopping. 6 modes.
6. Whether it worked — failures in checking. 5 modes.

The seams — failures belonging to no single decision, where reasoning is
dropped in the handoff. 6 modes.

Authority — whether the person accountable is the person deciding. Cuts
across all six. 3 modes.

Legibility — whether the reasoning survives outside the head that had it.
Cuts across all six. 3 modes.

## The catalogue: all fifty-two

Which problem
1.1 Stakeholder Laundering
1.2 HiPPO-ism
1.3 The One Shouting Loudest Wins
1.4 My-Budget-My-Features
1.5 Bonus-Driven Innovation
1.6 Selling Vaporware Features
1.7 Backlog Black Hole
1.8 Everything Is Priority One
1.9 Lack of Product Vision

Whose problem
2.1 One-Dimensional Discovery
2.2 Would You Use This?
2.3 Proxy Data Syndrome
2.4 Persona-Driven Self-Fulfilling Prophecy

Whether it's worth solving
3.1 Financial Incentives Misalignment
3.2 Build It and They Will Come
3.3 Ignoring Technical Debt

Which solution
4.1 Micromanagement by PM
4.2 Confirmation-Biased Discovery
4.3 Cargo-Cult Discovery
4.4 Discovery Is Just Validation
4.5 Partial-Team Discovery
4.6 Big-Bang Discovery
4.7 Skipping Discovery in Crisis
4.8 Requirement Engineering Masquerading as Discovery
4.9 Hypotheses Without Engineers
4.10 Hidden Assumptions
4.11 We Know What to Build
4.12 Loving the Solution
4.13 I Know Better

Whether to continue
5.1 Annual Roadmap Trap
5.2 Incrementalism Trap
5.3 Sunk Cost Fallacy
5.4 Mid-Sprint Scope Creep
5.5 Waterfall in Sprints
5.6 Chain Sprinting

Whether it worked
6.1 Output Over Outcome
6.2 Velocity as KPI
6.3 Nobody Knows What Success Looks Like
6.4 Feature Factory
6.5 Post-hoc Success Metrics

The seams
7.1 Outsourced Discovery
7.2 Design as a Silo
7.3 Research as a Silo
7.4 No Shared Understanding
7.5 Sole Source of Truth
7.6 Ignoring Sales & Support

Authority
8.1 Proxy Product Owner
8.2 Inaccessible Product Owner
8.3 Egos at Work

Legibility
9.1 Pleasing Over Satisfying
9.2 No Transparency
9.3 Confusion Over Guidance

## Run it: see how the scanner reads a document.

The page carries a live scanner. It reads four sample documents, and
accepts an upload in .md, .txt, .docx or .pdf. For each it returns every
claim, the failure modes detected on it, the quote it read and the rule
that fired. No score anywhere.

Worked example — a shift handover brief, 940 words, from a dispatch
product team. Operations leadership raised handover as the top gap in the
quarterly review. Dispatchers are said to want one place to write up what
happened on a shift, using a shared spreadsheet nobody reads today. The
proposal is a structured handover form with incident tags, a free-text
log and an acknowledgement step on the receiving shift, sized at four
weeks. The rationale is a competitive window closing in Q3, with two
accounts evaluating alternatives that ship handover today. Success
criteria are that the form is live for every dispatch team by 30
September, with positive feedback from those two accounts. Alternatives
considered: none, because the VP Operations asked for the form
specifically.

Six claims. Five with findings, one clean, nine modes named.

- C1 "Dispatchers want one place to write up what happened on a shift" —
  1 mode: Stakeholder Laundering, deterministic. Rule: need asserted
  with no source, no named user and no research reference in the same
  section.
- C2 the proposed form — 3 modes.
- C3 "Engineering has sized this at four weeks" — clean.
- C4 the competitive window — 1 mode.
- C5 the success criteria — 2 modes.
- C6 "None. The VP Operations asked for the form specifically." — 2
  modes.

No score, no grade, no percentage — not on screen and not in the
response. A claim carrying three failures and a claim carrying one are
different problems.

17 of 52 modes are checkable from a document of this type. The scanner
checks only those. The remaining 35 need context that a single document
of this kind structurally cannot contain.


================================================================
PAGE — SAGE
https://shorterloop.com/sage
================================================================

## Your product organization already has enough opinions. Sage finds the ones worth betting on.

Sage turns every artifact in the system into claims and the evidence
behind them — what a customer said, what was decided, what an experiment
showed, what shipped. Then it keeps testing whether those claims still
hold as new information arrives, backing the bets that survive and
challenging the ones that stop holding, while they are still cheap to
change.

Grounded in your evidence. Auditable.

## A worked exchange: the refusal

In the FlowDesk demo workspace, a PM asks Sage to draft the opportunity
for OBJ-1. Sage declines:

"I can't draft this one yet. OBJ-1 has no evidence attached, and its
stated cause — onboarding is too hard — appears in the objective
description and nowhere else in your workspace. Drafting from that would
give you a well-formed opportunity resting on a single unsourced
sentence.

Three things would change that: 41 support items mentioning setup or
access, the 14 churn interviews in your February folder, or any sales
note that names the cause."

Zero sources. Declined.

## The state of play: you already have the evidence. It just isn't in the room when the decision gets made.

Interview transcripts, experiment results, support exports, KPIs and
strategy decks live in separate systems. So the meeting runs on whoever
argues best.

Roadmaps running on faith. Assumptions harden into commitments. Nobody
goes back to check whether the evidence that justified them still exists,
or ever did.

Knowledge that gets uploaded and forgotten. Research lands somewhere,
gets read once, and never connects to the artifact it was supposed to
inform. The next decision starts from zero.

AI that bluffs when the evidence runs out. When retrieval fails or
support is thin, most assistants still write fluently. You need the
opposite: a visible gap, disclosed.

## A different starting point: most AI starts with a prompt. Sage starts with evidence.

Ask a typical AI "should we build this?" and it will probably give you an
answer.

Sage has a harder job. It has to find the evidence behind the idea,
determine whether that evidence is current, separate assumptions from
corroborated claims, look for contradictions, understand what other
artifacts depend on the decision, and tell you when the evidence simply is
not strong enough.

Because a plausible answer isn't necessarily a good decision.

## How Sage works: retrieval finds documents. Sage builds an evidence system.

1. Ingest — it reads what your organization knows.

Interviews, surveys, support exports, strategy documents, spreadsheets
and product artifacts are broken into statements, claims and evidence.
Nothing arrives pre-trusted.

2. Connect — it remembers what supports what.

Sage maintains semantic retrieval and a product knowledge graph
connecting evidence to personas, opportunities, solutions, experiments,
KPIs, epics and roadmaps.

3. Reason — it reasons over the evidence.

Sage can search the corpus, inspect the graph, analyze evidence, compare
alternatives, detect patterns and use specialized product-management
skills before it constructs an answer.

4. Watch — it keeps looking when you aren't asking.

The background analyst sweeps for contradicted assumptions, untested
claims, orphaned evidence, stale commitments, decayed confidence and
conflicting solutions.

5. Remember — it keeps what you worked out last time.

Finished questions and answers go back into the corpus. The reasoning
your team did in March is retrievable evidence in September. It stops
being a scrollback nobody can find.

## Ask harder questions

Questions product leaders actually need answered:

"Which roadmap bets are resting on assumptions rather than evidence?"
Inspect the evidence behind each commitment. A roadmap is a set of
claims, not a list.

"What do we believe that our own research contradicts?" Surface
contradictions that are easy to miss when knowledge is spread across
documents and teams.

"What important decisions are relying on stale evidence?" Account for
freshness and supersession. A two-year-old interview does not vote like
this quarter's.

"What are we treating as validated that actually isn't?" Distinguish what
has merely been claimed from what has actually been corroborated.

"Why do we believe this opportunity matters?" Trace backward from the
artifact to the accepted evidence behind it.

"We shipped it. The KPI moved. Did we actually cause it?" Inspect related
changes and confounders before claiming impact.

## Productive friction: an AI that is allowed to disagree with you.

Most product software helps work move forward. That creates a dangerous
bias: everything eventually becomes a thing to build.

Sage creates friction when the evidence does not justify confidence. The
goal is to make being wrong cheaper. It surfaces assumptions masquerading
as facts, contradictory customer evidence, opportunities with weak
support, commitments whose evidence has gone stale, solutions that
conflict with one another, and conclusions that outrun what the
organization actually knows.

## Evidence state: it can tell the difference between "we know" and "we think."

Evidence state travels with the claim all the way into the reasoning. It
does not get flattened into context for a language model.

Claimed — someone has said it. The assertion exists in the corpus.

Unsupported — the evidence is not there. The claim exists, but accepted
evidence does not support it.

Corroborated — the evidence supports it. Accepted evidence provides
corroboration.

Contradicted — your own evidence challenges it. Accepted evidence points
in the other direction.

## Uncertainty, surfaced: when Sage doesn't know, that matters too.

Confidence should come from evidence, not from how confidently a model
writes.

Sage distinguishes grounded, degraded and exploratory reasoning. If
required evidence infrastructure is unavailable, it downgrades the turn
and says so.

Grounded — evidence retrieval succeeded.
Degraded — a required capability failed, and this is disclosed.
Exploratory — reasoning extends beyond firm evidence, and is marked.

## For whoever owns the roadmap: what actually changes for you.

Product judgment stays yours. Sage removes the option of quietly not
exercising it.

You can defend the claim in the room. Answers carry their evidence state
and are checked assertion by assertion against what retrieval actually
returned. You can take the output into a board review without wondering
which supporting detail the model invented.

Integrity debt shows up early. Contradictions, untested bets and decaying
confidence surface on a schedule. By the post-mortem they're free to find
and expensive to have missed.

Institutional memory stops leaking. Every answered question becomes
retrievable context. Turnover costs you people, not the reasoning they
did.

Confidence becomes explicit. When evidence is thin or a capability is
down, Sage says so and marks the turn. You are never left assuming an
answer was grounded when it wasn't.

## For the technically curious: each part of Sage has one job.

Different parts of Sage handle routing, retrieval, graph reasoning,
document analysis, verification and continuous integrity monitoring.

35 in-process PM skills. 17 governed MCP skills. 18 routing intent
categories. 10 NLP task types. 3 grounding states. 6 integrity insight
classes.

Reasoning engine. Agentic ReAct tool use over corpus search, graph
lookup, evidence analysis, pattern detection, comparison and
artifact-generation skills. A self-critic re-runs synthesis when an
answer hedges or outruns its support, and a deterministic assertion
verifier decomposes the answer into structured statements and checks each
one against what retrieval actually returned. Runs stream step by step,
so you watch the reasoning rather than a spinner.

Knowledge architecture. Tenant-scoped semantic retrieval in Qdrant plus a
Neo4j product graph connecting evidence and product artifacts. Artifact
changes dual-write to both stores in one run across 19 entity handlers,
each carrying its claim state at write time. Similarity scoring after the
write links related artifacts automatically, and causal attribution
chains record whether a metric moved because of what you shipped.

Document intelligence. Documents are classified, freshness-checked and
atomized into statements and atomic claims carrying polarity, modality,
quantifiers and scope. Duplicate, low-integrity, superseded or
off-taxonomy material can be halted at any stage, with the reason
recorded. Recency decay and supersession detection keep an old deck from
carrying a fresh deck's weight.

Continuous integrity analysis. An always-on background analyst sweeps
every active workspace for contradicted assumptions, untested claims,
orphaned evidence, stale commitments, decayed confidence and conflicting
solutions. Each class runs an isolated query, so one failure never breaks
the sweep, and findings are ranked high, medium or low. No language model
sits in the synthesis path, so the results are deterministic,
reproducible and cheap to regenerate.

Model routing and evaluation. A compact fine-tuned router plans the right
skill sequence. The stack includes confidence calibration from token
logprobs, RLAIF evaluation and a Sage-Bench quality gate against the live
reasoning endpoint.

## Trust architecture: your evidence stays yours.

Isolation at the data layer. Per-workspace vector collections and a
tenant-aware graph. Scope is enforced server-side and stripped from
anything the model supplies.

Injection defenses. Customer-sourced text is handled as untrusted data. A
tool result cannot quietly rewrite Sage's instructions.

Evidence state, not model opinion. Claimed, unsupported, corroborated and
contradicted are derived strictly from accepted evidence links. Model
opinion never sets the state.

Metering you can see. Per-workspace rate limits and usage tracking, so
cost and behavior stay observable.


================================================================
OTHER PAGES
================================================================

- https://shorterloop.com/product-management — the six decisions the job
  turns on
- https://shorterloop.com/org-chart — where the same failures are built
  into the org chart
- https://shorterloop.com/capabilities/strategize — themes, objectives,
  key results
- https://shorterloop.com/capabilities/discover — opportunities,
  personas, assumptions, experiments
- https://shorterloop.com/capabilities/roadmap — roadmaps where every
  item names its objective and evidence
- https://shorterloop.com/capabilities/deliver — backlog, prioritisation,
  releases, two-way Jira sync
- https://shorterloop.com/capabilities/feedback — feedback portals,
  clustering, ideas and pain points
- https://shorterloop.com/capabilities/collaboration — documentation and
  whiteboards
- https://shorterloop.com/capabilities/integrations — connectors, REST
  API and webhooks
- https://shorterloop.com/pricing — per product, unlimited seats, one
  published price
- https://shorterloop.com/compare — an honest read on where Shorter Loop
  fits and where it doesn't
- https://shorterloop.com/about-us — the team
- https://shorterloop.com/labs — free tools
- https://shorterloop.com/blog — The Product Mindset
- https://shorterloop.com/white-papers
- https://shorterloop.com/guides
- https://shorterloop.com/security