Part IX. Company and Investing · Chapter 77
Application-Company Diligence
Application companies are the easiest quantum pitches to believe and the easiest to get wrong: they speak the customer's language while quietly assuming hardware that does not exist yet. This chapter starts diligence where it belongs — with the buyer and the baseline.
In this chapter 9 sections
Start from the buyer’s repeated decision, map data and validation boundaries, benchmark the owned computational kernel, test portability and gross-margin dependencies, and value only evidence that persists if the preferred backend or algorithm changes.
Application-company diligence starts at a repeated buyer decision: choose a route, molecule, schedule, portfolio, diagnosis, or control action. The company must own some durable improvement around that decision. Naming a quantum algorithm does not establish ownership of data, validation, workflow integration, customer relationship, or outcome.
Buyer workflow before quantum method
The ownership ledger records buyer and budget, decision frequency, input and data rights, incumbent method, owned computational or workflow layer, backend dependency, validation owner, deployment work, recurring service hours, result metric, and renewal evidence. A backend substitution and staffing sensitivity reveal whether value persists.
Dated ownership ledger: data, kernel, validation, outcome
A logistics optimizer loses its claimed boundary
The anonymized logistics offering has a paying pilot and a functioning hybrid workflow. Delivery needs 120 expert hours per customer per quarter, and the preferred backend supplies a material portion of the result. Removing the backend raises cost; reducing services breaks deployment. The company has services evidence, but the scalable software boundary remains unproved.
Artifact contract. A dated workflow/evidence/economics table with executable dependency sensitivity. Buyer, frequency, baseline, owned data, owned IP, backend dependency, validation owner, and outcome metric are present; the sensitivity test exposes value that disappears under a backend or staffing change.
Executable reference fixture
TEXT_FIELDS = ("scenario", "buyer", "baseline", "backend_dependency",
"validation_owner", "outcome_metric", "source_id")
def assess(record):
errors = [name for name in TEXT_FIELDS if type(record.get(name)) is not str or not record.get(name)]
for name, unit in (("frequency", "decisions/week"), ("service_hours", "hours/quarter"),
("backend_cost_increase", "fraction")):
item = record.get(name, {})
if type(item.get("value")) not in (int, float) or item.get("unit") != unit:
errors.append(name + "_schema")
for name in ("owned_data", "owned_ip", "paying_pilot"):
if type(record.get(name)) is not bool:
errors.append(name)
scalable = (not errors and record["paying_pilot"] and record["owned_data"] and record["owned_ip"] and
record["service_hours"]["value"] <= 80 and record["backend_cost_increase"]["value"] <= 0.20)
return {"decision": "invalid" if errors else ("product-evidence" if scalable else "services-only"),
"errors": sorted(set(errors)), "service_margin_hours": None if errors else 80 - record["service_hours"]["value"],
"backend_margin_fraction": None if errors else 0.20 - record["backend_cost_increase"]["value"]}
record = {"scenario": "paid routing pilot", "buyer": "daily route planner",
"frequency": {"value": 5, "unit": "decisions/week"},
"baseline": "incumbent tuned heuristic", "owned_data": True, "owned_ip": True,
"backend_dependency": "two declared QPU adapters", "validation_owner": "customer operations",
"outcome_metric": "cost per feasible route", "source_id": "scenario:pilot-ledger-Q3",
"service_hours": {"value": 120, "unit": "hours/quarter"},
"backend_cost_increase": {"value": 0.40, "unit": "fraction"}, "paying_pilot": True}
base_result = assess(record)
bad = {key: value for key, value in record.items() if key != "validation_owner"}
bad_result = assess(bad)
scaled = {**record, "service_hours": {"value": 70, "unit": "hours/quarter"},
"backend_cost_increase": {"value": 0.15, "unit": "fraction"}}
scaled_result = assess(scaled)
assert base_result["decision"] == "services-only" and base_result["service_margin_hours"] == -40
assert bad_result["decision"] == "invalid" and "validation_owner" in bad_result["errors"]
assert scaled_result["decision"] == "product-evidence" and scaled_result["backend_margin_fraction"] > 0
print(f"PASS: 77 company workbook base={base_result['decision']} service_margin={base_result['service_margin_hours']}h invalid={bad_result['errors']} scaled={scaled_result['decision']}")| Ownership field | Observed record | Gate | State |
|---|---|---|---|
| Buyer decision | daily route plan | named and repeated | pass |
| Outcome | reported pilot metric | matched comparator | pending |
| Service intensity | 120 expert hours/quarter | below 80 | fail |
| Backend substitution | +40 percent cost | below 20 percent | fail |
Exact validation command: python3 tools/validate_briefs.py --briefs data/editorial_briefs_64_87.json --from 64 --through 87 --check-rewritten-sources --execute-artifacts
Portability and service intensity shape economics
The next diligence request is a cohort table of implementation hours and buyer outcome, plus a second-backend acceptance run. A product claim advances only if new customers reach the same result with declining bespoke effort. A services business may still be valuable; classify and price it as one instead of borrowing software economics.
Interview the evidence, not the pitch
Prompt. Diligence an application company against one repeated buyer decision.
Deliverable. Workflow map, baseline, dated pilot evidence, owned layer, backend substitution test, staffing sensitivity, outcome metric, and kill criteria.
Pass condition. The conclusion survives removal of marketing labels, distinguishes services from scalable product evidence, and weakens automatically when portability or buyer-outcome evidence is absent.
Model answer: services value without scalable software proof
Format. Logistics-company ledger concluding 'services-proven, product-scale unproved'.
The model answer labels the current state services-proven, product-scale unproved. Under 120 hours and a 40 percent backend-cost increase, the sensitivity fails both declared product gates. The recommendation is a bounded partnership tied to portability and implementation-hour milestones. It becomes avoid if the buyer outcome cannot be measured or if staffing intensity does not fall across the next cohort.
Verification. The sensitivity fixture shows the margin and delivery impact of the documented staffing and backend dependencies and reproduces the bounded conclusion.
Companion work
Artifacts for this chapter
These entries resolve to checked-in local source. Commands are reproduced exactly from the chapter manifest, and source-embedded fixtures are exported as direct downloads.
diligence dossier
Application-company ownership ledger
Reproduce or test
python3 tools/validate_briefs.py --briefs data/editorial_briefs_64_87.json --from 64 --through 87 --check-rewritten-sources --execute-artifacts
Provenance
Sources and review
- Edward Farhi, Jeffrey Goldstone, and Sam Gutmann. A Quantum Approximate Optimization Algorithm. arXiv. 2014primary preprint
- Alberto Peruzzo et al.. A variational eigenvalue solver on a photonic quantum processor. Nature Communications. 2014primary paper
- OpenQASM Technical Steering Committee. OpenQASM 3 specification. Linux Foundation Joint Development Foundation. 2026official technical specification
- Association for Computing Machinery. Artifact Review and Badging. ACM Publications. 2026official reproducibility policy
- U.S. Government Accountability Office. Quantum Computing and Communications: Status and Prospects. GAO. 2021government technology assessment
- IBM Quantum. Qiskit documentation. IBM. 2026official documentation
- Timothy Proctor et al.. Benchmarking quantum computers. Nature Reviews Physics. 2025peer-reviewed perspective
- Kishor Bharti et al.. Noisy intermediate-scale quantum algorithms. Reviews of Modern Physics. 2022peer-reviewed review
The load-bearing claims in the chapter are mapped inline to this registered source set. A citation supports only the bounded claim beside it.