Same pitch, different end-games

Holding the vendor's facts, price and diligence answers fixed, does the positioning of a pitch change which institutional end-game an organisation reaches? The preregistered outcome is the share of runs that end engaged with the vendor (a pilot, a partnership or acquisition exploration), compared between strategic-upside and enterprise positioning and between research-institution and enterprise positioning, paired by seed. It would be falsified, in this simulator, by an upside or research arm whose engagement rate differs from enterprise by more than the replicate arm's noise.

Neither preregistered contrast cleared the bar: positioning did not detectably change how often the organisation engaged the vendor (strategic upside −3 pp, research ±0 pp against enterprise; Holm p = 1.000 and 1.000). The negative control, the same enterprise pitch with independent model samples, differed by +17 pp (p = 0.302) and reached the same terminal state as enterprise in 50% of seeds, which is the run-to-run noise any other difference has to be read against.

A fictional startup, Velliton, pitches deterministic simulation for warehouse-robotics fleet software to a fictional freight operator, Brenmoor Freight Systems. Every arm carries the same fact sheet (a 12-week pilot at $140,000, a $420,000-a-year licence after it, 14 employees, 22 months of runway, SOC 2 Type I, one customer-reported result), and the vendor's diligence answers are fixed text, identical across arms. Only the cover mail and the deck's framing differ, and they are matched in length:

Dear Rafael,

Velliton Replay lets your fleet-control team test every change against recorded warehouse days before it ships, so regressions are caught in simulation instead of on the floor.

The pilot is 12 weeks at one Brenmoor site for a fixed $140,000, with a named implementation lead, weekly status reports and success criteria agreed up front. Integration typically takes 4-6 weeks with two of your engineers. Replay runs inside your cloud account with read-only access to fleet-control logs; SOC 2 Type I is complete and Type II is under way. At one customer, 31 of 38 pre-release regressions were caught in simulation. After the pilot, pricing is $420,000 a year for up to four sites.

The fact sheet is attached and the deck is shared with you. Could we book 30 minutes with you and your fleet-software lead?

Ana Ferreira
Co-founder and CEO, Velliton

[attached: velliton-facts, velliton-deck]

Velliton Replay: pre-release testing for fleet software

Problem: fleet-control changes cause floor incidents that testing does not catch.
Solution: replay recorded warehouse days against every change before release.
Pilot: 12 weeks, one site, $140,000 fixed; named implementation lead; agreed success criteria; weekly reporting.
Security and deployment: your cloud account, read-only log access, SOC 2 Type I done, Type II in progress.
Outcome at one customer: 31 of 38 pre-release regressions caught in simulation.
Pricing after pilot: $420,000 per year for up to 4 sites.

Dear Rafael,

Velliton grew out of a university robotics lab's work on deterministic replay, published in two peer-reviewed papers. Our question has always been why fleet-control changes that pass testing still fail on the warehouse floor, and how to measure that before release.

We would like to propose a 12-week joint study at one Brenmoor site. We would replay your recorded warehouse days, measure how many regressions simulation catches before release, and write up the method and the results with your engineers. In our first deployment, 31 of 38 pre-release regressions were caught in simulation. Every run is reproducible and every claim can be checked against the replay.

The study is a fixed $140,000. The fact sheet is attached and the deck is shared with you. I would value 30 minutes with you and whoever leads fleet software.

Ana Ferreira
Co-founder and CEO, Velliton

[attached: velliton-facts, velliton-deck]

Velliton: measuring why fleet changes fail

Who we are: a research-led team from a university robotics lab; two peer-reviewed papers on deterministic replay.
What we study: the gap between fleet software that passes tests and fleet software that works on the floor.
The instrument: Velliton Replay, exact and forkable replays of warehouse days.
Proposed: a 12-week joint study at one site, with a shared write-up of the method and results.
First result: 31 of 38 pre-release regressions caught in simulation at one customer.

Dear Rafael,

Whoever owns the simulation layer will set the pace of warehouse automation for the next decade. Velliton Replay is that layer: exact, forkable replays of entire warehouse days, so fleet changes ship in days instead of quarters. Operators who adopt it early will out-ship everyone else; the ones who wait will end up licensing it through a competitor's partner.

We are in conversations with five other logistics operators and will choose one anchor partner to shape the roadmap with us. For the right partner we are open to a strategic structure: a pilot that converts into an anchor partnership, a strategic investment, or a deeper combination of the two companies. At one customer, 31 of 38 pre-release regressions were caught in simulation.

The pilot is 12 weeks for $140,000. The fact sheet is attached and the deck is shared with you. Can we talk this week?

Ana Ferreira
Co-founder and CEO, Velliton

[attached: velliton-facts, velliton-deck]

Velliton: the simulation layer for warehouse automation

Thesis: the operator that controls simulation controls the pace of automation.
The platform: exact, forkable replays of entire warehouse days.
The window: one anchor partner will shape the roadmap; 5 other operators in conversation.
Structures on the table: pilot converting to anchor partnership, strategic investment, or a deeper combination.
Proof point: 31 of 38 pre-release regressions caught in simulation at one customer.
Entry: 12-week pilot, $140,000.

