Executive Launch Brief & Workback Plan — Ramp "Router" (AI Model Routing) Launch

Test case: Ramp, AI Router launch, 2026-08-20. Phase: JOS-25 Phase 3 — Company-Specific Proof, Launch Strategy module (01_OS_Architecture/03_pricing-and-launch.md, Area 2, plus the Area 1/Area 2 handoff). Author role simulated: Jerry as Senior/Director PMM responsible for this launch, operating Jerry's PMM OS. Built: 2026-09-04. Claim-status vocabulary used throughout, exactly as defined in CHARTER.md: Publicly verified · Reasoned hypothesis · Internal input required · Illustrative output · Workflow tested · Live in operating system · Prototype · Requires integration.

Prior-phase sources cited, not re-derived: company facts and the launch's existence are drawn from 02_Company_Selection/scorecard.md (Ramp candidate section, 95/100) and fresh 2026-09-04 research below. The launch mechanism being run here — tiering heuristic, sequencing gate, output artifacts — is 01_OS_Architecture/03_pricing-and-launch.md, Area 2, unmodified. Nothing in that module doc was redesigned for this exercise; it was run.

How to read this document (the Jerry-add test, applied to itself)

Per D-024 and the charter's Jerry-add test, every section below is split into two visibly separate parts:

• OBSERVED — facts about Ramp and the Router launch that are true regardless of who's looking at them. This is the OS's input data. It is kept deliberately short in every section, is fully cited, and is never the point of the section.
• OS CONTRIBUTES — what Jerry's PMM operating system does with that input: the tiering call and its reasoning, the internal inputs it names as missing and refuses to guess at, the workback gates and named owners, the go/no-go brief, the validation pass against the module's own failure modes, and the measurement plan. This is the actual deliverable.

The exercise treats the launch as already having happened publicly (2026-08-20, ~2 weeks before this document). The question this document answers is not "what will Ramp do" — it's "how would Jerry's OS have tiered, sequenced, and worked back from this launch, and where does its own logic say it must stop and wait for information only Ramp's internal teams have." Most workback specifics below are Reasoned hypothesis or Illustrative output, per the assignment — this document does not have, and does not claim to have, Ramp's real internal calendar, readiness status, or org chart.

Section 1 — OBSERVED: The Public Record

(Input data only. Every line here is cited. None of it is the deliverable.)

