# Deliverable spec — Frontier Lab Composite Operations World

**Which document is which.** This file specifies *our own deliverable*: the bundle
you are holding, its required capabilities, and its acceptance criteria.

`PRD.md` is a different document: it records the product documentation of the
real software the five mock MCP servers are modeled on, so a reader can see what
each mock is faithful to and where it intentionally deviates.

- `DELIVERABLE_SPEC.md` (this file) — what the sample must ship.
- `PRD.md` — what the mocks imitate and the fidelity boundary.

## Objective

Provide a sendable, offline-runnable sample of a stateful enterprise tool world
that a frontier lab can inspect, compile, seed, serve over MCP, evaluate with
100 tasks, and analyze for model failure modes.

## User

An applied-research or post-training team evaluating long-horizon tool use,
environment quality, verifier discrimination, and trace provenance.

## Required capabilities

1. Exactly 100 tasks across 10 operational categories.
2. At least 20 executable tools; this release supplies 32 across five servers.
3. MCP 2025-11-25 initialize, tools/list, and tools/call over stdio and
   Streamable HTTP.
4. One deterministic SQL seed and one fresh state per episode.
5. A directed acyclic tool-function graph with an explainable correlation score.
6. Executable state verifiers with expected and actual values in every trace.
7. One hundred programmatic oracle traces proving task solvability.
8. One hundred dry-run traces for each deterministic reference-policy fixture.
9. Failure analysis for the strong, mid, and weak reference-policy fixtures,
   explicitly separated from empirical model evidence.
10. A separate live-provider runner with observed model identity, per-request
    cost receipts, and an optional operator-selected spend ceiling.
11. Research queries, source summaries, live registry snapshots, pinned GitHub
    repositories, and explicit retrieval limitations.
12. A browser player with downloadable reports, traces, and the complete archive.
13. A canonical company profile containing the Blobfish product thesis, intended
    buyer, synthetic Northstar tenant, active personas, and workflow-claim boundary.

## Evidence policy

The bundle must never describe deterministic fixtures as model outputs. A trace
is empirical only when its evidence class is `live_provider_inference`, a
provider response was received, and the provider-returned model field is stored.
Hidden chain-of-thought is neither requested nor recorded.

Vendor documentation substantiates individual product capabilities and selected
lifecycle semantics. It does not establish that a customer uses the ten exact
cross-system sequences in this demo. Those sequences must be described as
vendor-grounded synthetic composites unless customer SOPs, interviews, process
mining, or production traces are added as a separate evidence class.

## Acceptance criteria

- `python3.12 -m frontier_lab_world.build --output artifact` succeeds offline.
- `python3.12 -m frontier_lab_world.validate artifact` reports PASS.
- Five server wrappers compile and return their catalog-assigned tools
  (`crm`=7, `support`=6, `billing`=6, `engineering`=7, `knowledge`=6).
- The composite wrapper returns all 32 tools.
- All 100 oracle traces replay to reward 1.
- Each requested target trace file has exactly 100 records and verifier details.
- The DAG contains all tools, is acyclic, and covers every adjacent task step.
- The verifier audit has no pre-satisfied assertions or surviving omission,
  wrong-target, or wrong-value mutants.
- Canonical and equivalent read-free plans pass for every retained task.
- The manifest reports empirical, fixture, and oracle evidence counts separately.
- Every research source has a URL, publisher, original summary, design use, and
  the shared bundle-assembly stamp disclosed in `provenance.json`.

## Non-goals

- Production SaaS parity or access to real customer systems.
- Claims that the synthetic composite workflows represent observed customer
  process prevalence or an exact customer's operating procedure.
- Claims about comparative model quality from synthetic fixtures.
- Redistribution of full third-party articles or upstream source repositories.
- Automatic paid API calls during build, test, or validation.