VELLITON FACT SHEET (identical in every version of this pitch; all of it is fictional)
- Product: Velliton Replay, a deterministic simulator for warehouse-robotics fleet software. It runs fleet-control code against recorded or synthetic warehouse days; any run can be replayed exactly and forked to test a change.
- Company: founded 2024; 14 employees; $11M raised (seed and Series A); 22 months of runway at current spend; 3 paying customers (two regional 3PLs, one parcel-hub operator); annual recurring revenue $1.1M. In conversations with 5 other logistics operators.
- Security: SOC 2 Type I complete; Type II audit window closes in 5 months. Needs read-only access to fleet-control logs; can run inside the customer's cloud account.
- Offer: 12-week pilot at one Brenmoor site, fixed fee $140,000. After the pilot, a site licence of $420,000 per year for up to 4 sites.
- Integration: estimated 4-6 weeks of 2 Brenmoor engineers plus Velliton's team.
- Evidence: in one customer's 10-week deployment, 31 of 38 regressions found before release were found in simulation (customer-reported, not independently audited).
- Team: the two founders previously worked at a university robotics lab and published 2 peer-reviewed papers on deterministic replay.

The counterfactual for each arm is the enterprise arm of the same seed: the same world, forked from one snapshot after the stakeholders' mailboxes and the fact sheet were written, with the same availability and turn-order streams. The enterprise replicate arm sends the identical enterprise pitch but draws its model replies independently (sample salt 1), so its difference from enterprise measures the model's own run-to-run variation.

Nothing in the rules picks an outcome. The pitch lands only in the sponsor's inbox; who else hears of it, what diligence is asked for, which proposals are filed and which stances are taken are each stakeholder's structured turn, answered by the model from their persona and from what the world's mail and docs services show them. A stakeholder takes a turn in a week if they have unread mail or an open proposal awaits their approval, and they are available that week. Every mail, forward, shared document and decision record is an owner write to the company-2026 world's services, so each week's state hash covers them.

• Runs: 30 seeds (1001–1030) × 4 arms = 120 runs, ten simulated weeks at most.
• Model: deepseek-flash through the repository's DeepSeek configuration, temperature 0.7, reasoning effort low, JSON mode; engine 0.3.0.
• Cost: 1,211 model calls, 3,109,403 prompt and 1,419,498 completion tokens (budget cap 1,800 calls); 636 s wall clock.
• Preregistration: preregistration.json, committed before the final run, fixes the outcome, contrasts, test, seeds and budget (spec hash d32b89d53b9fae0f). A 12-run pilot on other seeds is excluded; it changed one thing, the stance wording.
• Common random numbers: arms of a seed share availability and turn order. Because each arm's pitch differs from the first turn, no two arms put an identical prompt to the same stakeholder (0 such pairs), so arms diverge from the first week: the pairing removes scheduling noise, not model noise.
• Replay: every reply is in the checked-in journal, keyed by prompt and sample index and pinned to the engine, world and spec. Offline replay reproduces every week's state hash and every terminal state (--offline --expect). Drawing new replies is a different thing: it is a new sample, which is what the replicate arm measures.

• Every stakeholder is the same model given a different persona. Disagreement between them is disagreement the prompt induces, and the elicited ratings tell you about the model's priors about such roles, not about executives.
• The institution is one hand-written set of decision rights. Different rights (a procurement veto removed, a CFO above finance) are different experiments; the busy-organisation run varies only availability.
• The world's mail and docs are read as text, not through a mail client; the stakeholders cannot meet, call or lobby outside mail, and the vendor answers diligence but never follows up or negotiates.
• The fact sheet is generous to a pilot (it fits finance's remaining budget), which may explain why pilots dominate in every arm; a pricier offer could separate the arms differently.
• 30 pairs detect only large differences. A null here is evidence against a large effect of positioning in this simulator, not against an effect on real organisations.
• No frequency on this page is a real-world probability of a pilot, a build or an acquisition. None has been calibrated against a real buying process.

1. Vignette survey of real roles. Show the three pitches, randomised, to practising engineering, finance and procurement leaders and compare their first ratings and stated next step with Figure 4's simulated ratings, role by role.
2. Randomised outbound test. Send matched positioning variants to comparable prospect accounts and record forwarding breadth, diligence requests and meetings in a CRM: the observed counterparts of exec_forwarding_breadth and diligence_breadth.
3. Historical deal outcomes. Code past enterprise evaluations (pilot, build, reject, stall, time to decision) to calibrate the terminal-state distribution and the decision rules themselves.
4. Only then fit a mapping from simulated to observed outcomes and report calibrated probabilities, with the calibration data named.

# replay the published run from the journal: no model, no key
.venv/bin/python research/studies/market-perception/executive-endgames/run.py --out target/research/ee-replay \
    --journal research/studies/market-perception/executive-endgames/results/main/journal.jsonl --offline \
    --expect research/studies/market-perception/executive-endgames/results/main/summary.json        # replay: identical
# analyse and rebuild this page from the results
.venv/bin/python research/studies/market-perception/executive-endgames/analyze.py research/studies/market-perception/executive-endgames/results/main
python3 research/studies/market-perception/executive-endgames/build_page.py --check
# draw new samples (needs DEEPSEEK_API_KEY; fails clearly without it)
.venv/bin/python research/studies/market-perception/executive-endgames/run.py --out target/research/ee-new --max-calls 1800

Data: results.json · runs.csv · tree.json · model journal · spec.json · page data. Code: run.py, analyze.py, institution.py, deliberation.py, trajectory.py.

Study source, spec and results ↗