Revenue and the Needle

Torno connects Stripe read-only, normalizes billing events into MRR you can decompose, and assembles the Needle: one view of the target Metric, what is moving it, and everything currently aimed at it.

The Stripe connection

A Stripe connection is read-only and scoped to a Property and environment. You connect through OAuth; a backfill pulls history while webhooks stream new events, and both converge in idempotent event storage where out-of-order arrivals reconcile instead of corrupting state. Connection health, webhook and backfill lag, failures, retries, and reconciliation status all stay visible in the product.

From Stripe events to MRR movements

Normalization turns raw Stripe events into MRR movements and snapshots, covering new, expansion, contraction, churn, resume, pause, trials, proration, and subscription schedules, with a reporting currency converted at pinned FX rates. Refunds and disputes stay separately visible; they never silently rewrite MRR. The movement decomposition must reconcile to the period delta, and a mismatch is flagged rather than smoothed over.

Revenue meets Experiments

A Subject key carried in Stripe metadata joins paying Customers to Experiment arms. The join is cohort-grade: per-arm revenue reads are k-gated like every other aggregate in Torno, and payments with missing or invalid metadata land in an explicit unattributable bucket instead of being guessed into an arm. See Identity and privacy for how the Subject key travels.

One definition of MRR

MRR is defined once, in the semantic layer, as a revenue-class Metric with versioned definitions and a declared decomposition. Revenue supplies data to that Metric; it does not run a second calculator, so the MRR on the Needle equals the MRR read anywhere else. And because revenue moves slowly, a revenue-class target must pair with a leading-indicator Metric — the steering number you can watch week to week.

The Needle

The Needle is a composition, not a second metric engine. It assembles, from parts that already exist elsewhere in Torno:

• the target Metric’s value, trend, freshness, and source basis, in the standard read envelope;
• its decomposition into new, expansion, contraction, and churn;
• the paired leading indicator;
• every relevant Loop and live Change aimed at the target, including warnings for Changes that are unmeasurable because they defined no exposure;
• Experiment evidence states, with guardrail and integrity status;
• bounded contribution estimates — ranges tied to evidence, never causal certainty.

Empty states are explicit: no Stripe connection, no target set, no data yet, and no live Changes each say so plainly rather than rendering an optimistic blank chart.

The same composition feeds the Property home, the dedicated Needle page, the Loop board, the API, MCP, and the CLI:

torno revenue needle   # the Needle, in a terminal
torno loop status      # the same composition, Loop-first

What agents cannot do

Agents can read revenue, cite it in proposals, and track pricing work as Changes. They do not mutate live Stripe prices. Anything that changes what a Customer is billed stays a human action, consistent with Policy and approvals.

Honest notes

The Stripe integration’s verification state is visible in the product; Torno does not claim live end-to-end Stripe proof beyond what your connection screen shows. Contribution estimates on the Needle are bounded ranges tied to Experiment evidence — when the honest answer is a wide range, the Needle shows a wide range.