# Internet RU V2 50G E2E Ready Contract

This document is a pre-run gate. Issue #199 does not authorize or start a
formal 50G run.

## Capability boundary

- Big Query is `internet/platform/big_query` and owns ten domain business
  reports: three Ride, three Food, and four Mart reports.
- Missing Index is `internet/platform/missing_index` and owns one real business
  lookup per selected domain in an `indexed` or `missing` prepared binding.
- Hotspot is the shared Internet service-area policy. Exactly 20 percent of
  prepared service-area keys form the target set and the deterministic selector
  directs configured 80 percent of admitted roots to that set.
- Combination cases are configuration. They do not add a worker, SQL catalog,
  runtime action, cleanup branch, or executor case switch.

## Frozen paired runs

| Pair | Left | Right | Sole allowed difference | Question |
|---|---|---|---|---|
| IN-F16-F17 | indexed, Big Query OFF | indexed, Big Query ON | Big Query enabled | Does report interference change foreground statement RU or only latency? |
| IN-F17-F18 | indexed, Big Query ON | missing, Big Query ON | Missing Index variant | Does removing the domain index increase the intended lookup RU/work? |
| IN-F18-F19 | missing, Big Query ON | missing, Big Query OFF | Big Query enabled | Is the interference effect repeatable under missing-index work? |
| IN-F16-F19 | indexed, Big Query OFF | missing, Big Query OFF | Missing Index variant | What is the isolated index effect without Big Query? |
| IN-H20 | canonical | service-area 20/80 | Hotspot enabled | Does real root concentration change RU, latency, or both? |
| IN-BQ-REPEAT | Big Query repeat 1 | Big Query repeat 2 | none | Are the ten fixed reports and foreground effects repeatable? |

The machine-readable source is
`testcase/internet-ru-acceptance-combination.json`. `ValidateSuite` rejects a
pair if its actual recursive JSON difference set is not exactly the declared
allowlist. Data checkpoint, TiPoC binary, target build, duration, foreground
workers, SQL pool, business mix, stable window, and Query Cost configuration
are held in one common contract and checked again against each run archive.

The suite freezes the evidence provider as
`tidb_last_query_info_rru_wru/v1` and its measured model as
`resource_control_rru_plus_wru`. The provider is the session-level collection
path; it is not used as a replacement name for the RU model in analysis or
customer-facing reports.

## Required immutable evidence per run

1. RU acceptance aggregate generated from the foreground and registered
   operation Query Cost scopes.
2. Generic `operation-artifacts.json` with run/attempt identity.
3. Final Big Query receipt when enabled.
4. Final Missing Index receipt for the prepared `indexed` or `missing` state.
5. One sealed selected-run domain receipt for every selected Ride/Food/Mart
   business. Hotspot cases require the projected target identity and counters;
   canonical cases require hotspot evidence to be absent. The dry-run also
   rejects a configured hotspot whose observed target share does not exceed
   50 percent; this is a broad routing-proof guard, not an RU-model threshold.
6. Archive values for TiPoC path/commit/binary SHA-256, target build
   attestation, exact command arguments, data checkpoint, pressure shape,
   business-mix fingerprint, Query Cost fingerprint, and monitoring window.

The report-input compatibility command is:

```text
tipoc ru-acceptance internet-dry-run \
  --request <case-dry-run-request.json> \
  --output <new-output-directory>
```

It writes `internet-report-input.json`, selects five to ten eligible statement
points, forces one anchor from each enabled operation plus one foreground
anchor, and fills the remaining positions by mean RU. It fails closed on an
OFF operation receipt, an enabled operation without an eligible RU/latency
point, a missing hotspot domain, mismatched archive authority, or fewer than
five eligible points. Failed or canceled attempts remain visible quality
signals; they do not alone block report generation when every selected
statement still has a successful RU/latency sample, its counters are
consistent, and its causal identity is unchanged.

## Approval and cleanup boundary

Before a formal 50G run, an operator must replace every `replace-with-*` value,
archive the exact clean TiPoC commit and binary hash, confirm the reusable 50G
checkpoint, confirm monitoring access and target-cluster ownership, and approve
the run. Until that explicit approval, no remote build replacement, prepare,
run, schema mutation, or data cleanup is permitted.

After approval, cleanup may remove only the operation-owned temporary feature
indexes and this test attempt's artifacts/data. The shared 50G checkpoint and
foreign test data remain outside this issue's cleanup authority.