KPI Tree, Metric Dictionary, and Pipeline Model — Ramp Router (2026-08-20)

Phase 3 — Company-Specific Proof. This document runs the mechanism defined in 01_OS_Architecture/05_enablement-and-pipeline.md, Area 2 (Pipeline and Measurement), against a real, dated launch: Ramp Router, Ramp's AI model-routing product, launched 2026-08-20. It does not redesign the mechanism — the KPI-tree method, metric-dictionary format, and signal-to-action table are fixed by Module 05 and applied here as-is. What changes is the input: a real company, a real launch, real public facts.

Claim-status vocabulary (per CHARTER.md, used exactly as labeled below): Publicly verified · Reasoned hypothesis · Internal input required · Illustrative output · Workflow tested · Live in operating system · Prototype · Requires integration.

The Jerry-add test (D-024) governs every section below. Each section opens with an OBSERVED block (what is merely true about Ramp, cited) and closes with an OS CONTRIBUTES block (what the operating system does with that input — the actual deliverable). Do not read the OBSERVED blocks as the content of this document; they are the input data. The tree, the dictionary, the thresholds, and the reasoning are the output.

Timing honesty, stated up front: Module 05's own decision logic requires a KPI tree to be built at launch kickoff, not after — building it retroactively collapses into "retroactive storytelling" (a named failure mode in that doc). This document is being built ~15 days after Router's actual launch (2026-08-20 → today, 2026-09-04), by an operator with no access to Ramp's internal systems. It is therefore explicitly run as a kickoff simulation: the tree below uses only what was publicly knowable at or before the 2026-08-20 launch date (the product's own mechanics — free-through-2026 pricing, no-account-required signup, U.S.-only launch, model-provider mix) to demonstrate what the OS would have produced before results existed, not an after-the-fact fit to outcomes Ramp has since claimed. Where Ramp's own post-launch marketing claims (e.g. "40% average savings") are used, they are treated as input the tree must validate, not as evidence the tree already worked — see Section 5.

1. Anchor facts — what Router is (OBSERVED)

[Publicly verified — TechCrunch, 2026-08-20, https://techcrunch.com/2026/08/20/ramp-launches-its-own-ai-model-router-called-router/; corroborated by PRNewswire, https://www.prnewswire.com/news-releases/ramp-launches-routercom-to-cut-companies-rising-ai-bills-302855572.html; scorecard.md §Candidate 2, criterion 1] Ramp launched Router (router.com) on 2026-08-19/20: a single API endpoint, compatible with the OpenAI and Anthropic SDKs, that routes each inference request to the lowest-cost model meeting a developer-set quality bar. Ramp says it ran this routing technology internally for three years before releasing it as a standalone public product.

[Publicly verified — TechCrunch, PRNewswire, Unite.AI coverage, cross-checked via search 2026-09-04] Key launch mechanics, all load-bearing for the tree below: - No Ramp card or company account required to use Router. It is decoupled from Ramp's core spend-management product at signup — a self-serve, developer-led motion, not the enterprise/ABM motion that defines the rest of Ramp's business. - Free routing through 2026-12-31; users pay only underlying model-inference (token) costs, with a $26 signup credit. No Router-specific price list exists yet for 2027 onward. - U.S.-only at launch; enterprise features and additional geographies are stated as "coming soon" — i.e., Ramp itself has flagged this as an incomplete, expanding surface, not a finished product. - Model coverage at launch: OpenAI, Anthropic, and xAI, with Gemini "coming soon," plus open-weight models (DeepSeek, Moonshot/Kimi, MiniMax, Z.ai/GLM, Qwen) served through providers such as Fireworks AI. - Ramp's own marketing claims 40% average inference-cost savings among customers already using the underlying routing tech, with one named customer (Valentin De Matos of Delphi, quoted in Ramp's release coverage) cited at 92% — self-reported, press-relayed figures, not independently audited. [Publicly verified that Ramp made this claim; the underlying 40%/92% figures themselves are Reasoned-hypothesis-grade at best — no denominator, cohort definition, or measurement window is disclosed] - Data handling: Router records model inputs, outputs and tool calls for one year by default, with PII removed before use (per Ramp, as reported by TechCrunch 2026-08-20); router.com states users "can control some of" these settings and can select U.S.-hosted models with zero data retention — no explicit opt-out mechanism is published in either primary source (router.com fetched 2026-09-06).

