# GÖ.AI Treasury Studio — Financial Scenario Lab

## Purpose
The Financial Scenario Lab is the executable operating model behind investor Slides 10, 13, 14 and 16. The deck is a snapshot; this model is the source of the snapshot.

**Operating principle:** simplify the presentation, not the thinking.

The lab pressure-tests GÖ.AI's revenue mechanics, unit economics, VOP guardrails, corridor capture assumptions, capital requirements and runway under one canonical model.

## Canonical revenue model
Annualized revenue is separated into three layers:

1. **Recurring platform revenue** = active travelers × annual platform ARPU.
2. **Coordination revenue** = active travelers × annual trips × coordinated spend per trip × retained coordination contribution.
3. **Enterprise / intelligence revenue** = enterprise accounts × enterprise ACV.

This deliberately separates the durable business model from any particular packaging decision.

## VOP guardrail
`VOP = Expected Measurable Customer Value / Traveler Premium`

Internal governance range:
- **3.0×+** strong surplus
- **2.0×–2.99×** healthy target
- **1.5×–1.99×** borderline
- **1.0×–1.49×** weak
- **<1.0×** modeled customer-value ceiling pressure

Economic policy: `Economic Floor ≤ GÖ Offer Price ≤ Customer Value Ceiling`.

## Pressure-test presets
Base, Conservative, Downside, Upside, Capital Constrained, Enterprise Led, Traveler Led, and High VOP Executive. Presets are starting points, not forecasts. Every input can be modified independently.

## Financial Chaos Mode
Chaos Mode moves correlated assumptions together. Current shocks: CAC, retention, annual trip frequency, direct provider/technology COGS, and enterprise ACV. Future shocks should include enterprise sales-cycle delay, payment-rail variance, provider pricing changes, churn clusters, infrastructure step-functions and disruption-driven cost spikes.

## Scenario receipts
Every saved run emits a receipt containing: scenario ID, model version, assumptions, outputs, timestamp, changed by, data provenance, and observed-vs-modeled status.

Example ID: `FIN-2026-09-11-BASE-0042`.

The browser always retains a local copy. When Netlify's `GITHUB_RECEIPTS_TOKEN` is configured with write access to this repository, the same immutable JSON receipt is written to:

`/receipts/YYYY/MM/FIN-....json`

GitHub is the canonical audit trail for v0.1 because it provides version history, attribution, and a simple handoff surface for the future CTO/CFO.

## Google Drive / Sheets bridge
Google Sheets should be an analytics/operations view, not a second source of truth. A future bridge should read canonical GitHub receipts and append normalized rows to a CEO finance workbook. The scenario ID remains the primary key so the Sheet can be rebuilt from GitHub at any time.

Do not write financial truth independently to GitHub and Sheets without deterministic reconciliation.

## Deck contract
- **Slide 10 — Business Model:** revenue layers, VOP and pricing guardrails.
- **Slide 13 — Market Strategy:** traveler pool, corridor capture, density and GTM assumptions.
- **Slide 14 — Financial Projection:** annualized revenue, margin and milestone trajectory derived from saved scenarios.
- **Slide 16 — The Ask:** raise amount, runway and capital allocation tied to Product Truth → Economic Truth → Customer Truth → GTM Truth → Enterprise Truth.

## Model governance
1. Preserve historical model versions.
2. Never silently rewrite a receipt after provider prices, assumptions or formulas change.
3. Replace modeled inputs with observed telemetry as beta data becomes available.
4. Keep sandbox and production provenance explicit.
5. Do not double-count traveler platform revenue and enterprise platform revenue.
6. Do not treat city-level market totals as revenue forecasts.
7. Do not increase traveler premium merely because a model can tolerate it; customer surplus is a strategic asset.
8. Review assumptions monthly during beta and quarterly after stable production telemetry exists.

## Future CTO implementation path
- Persist receipts to a database in addition to GitHub when warranted.
- Ingest actual ProviderUsageEvents and trip-level treasury records.
- Derive observed trips/traveler, direct technology COGS, payment variance and retained contribution automatically.
- Add locked Base / Downside / Upside board snapshots.
- Produce investor-deck exports from a selected canonical receipt rather than manually retyping assumptions.

## Acquisition economics v0.2
The Scenario Lab now separates **direct-traveler CAC** from **enterprise CAC** and adds a governed VALIDATE / PROVE budget bridge. The current planning values are $350 per newly acquired direct traveler and $8,000 per newly won enterprise account, with $6,000 / $12,000 enterprise sensitivities. These are modeled assumptions, not observed acquisition performance.

The $225,000 Slide 16 GTM + market-validation allocation is an envelope, not automatically an acquisition-only budget. Treasury shows a theoretical acquisition-only capacity until explicit VALIDATE and PROVE acquisition allocations are entered. Enterprise-sourced travelers are separated from direct acquisitions so the same traveler is not charged a full direct CAC twice.

See `docs/acquisition-economics-v0.2.md` for the model contract, required tests and investor-deck publication policy.

## Separate pre-seed financing scenario
Treasury Studio now keeps the $500K pre-seed VALIDATE capital plan separate from the existing $1.5M Seed/Base Case. The pre-seed plan uses `funding-scenario-v0.1.0`, starts from $0 observed revenue and zero observed customers, and targets the first 100 active travelers plus two enterprise accounts.

Its $27,250 acquisition budget is a line item inside the operating allocation, not an additional expense added on top of Opex. The default 12-month plan schedules $445,000 of expenditure and holds $55,000 as decision reserve. The displayed 12-month and 18-month funding-capacity figures are mathematical ceilings only.

Saved pre-seed states remain canonical `FIN` receipts with `scenarioClass: preseed_validate_capital`, so pre-seed and Seed assumptions can be compared without mutating historical receipts or drifting between decks.

## Sequential financing authority

The prior combined VALIDATE→PROVE framing has been superseded for financing purposes by two separately versioned scenarios:

1. `funding-scenario-v0.2.0` — $500K Pre-Seed VALIDATE over 18 months.
2. `seed-prove-funding-v0.1.0` — $1.5M Seed PROVE as incremental capital after successful VALIDATE.

Seed inherits the VALIDATE operating state rather than restarting at zero. Costs already funded by the $500K Pre-Seed round may not be represented as new Seed uses of funds unless they are genuinely new post-VALIDATE scope. Seed opening cash is recorded separately at close; the model currently uses the $31K Pre-Seed Decision Reserve as a modeled carry-forward placeholder only.

Canonical documents:
- `docs/validation/preseed-validate-500k-capital-plan-2026-10-26.md`
- `docs/validation/seed-prove-1500k-incremental-capital-plan-2026-10-26.md`