Update to OloLand DD

{
  "description": "Use when analyzing SaaS unit economics, cohort retention (NDR/GRR), LTV/CAC, CAC payback, magic number, or rule of 40. Computes deterministic metrics from customer-month transaction data and flags anomalies vs. the seller's stated narrative.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 439
    }
  ],
  "name": "unit-economics",
  "skill_md_contents": "---\nname: unit-economics\ndescription: Use when analyzing SaaS unit economics, cohort retention (NDR/GRR), LTV/CAC,\n  CAC payback, magic number, or rule of 40. Computes deterministic metrics from customer-month\n  transaction data and flags anomalies vs. the seller's stated narrative.\n---\n\n# Unit Economics & Cohort Analysis\n\n## What this is (and isn't)\n\nThis is **deterministic computation**, not prose. The cohort triangle, retention metrics, and unit-economics ratios come from numpy/pandas in `services/financial/cohort_analyzer.py`. The LLM's job is interpretation, not calculation.\n\nThe killer feature is **reconciliation**: when the CIM claims 115% NDR but the cohort data shows 92%, that 23-point spread is the kind of finding that closes IC memos. The `analyze_unit_economics` MCP tool detects these automatically when you pass `stated_*` parameters.\n\n## When to use\n\n- Reviewing a SaaS or recurring-revenue deal\n- Validating CIM claims about retention, churn, or sales efficiency\n- Building cohort triangles for a quality of revenue analysis\n- Stress-testing the LBO base case (does the model assume retention the cohorts don't support?)\n\n## How to use\n\n### Step 1 — Get the stated narrative\nRead what the seller claims. Look in:\n- The CIM's \"key metrics\" or \"unit economics\" section\n- Management presentations\n- Data room metrics dashboards\n\nCapture:\n- NDR (e.g. \"115%\")\n- GRR (e.g. \"94%\")\n- CAC payback months\n- LTV/CAC ratio\n\nIf the seller doesn't state these, that's itself a finding — note it.\n\n### Step 2 — Load transactions\nFormat: `[{customer_id, period: 'YYYY-MM-DD', revenue}, ...]` — one row per customer per month.\n\nSources, in order of preference:\n1. Customer-level revenue export from the seller (cleanest)\n2. Subscription/billing system export (Stripe, Chargebee, Recurly)\n3. Reconstructed from CRM + invoice data\n4. Aggregated cohort data (less ideal — you lose granularity)\n\nIf you only have aggregated cohort data, the raw cohort triangle CAN'T be recomputed; you'll have to trust the seller's triangle and just compare the headline metrics.\n\n### Step 3 — Estimate LTV/CAC inputs\nPull from financials:\n- `sales_marketing_spend` — last 12 months\n- `new_customers_in_period` — count of new logos in the same period\n- `gross_margin` — as decimal (0.75, not 75)\n- `new_arr_in_period` — for magic number (uses quarter-annualized formula)\n- `ebitda_margin` and `revenue_growth_yoy` — for rule of 40\n\nIf any are missing, the tool returns `None` for that metric — that's fine, partial analysis is still valuable.\n\n### Step 4 — Call the tool\n`analyze_unit_economics(deal_id, transactions, ...)` with all the inputs.\n\n### Step 5 — Interpret\n\n**On retention spreads:**\n- 0-5pp: probably timing/methodology difference, not a finding\n- 5-10pp: medium severity, ask the seller about it\n- >10pp: high severity, this is a flag for the IC memo\n\n**On payback/LTV ratios:**\n- Within ±20% of stated: reconciles\n- ±20-50%: medium\n- Beyond ±50%: high — the unit economics narrative is broken\n\n**On decay fit:**\n- R² > 0.85: clean exponential decay, the cohort behavior is predictable\n- R² < 0.7: cohorts behave differently — could be product-market fit changes, segment shifts, pricing changes. Worth investigating.\n\n**On rule of 40:**\n- >40: strong\n- 20-40: typical\n- <20: weak — model the LBO with conservative assumptions\n\n## Anti-patterns\n\n- **Don't compute cohorts in your head from monthly summaries.** Use the engine.\n- **Don't ignore anomalies because they're \"small.\"** Even a 5pp NDR spread on a $50M ARR business is $2.5M of phantom revenue in the model.\n- **Don't assume LTV-CAC is meaningful for sub-12-month-old cohorts.** The decay fit needs history.\n- **Don't blend B2B and B2C cohorts.** Run them separately if the deal has both.\n\n\n## OpenAI execution requirements\n\nUse the connected MCP server's current tool schemas. Do not invent tool arguments, job-status endpoints, inputs, or outputs. If a referenced tool is unavailable, explain the limitation and request the needed connection or data. Invoke writes only when the user has requested the corresponding action. Do not initiate purchases or payments. An unrun, unsupported, or unavailable procedure is a gap, never a passing result.\n\n\nOpenAI cannot execute local lifecycle hooks. Use the packaged explicit setup/review workflow when requested. Server-side MCP auditing remains authoritative; preserve evidence blockers and human-only approval gates.\n\nClaim-correction submission is unsupported in this OpenAI upload because the current handler records surface=cowork. Do not invoke submit_agent_claim_correction from OpenAI. Explain the limitation and retain proposed correction text for human review without claiming submission. See unsupported-workflows.json for the excluded canonical workflow.\n"
}