[Publicly verified — scorecard.md §Candidate 2] Context on the parent company: Ramp closed a $750M Series F on 2026-06-04 at a $44B valuation (ICONIQ, GIC, Ontario Teachers'); Router launched roughly 11 weeks later. Ramp's core ICP is finance/ops leaders at growth-stage and enterprise companies; its named competitive set is Brex, Airbase, Navan, Expensify; G2 shows 4.8/5 across 600–2,452 reviews depending on the aggregation page cited.

OS CONTRIBUTES (what this section is for, not just what it says): The single most consequential fact above, for measurement design, is the decoupling of Router's signup from Ramp's core account — the OS reads this as a structural signal that dictates the whole shape of the tree in Section 2. A launch inside Ramp's existing enterprise motion would decompose as an account-based tree (target accounts engaged → opportunities → pipeline → closed-won, per Module 05's own stated alternative). Router's self-serve, no-account, developer-facing mechanics mean that tree is the wrong instrument here — the OS has to build the PLG-decomposition Module 05 names as the alternative, and it has to do so because of a specific, cited product-mechanics fact, not by default. That is a decision, not a restatement — Ramp's own launch coverage does not frame Router in KPI-tree terms at all.

2. Motion-type decision (OS CONTRIBUTES)

Decision: Router is scored as a self-serve/PLG motion with a secondary enterprise cross-sell branch back into Ramp's core account, not a bookings-led enterprise motion. Reasoning, applied to the specific facts in Section 1:

1. No Ramp account or card is required to sign up — the funnel entry point is a developer, not a procurement process. A bookings-first tree (MQL → SQL → opportunity → closed-won) has no natural entry event here; there is no "opportunity" object created at signup.
2. There is no current price for Router itself (free through 2026-12-31) — so "closed-won revenue" cannot be the top metric for this measurement era. A tree that forces a revenue top-line onto a free product either sits at zero all quarter (useless as a signal) or gets gamed by counting inference-token spend that Ramp doesn't monetize (misleading as a signal). This is the specific failure Module 05 names generically ("treating a coverage-ratio benchmark as a fixed rule instead of calibrating it") — here it shows up as treating a bookings-shaped tree as a fixed template instead of calibrating it to a not-yet-monetized product.
3. Because Router sits inside a company whose core business (spend management, corporate cards) is enterprise-sold, and because Router's own tagline ties it explicitly to "cutting AI bills" — Ramp's core value proposition domain — a cross-sell path back into the enterprise motion is a reasonable secondary branch, not a separate unrelated product. This is stated as [Reasoned hypothesis]: Ramp has not publicly stated a cross-sell strategy for Router into its core card/bill-pay product; the OS infers it from positioning language and product adjacency, and flags it explicitly as an inference, not a confirmed Ramp strategy.

Two measurement eras, both required by the free-through-2026 pricing fact: - Era 1 (now → 2026-12-31, "free/growth era"): top metric is a leading proxy for future value, not revenue. - Era 2 (2027 onward, "monetization era," date TBD): top metric becomes an actual revenue/margin metric once Ramp sets Router pricing. The tree below is built for Era 1 and names the trigger that forces a rebuild for Era 2 (Section 6, Update trigger) — consistent with Module 05's own rule that the tree is fixed for a motion's duration and re-baselined only when the motion itself changes, which a pricing change explicitly would be.

This two-era design, forced by a specific disclosed fact (free-through-2026), is itself an OS output — it is the kind of structuring decision a generic "track adoption and revenue" instruction would skip past entirely.

3. KPI tree — Era 1 (Illustrative output / Reasoned hypothesis)

Everything below this line is Illustrative output. No real Ramp CRM, product-analytics, or usage data was accessed. Node names, decomposition logic, and structure are the OS's actual contribution; specific numeric plan values are placeholders marked [ILLUSTRATIVE] to show what a populated tree looks like — they are not claims about Ramp's real numbers and must not be read as such.

Top metric — Era 1