Company context — Publicly verified, per 02_Company_Selection/scorecard.md, Ramp candidate section: - $750M Series F closed 2026-06-04 at a $44B valuation (ICONIQ Capital, GIC, Ontario Teachers' Pension Plan co-leading), reported by TechCrunch, SiliconANGLE, PRNewswire. - "Ramp Stack," an AI accounting-automation product, launched alongside that raise. - G2 rating 4.8/5 across 600–2,452 reviews depending on the aggregate page counted.

The launch itself — Publicly verified, per WebSearch results 2026-09-04 (TechCrunch, PRNewswire, Benzinga, and secondary pickup at Cryptonomist, ITBrief, SQ Magazine, AI Industry Today, TechBuzz.ai, CryptBull, E‑Ink News Daily; original TechCrunch/PRNewswire/Benzinga pages could not be fetched directly in this session — outbound fetches to news domains are blocked by this environment's egress proxy, so facts below were drawn from WebSearch's synthesis of those sources rather than primary-document quotation; superseded 2026-09-06 where an entry cites a direct fetch or Stripe's / Palo Alto Networks' own releases): - Ramp launched "Router" on 2026-08-20 — a multi-model AI API/routing product that lets a business call OpenAI, Anthropic, DeepSeek, Moonshot, Minimax, Nvidia, xAI, and Z.ai models through one API/bill, with each request routed to the lowest-cost model meeting a required performance bar. - Pricing/packaging as launched: free through the rest of 2026 plus a $26 launch credit; customers still pay underlying model-inference cost; US-only at launch; a one-year default retention window on inputs/outputs/tool calls (TechCrunch 2026-08-20); no explicit opt-out mechanism is published — router.com says users "can control some of" these settings and offers zero-data-retention U.S.-hosted models (corrected 2026-09-06). - Ramp's own claim: the routing technology was used internally for three years before public release, and Ramp reports its own inference costs fell roughly 30% internally while holding reliability above 99.9% across production traffic. Customers already on Router are reported to have cut inference costs ~40% on average. - Coverage framing: Benzinga's headline was "Ramp Takes a Shot at OpenRouter With New AI Service" — direct competitive framing against the category leader.

Competitive landscape — Publicly verified / Reasoned hypothesis (market-sizing figures are third-party estimates, not disclosed), per WebSearch 2026-09-04: - Named competitors: OpenRouter (unified gateway; "400+ models from more than 80 providers" per Stripe's 2026-08-19 acquisition announcement; $113M Series B at a $1.3B valuation, 2026-05-26, led by CapitalG), Portkey (observability/DevOps-focused; acquisition by Palo Alto Networks announced 2026-04-30 and completed 2026-05-29, per Palo Alto Networks' own releases), Martian (cost-optimization routing via a dedicated small prediction model). - (Removed 2026-09-06 by the Material Claim Verification Gate: a "97.8% of tracked category capital" figure with no named source could not be verified and carried false precision. The verified funding fact is OpenRouter's $113M Series B above.)

Reception in the first two weeks — Reasoned hypothesis (press synthesis, not a verified survey), per WebSearch 2026-09-04: - Skepticism centers on two things: (1) the one-year default data-retention window, flagged explicitly as a trust concern; (2) whether enterprise customers will route mission-critical AI traffic through a fintech's infrastructure — commentary notes Ramp's core-product enterprise trust may transfer via halo effect, but this is untested for this specific product category. - No public reporting found (as of 2026-09-04) on revenue attributable to Router, adoption volume beyond the "customers already report ~40% savings" claim, or any support/incident issues.

Section 2 — OS CONTRIBUTES: Launch Tiering Recommendation

Applying 03_pricing-and-launch.md's tiering heuristic (novelty to the market, competitive urgency, customer-facing behavior change, revenue/positioning significance — scored against confirmed internal readiness, never assumed readiness) to this specific launch.

Novelty — split into two readings the module's heuristic doesn't distinguish by default, and the OS should: - Novelty to the market: Low-to-medium. Multi-model LLM routing is an existing, funded category (OpenRouter, Portkey, Martian). Router is a fast-follower on category, not a category creator. Reasoned hypothesis. - Novelty to Ramp's own narrative: High. Ramp is a spend-management/fintech company entering an AI-infrastructure product category for the first time — this is the more market-moving fact for Ramp specifically, and it's the reading that should drive the tiering score, not the category-level novelty. Reasoned hypothesis — this distinction is the OS's contribution; the module's written heuristic as drafted would have scored this launch on category novelty alone and under-called it.

Competitive urgency — High. Category consolidation is already underway (Portkey's May 2026 acquisition by Palo Alto Networks) and the incumbent (OpenRouter) is well-capitalized ($113M Series B at a $1.3B valuation, 2026-05-26). A later entry would face a more entrenched leader and less differentiation room. Reasoned hypothesis, built on Publicly verified funding/M&A facts above.

Customer-facing behavior change — High. This asks existing Ramp customers to route production AI traffic through Ramp for the first time — a materially different ask than a card or bill-pay feature. Reasoned hypothesis.

Revenue/positioning significance — Positioning: high. Revenue: currently near-zero by design (free through 2026, inference cost pass-through only, no platform markup disclosed). This is a land-grab/positioning play, not a monetization launch, as of the public pricing terms. Reasoned hypothesis, drawn from the Publicly verified pricing terms.

OS tiering call: MAJOR — conditional. On the four market-facing dimensions above, this clears the module's bar for a major launch (novelty-to-narrative, competitive urgency, and behavior change are all high; positioning significance is high even though revenue significance is deliberately near-zero). Per the module's own rule, a major classification requires confirmed — not assumed — readiness across eng/sales/support, and none of the following is publicly knowable, so the OS marks the tier "major, pending confirmation" rather than a clean "major":

Internal input required to finalize this tier (cannot be inferred from any public source, and the OS will not guess): - Real confidence level from Ramp engineering leadership on Router's production stability at the scale a major launch drives (the "3 years internal use" claim is a public relations claim about readiness, not a readiness confirmation the OS can act on — see Section 7, failure-mode check). - Sales team enablement status: were AEs/CSMs trained and carrying Router in active conversations before 2026-08-20, or did the launch outrun enablement. - Support/CS staffing and macro readiness for the data-retention question press immediately raised — i.e., did Support have a scripted, accurate answer ready on day one, or was this a gap. - Legal/compliance sign-off specifically on the opt-out one-year retention default as customer-facing policy (this is exactly the kind of internal input Module 03 Area 1's failure-mode list and Area 2's failure-mode list both flag — see Section 7). - Ramp's own internal calendar — whether Router competed with or was sequenced around Ramp Stack's June launch and the Series F news cycle.

Calibration check against Ramp's revealed behavior — genuine OS-added analysis, not a restatement: the OS's job isn't just to produce a tier in isolation — it's to check its own heuristic against what the company actually revealed about its own internal tiering decision, since a company's launch behavior (dedicated domain, PR-wire distribution, executive-level press briefing implied by same-day TechCrunch coverage, multi-outlet pickup) is itself a public signal of how Ramp tiered it internally. Ramp's revealed behavior — a standalone product surface, a PR-wire release, and coordinated same-day coverage across TechCrunch, PRNewswire, and Benzinga — matches a major-launch playbook, not a changelog-only or GA-quiet release. This is a match between the OS's blind, public-evidence-only tiering call and Ramp's actual revealed tier — a useful sanity check on the heuristic itself, not proof the internal readiness gate was actually satisfied (those remain unconfirmed per the list above). Reasoned hypothesis.

Section 3 — OS CONTRIBUTES: Packaging Read Feeding the Launch (Area 1 → Area 2 handoff, per module 03's own handoff note)

OBSERVED (input): Router shipped free through the rest of 2026, plus a $26 credit, with customers paying only pass-through model-inference cost — no disclosed Ramp markup on the routing layer itself.

OS reading: Per Module 03 Area 1's decision scope (PMM doesn't set price, but does read what a packaging shape communicates and flags what's needed to validate it), this is a land-grab / usage-capture packaging shape, not a monetization launch: Ramp is pricing the routing layer at effectively $0 margin to (a) displace OpenRouter as the default for its existing customer base and (b) collect usage data under its stated retention policy, betting that expense-management customers already trust Ramp with financial data and will extend that trust to AI traffic. This is consistent with, and reinforces, the "positioning high / revenue near-zero" read in Section 2. Reasoned hypothesis.

Internal input required to validate this packaging call, not guessable: the actual COGS Ramp is absorbing or passing through un-marked-up on model inference (is "no markup" literally true, or is a margin embedded in the customer-facing per-token rate that just isn't disclosed), and Finance's revenue model for when/how this converts from free to paid after 2026 — the free period has a stated end point, which itself is the kind of pricing-cadence "update trigger" Module 03 Area 1 names.

Cross-check against ICP/positioning (Module 02), run 2026-09-06 against 02_icp-positioning-ramp.md: (1) The packaging read's core claim, that Router extends Ramp's spend-management trust into AI traffic, agrees with Module 02's B2 spend position and with Ramp's own release ("connects model selection decisions to Ramp's broader AI spend visibility and controls"). (2) The read's "displace OpenRouter as the default for its existing customer base" assumes the bridge motion that Module 02's A3 leaves unresolved and B4 declines to recommend without internal input. The packaging read is therefore held at Reasoned hypothesis, contingent on A3, and the internal input named above gains a third item: whether Router is intended as a cross-sell into the existing Ramp base at all. (3) The free-through-2026 mechanics agree with Module 02's finding that no economic-buyer message can be drafted from public evidence. (4) The one-line integration agrees with the champion-stage message in the matrix. Net: the cross-check lowers the packaging read's confidence rather than raising it, which is the useful result. The first version of this document declared this cross-check blocked because Module 02 "has not been run against Ramp"; the positioning document had existed since 2026-09-04, and the statement stood for two days after it. Corrected on the record 2026-09-06 (JOS-31, D-067 closure rule).

Section 4 — OS CONTRIBUTES: Workback Plan (Illustrative — dates are T-minus placeholders, not asserted Ramp facts)

Per Module 03 Area 2's sequencing rule: internal readiness confirmation → internal enablement → external communication, always in that order, external never before internal. The dates below are a structural template scaled for a major launch, expressed as T-minus offsets from the known public launch date (2026-08-20). They are not a claim about Ramp's actual internal calendar, which the OS has no access to and does not invent. Illustrative output.

Why the sequence matters here specifically, not generically: Module 03's stated failure mode is external comms outrunning internal enablement. The Section 1 reception data (data-retention concerns surfacing in coverage almost immediately) is the OS's actual test of whether G4 (Support readiness on this exact question) was cleared before G7. This cannot be confirmed from outside — but it is precisely the kind of gate the OS is built to check, and precisely the kind of question this document flags as open rather than assumed. Internal input required.

Section 5 — OS CONTRIBUTES: Ownership Map

Per Module 03 Area 2's Human owner logic, applied to this launch's specific gates (not a generic RACI — mapped to the actual open questions Section 1's reception surfaced):

All rows are Reasoned hypothesis — role titles are generic-org-shape assumptions consistent with a company Ramp's size, not confirmed Ramp org-chart facts, which are Internal input required and not publicly available.

Section 6 — OS CONTRIBUTES: Go/No-Go Brief (retrospective template, filled honestly)

This is the actual artifact Module 03 specifies as PMM's Output for the launch-date decision — reproduced here as it would have looked, filled in with what is and isn't answerable from outside:

OS's honest output at this checkpoint, if this were a live launch: five of six readiness rows are unconfirmed. Per Module 03's own validation rule ("a tiering recommendation built on unconfirmed readiness assumptions is invalid by construction and should be flagged as such, not silently shipped"), the correct OS output at a real T-2-week checkpoint would have been an explicit escalation to the named owners in Section 5 — not a silent green light. This is what the OS is for: making the absence of confirmation visible instead of papering over it with a plausible-looking brief. Illustrative output.

Section 7 — OS CONTRIBUTES: Validation Against Module 03's Own Failure Modes

Module 03 names five specific failure modes for this function. Checking the observed reception against each, honestly, is real OS output — not a launch recap:

1. External outrunning internal enablement. Section 1's reception shows the data-retention question surfaced in coverage almost immediately. This is consistent with (not proof of) either (a) Support being under-prepared for that exact question, or (b) Support being fully prepared and press simply asking it anyway because it's the obvious question for any AI-data product. The OS cannot distinguish these from outside — Internal input required — but names this as the single highest-value internal question to ask Ramp's Support/CS lead if this were a real engagement.
2. Tiering inflation. No evidence of this — the market-facing dimensions (Section 2) independently support a major-tier read; this doesn't look like internal-morale-driven overclassification.
3. Tiering deflation. No evidence of this either — Ramp's revealed behavior (Section 2's calibration check) matches a major-launch playbook, not an under-classified one.
4. Treating the date as fixed despite new readiness information. Not observable from outside — the OS has no visibility into whether 2026-08-20 slipped from an earlier internal target. Internal input required.
5. Assuming internal readiness rather than confirming it with the actual owner — named by the module as "the single largest risk of an AI-operated version of this function." This is the most directly testable failure mode against this exact case: the "3 years internal use, 99.9% reliability" claim is precisely the kind of plausible-looking, unconfirmed readiness signal the module warns against treating as sufficient. It's real evidence (Ramp said it publicly, and dogfooding for 3 years is a genuinely strong signal if true) — but it is Ramp's marketing claim about its own readiness, not the OS's own confirmation from the actual engineering owner. An OS operating with real internal access would treat this claim as a starting hypothesis to verify with Engineering directly, not as the readiness confirmation itself. This is the clearest, most concrete instance in this whole exercise of the module's own stated failure mode showing up in real public material — flagging it is the deliverable; restating the "3 years" claim on its own would not have been.

Section 8 — OS CONTRIBUTES: Measurement Plan

Per Module 03's Measure section split (what PMM can track independently vs. what requires internal systems access), applied to this specific launch:

Trackable now, independent of Ramp internal access — Reasoned hypothesis / Illustrative output: - Press-tier achieved: major-tier coverage confirmed (TechCrunch same-day + PR-wire + 6+ secondary outlets within 48 hours) — a leading indicator the external-comms gate (G6/G7) executed at major-launch scale. - Sequencing-plan adherence: (inference removed 2026-09-06 — Ramp's "customers already using Router" phrasing was read as evidence of a closed beta; no primary source describes an external beta, and Ramp's release attributes the prior usage to three years of internal use. No public evidence on sequencing either way.) - Competitor reaction: trackable going forward — has OpenRouter, Portkey, or Martian publicly responded or shipped a comparable move since 2026-08-20 (none found as of 2026-09-04, ~2 weeks post-launch). - Theme persistence: whether the data-retention concern recurs in coverage over the following weeks (a signal of whether Ramp's messaging/support response actually resolved it) or fades (signal it was addressed or was never material).

Internal input required — cannot be measured from outside: - Actual Router signups, active usage volume, revenue-conversion rate once the free period ends. - Real cost-savings figures behind the "~40%" claim (sample size, methodology, selection bias of early adopters). - Support ticket volume specifically about data retention/trust, and whether it exceeded forecast. - Sales-cycle or win-rate impact on Ramp's core spend-management product from the Router halo effect (or drag, if trust concerns bled into core-product conversations). - Whether the launch achieved whatever Ramp's own internal goal was (awareness vs. pipeline vs. category-positioning vs. AI-narrative support ahead of/around the Series F story) — this determines what "success" even means here, and it's unknowable from outside per Module 03's own Missing-inputs list.

Section 9 — Judgment Calls and Self-Check Against the Jerry-Add Test

Judgment calls made in building this document, stated plainly:

1. Treated "novelty to Ramp's narrative" as distinct from "novelty to the market" and scored the launch on the former — the module doc as written doesn't make this split explicit; this document extends it. Flagged inline in Section 2, not hidden.
2. Used Ramp's own "3 years internal use" and "40% savings" claims as evidence to interrogate, not evidence to accept — the OS's job per Module 03's failure-mode #5 is to treat vendor self-report as a hypothesis, not a confirmation. This shaped Section 6 and Section 7 directly.
3. Ran the Module 02 (ICP/positioning) cross-check for the packaging read in Section 3 on 2026-09-06, once it was noticed that the module had existed since 2026-09-04 while this document still declared the check blocked. The stale statement is the reason the dependency-freshness manifest (JOS-34) now records every cross-check with the upstream version it was run against.
4. Workback dates are structural T-minus placeholders, not Ramp's real calendar — repeated at every table to avoid the read that this document knows Ramp's actual internal schedule, which it does not and cannot.
5. Egress limitation: primary-source fetches to TechCrunch, PRNewswire, Benzinga, and several secondary outlets were blocked by this session's network egress proxy; facts attributed to those outlets above come from WebSearch's synthesis of them, not direct quotation of primary text. Flagged once, here, per this repo's standing rule on stating capability gaps rather than re-discovering them silently. (Superseded 2026-09-06: the Material Claim Verification Gate re-ran in a local session with direct web access; every entry citing "fetched directly 2026-09-06" is a primary-document read, not search synthesis.)

Self-check against the Jerry-add test, section by section: - Section 1 (OBSERVED): correctly reads as input data — short, cited, makes no decision. - Section 2: passes — the novelty-split and calibration-check are OS-original, not restated Ramp marketing. - Section 3: passes — the cross-check is run, and it lowers the packaging read's confidence rather than raising it. - Section 4: passes — every date is marked illustrative; the gate logic (not the dates) is the content. - Section 5: passes — maps owners to this launch's actual open questions (data retention), not a generic RACI. - Section 6: passes — the honest "five of six unknown, should have escalated" output is the point, not a filled-in-looking brief. - Section 7: passes — this is the section most directly testing the OS's own failure modes against real evidence; it is the closest thing in this document to the deliverable's core value. - Section 8: passes — clean split between trackable-now and internal-input-required, tailored to what Section 1 actually surfaced (retention-concern persistence, competitor response) rather than a generic KPI list.

No section, on this pass, reads as "Ramp launched Router on August 20 and here's what it does" as its point — where launch facts appear, they are immediately operated on by a named OS mechanism (tiering heuristic, sequencing gate, ownership map, failure-mode check, or measurement split). Per D-019's Verification Gate, this self-check is not a substitute for independent verification — it is offered as the builder's own pass, to be checked independently before this deliverable is treated as done.

Current status of this deliverable

Workflow tested (first-time): the Launch Strategy module's tiering heuristic, sequencing gate, and output-artifact set have now run once against a real, publicly-documented company launch (upgraded from 01_OS_Architecture/03_pricing-and-launch.md's prior status of "Reasoned hypothesis, not yet run against a real case"). Individual outputs within it — the specific tier call, workback dates, ownership names — remain Reasoned hypothesis / Illustrative output, since none were confirmed by an actual Ramp stakeholder. No claim in this document should be read as "Live in operating system" — that status is reserved for a mechanism actually operating inside a real hiring company, which this is not.