Qualified Routed Volume (QRV) — production requests routed during week W by the accounts in the Sustained-Use population for that week, SU(W) (defined in the dictionary below; membership is decided from the three weeks before W, so it is knowable before W's traffic exists). QRV(W) is computed directly from request records as a sum over those accounts, never from rates. Used as the leading proxy for (a) future monetizable usage once Era 2 pricing exists, and (b) cross-sell pipeline into Ramp's core account. QRV is deliberately not total routed volume — a tree that counted all traffic, including one-time signups chasing the $26 credit, would reward vanity volume instead of durable usage, the same trap Module 05's Area 1 evidence names for enablement downloads vs. actual use.

Driver decomposition

QRV (Qualified Routed Volume, weekly)
│
├── DEFINITION — QRV(W) = Σ production requests in week W, over accounts a ∈ SU(W)
│     (a flow over the week, from a population that accumulates across every cohort
│      that ever qualified and is still routing; summed from routing logs)
│
├── BRANCH A — Cohort forecast F(c, W), one signup cohort c, for W ≥ c + 4 (multiplicative)
│     Signups(c)
│       × Activation Rate(c) (API key created + ≥1 production request within 7 days)
│       × Sustained-Use Rate(c) (present in each of weeks 2, 3 and 4 after activation, no gap week)
│       × Retention(c, W) (share of c's qualified accounts still in SU(W))
│       × Avg Weekly Routed Volume per account of c in SU(W)
│     = F(c, W)           Σ over cohorts c ≤ W − 4 of F(c, W) is reconciled AGAINST QRV(W); it never defines it
│
├── BRANCH B — Cross-Sell Pipeline (secondary, additive to Branch A, feeds enterprise motion)
│     Sustained-Use Accounts
│       × Ramp-Account-Link Rate (% that create/link a core Ramp company account)
│       × Avg Influenced Pipeline Value per linked account
│     = Router-Influenced Pipeline (feeds Module 05 Area 2's enterprise tree, not QRV itself)
│
└── BRANCH C — Habit/Retention health (diagnostic, not multiplied into QRV)
      Week-4 Retention %
      Weekly Active Developers (WAD)
      Requests per Active API Key

[ILLUSTRATIVE] plan-shape example (structure only — real plan numbers are Internal input required): New Signups 1,000/wk → Activation Rate 45% (450 activated) → Sustained-Use Rate 30% of activated (135 qualified) → Retention 100% in the week shown → Avg 8,000 requests/wk per account → F(c, W) ≈ 1.08M requests/wk for that one cohort, from its fifth week onward. That is one cohort's forecast contribution, not QRV: QRV(W) also carries every earlier cohort still routing, and this week's signups contribute zero to it because no account can clear a week-4 bar in its first week. These numbers are invented to show the arithmetic works, not to claim anything about Router's real traffic. (Correction of record, D-067 item 4: the first version of this document gave the four-factor chain as QRV's formula. It is a single-cohort forecast; the definition above and the executable tests in 05_Metric_Tests/ are the version that holds.)

OS CONTRIBUTES: The tree's shape — three branches, one multiplicative growth engine, one cross-sell offshoot, one diagnostic-only branch that is deliberately not multiplied into the top metric — is the actual design decision. Branch C exists because a tree that only reports the multiplied output can look healthy on paper while retention quietly rots (rising signups masking falling Week-4 retention); Module 05's failure-modes list names exactly this class of blind spot ("under-triggering on a slow structural decline that never crosses a single sharp threshold"). Keeping retention as a visible, non-multiplied diagnostic line is the OS's answer to that named risk, applied to this specific tree.

4. Metric dictionary (Illustrative output / Reasoned hypothesis)

Per Module 05's required format: metric name, one-sentence definition, exact source field/query, owner, update cadence. Source fields are illustrative (named as if a product-analytics tool like Amplitude/Mixpanel plus Ramp's internal CRM existed) — the actual schema is [Internal input required].

OS CONTRIBUTES: The dictionary's real function is not the definitions themselves but the precision they force — specifically the "no gap week" clause in Sustained-Use Rate and the explicit exclusion of one-time signups from QRV. Without that clause, two people could both report "Sustained-Use Rate" and mean different things (one counting any-4-of-4-weeks-active, one requiring consecutive weeks) — exactly the dictionary-drift failure Module 05 names as the single most common cause of dashboard distrust. Fixing that clause here, before any dashboard exists, is the OS's actual output; Ramp's own launch materials make no claim about a "sustained use" cohort at all. The definitions are executable: 05_Metric_Tests/METRIC_DEFINITIONS.md states each one, and 05_Metric_Tests/test_metrics.py (12 assertions on a labeled synthetic dataset with six cohorts, churn, reactivation and a censored final week) proves QRV equals the direct sum, that a single cohort's forecast diverges from it, that this week's signups contribute zero, and that the savings metric computes as defined.

5. Signal-to-action table (Illustrative output / Reasoned hypothesis)

Thresholds below are starting points for calibration, not claims about Ramp's real performance — Module 05 is explicit that fixed benchmarks without a real historical baseline produce false confidence or false alarms, and Router is 15 days old with no public baseline to calibrate against. Each threshold is marked [ILLUSTRATIVE].

OS CONTRIBUTES: Signal #7 is the clearest single instance of the Jerry-add test in this document. Ramp's own marketing already states "40% average savings" — repeating that number is the failure mode the Jerry-add test exists to catch. What the OS adds is refusing to treat a self-reported, undefined-cohort marketing figure as a trustworthy internal metric until it reconciles against the dictionary's own precise definition — a specific, actionable skepticism check, not a restatement of Ramp's press release.

6. Validation, update trigger, and human owners (Reasoned hypothesis)

Validation. Per Module 05: the tree is validated by reconciliation, not by a separate test: QRV is summed from routing logs, the forecast F(c, W) is summed over cohorts and compared against it, and the gap is the forecast error. A single cohort's chain is expected not to equal QRV, and the tests assert that it does not. At day 15 post-launch, this cannot yet be run — there is no live data access. The correct validation step right now, honestly, is: (a) confirm the dictionary's definitions survive a sanity check with whoever would manually pull these numbers (a real person reading "Sustained-Use Rate" and computing the same number the query would), and (b) hold signal thresholds as provisional until at least one full 4-week cohort exists to backtest against. [Internal input required] for the actual reconciliation and backtest; both are currently blocked on live access Ramp has not (and would have no reason to have) granted.

Update trigger. Re-baseline this tree: at the Era-1 → Era-2 transition (Router pricing announcement, expected on or before 2026-12-31 per the stated free period); immediately if Router's signup mechanics change (e.g., a Ramp-account requirement is added, which would collapse Branch A/B's separation); and on the fixed quarterly cadence Module 05 sets for signal-threshold re-tuning, using the most recent trailing cohort data once it exists.

Human owners (illustrative role titles, not Ramp's actual org chart — [Reasoned hypothesis]): A PMM lead for Router (or Ramp's AI/platform product line) owns the tree and dictionary, co-owned with RevOps/Growth Analytics for CRM-and-product-analytics data-source integrity — mirroring Module 05's general PMM/RevOps split. DevRel owns the Activation-Rate response (signal #1) since that failure mode is a developer-experience problem, not a sales one. Sales/Success only enters at signal #3 (large-account stall) and signal #4 (cross-sell), because Router's motion is self-serve by design — most signals in this tree have no natural sales owner, which is itself a structural fact about this specific launch, not a generic PMM statement.

7. Self-check against the Jerry-add test (D-024)

Required by CHARTER.md before this deliverable is treated as done. Per-section accounting:

Result: passes. No section restates what Router does or what Ramp's press release says as its content — each closes on a structural, definitional, or judgment output that required the input facts but is not reducible to them. The one place genuine risk existed (Section 1, reciting launch facts) is resolved by Section 1's own OS-CONTRIBUTES close and by Signal #7 treating those facts with explicit skepticism rather than accepting them.

Honest limitation, stated rather than hidden: every numeric threshold and plan value in this document is invented to demonstrate mechanism, not measured. That is the correct and disclosed state for a Prototype-status deliverable per Module 05's own Current Status line ("no real launch has been measured through this design yet") — this document does not change that status; it demonstrates the mechanism runs against a real, dated, cited case, which is what Phase 3 asked for.

Sources: TechCrunch, 2026-08-20 · PRNewswire, 2026-08-19 · Unite.AI · 02_Company_Selection/scorecard.md (Ramp candidate section, Phase 2, 2026-09-04) · 01_OS_Architecture/05_enablement-and-pipeline.md (mechanism run against this case) · 05_Metric_Tests/METRIC_DEFINITIONS.md and 05_Metric_Tests/test_metrics.py (definitions of record and executable tests, JOS-32).