# Ticket #000036 — T3 per-window covert-channel budget bound

**Status:** **closed · 2026-05-11.** Phase 1 (formal derivation + calculator) landed 2026-05-10; dav1d review (`RESPONSE_1` + `RESPONSE_2`) returned 2026-05-11 → Tier-1 polish (recommendation wording → "CANNOT CERTIFY"; structured `certification_status` / `b1_model` / `b1_selected` / `model_assumptions` output fields; bool/NaN/inf validation hardening; `g=0` accepted; hard-coded test cwd removed) + Tier-2 (dav1d Option B applied *in v1* per fox — no v2 fork: default `b1_model = max_envelope = max(fraction_channels, aggregate_bias)`, genuinely upper-bounding across both interpretations of `g`; `effective_control_v1` / `fraction_channels` / `aggregate_bias` reachable via `--b1-model`; every output reports all three B1 variants + both SNR readings; `CALCULATOR_VERSION` stays `t3-bound-v1-bottou-refinement`, `b1_model` echoed in `inputs` disambiguates KAT replays) + KAT-regen tooling (`scripts/generate_t3_bound_kat.py`, 12-entry fixture, `test_t3_bound_known_answer_tests` runs not skips) all landed 2026-05-11. Baseline I_window: 625.87 (effective_control_v1) → 6183.02 (max_envelope default), `NOT_CERTIFIED_BY_BOUND` at W=10000. Test suite 53 → 83. **Both dav1d closure blockers cleared** (B1 worst-case model; active KAT fixture). All §5 acceptance criteria met. **Continuation:** empirical C_B1/C_B2/C_B3 tightening tracked under **#000043** (parks on v7 deployment data); R2's architectural integrations (Merkle audit-event commitment, SQD canonicalization, CTI clause-lattice, 5F trigger, ForkScore security-risk) are separate tickets if wanted; landing the bound's framing into a v7 plastic-training spec parks on that spec gaining a deployment target. Reviewer artifacts: `~/Downloads/RESPONSE_1_-_ticket-000036-...txt`, `RESPONSE_2_-_...txt`.
**Opened:** 2026-05-09
**Scope:** Derive an explicit closed-form upper bound on the covert-
channel capacity under threat model T3 (hyperparameter adversary),
when M2 (per-checkpoint anchor nonce) is in place. The §6 table in
`docs/soft-hash-channel-analysis.md` lists "bounded by per-window
budget" without giving the bound. This ticket calculates it.
**Audience:** maintainers of the v7 plastic-training spec; #000018
follow-up; operators sizing nonce-window length vs acceptable
residual.
**Hard constraint:** the bound must be **explicit closed form** —
not an asymptotic Big-O claim. Operators need it expressed in
bits-per-window with named inputs (per-step bandwidth, window
length, gradient budget) so they can plug in their deployment's
actual numbers and read off the residual.

---

## 1. Problem statement

#000018's §4 reduction bounds T1 + T2 channels at the SHA-256
random-oracle baseline. T3 (hyperparameter adversary) is **not**
covered by that reduction: T3 controls learning-rate scheduling
and batch ordering, breaking the implicit assumption that A's
training-oracle queries follow the published schedule.

§6 of the analysis claims "T3 bounded by per-window budget" with
M2 enabled. The intuition: the per-checkpoint nonce randomizes
the anchor between checkpoints, so T3 only has a single window
of length W steps to exploit before the anchor re-randomizes.
The bound on per-window steerage is the open question.

This ticket pins the bound.

## 2. Design choices

### 2.1 Capacity model

Define the per-window channel as:

```
I_window = I(adversary inputs over W steps  ;  C(M_{t+1}))
           conditional on H_{≤t}, n_t (the published nonce)
```

For each adversary input (gradient bias, learning-rate change,
batch order swap), measure how many bits of `Q(Θ_{t+1})` the
adversary can steer relative to the random baseline.

### 2.2 Three input bandwidths

T3 has three control surfaces. Each contributes to the per-
window channel:

**B1 — Gradient bias (bits per step).** Inherited from T2:
adversary controls `g`-fraction of gradient computations; each
step the adversary biases `O(g · ‖∇L‖)` of the gradient signal.
Per-step bandwidth ≈ `g · ‖∇L‖ / unit-Hessian-step`.

**B2 — Learning-rate selection (bits per LR decision point).**
T3 picks LR from a constrained range. With log-grid LR space
of `R` levels, B2 = log₂ R bits per decision point. Decision
points typically once per K steps under standard cosine /
warmup schedules.

**B3 — Batch order (bits per epoch).** T3 reorders batches
within an epoch. With N batches per epoch, B3 ≤ log₂ N! ≈ N log N
bits per epoch — but most of those bits don't translate to
parameter steerage because batch order has weak influence on
final Q(Θ) under gradient averaging. Effective bandwidth is
much smaller; see §3.2 for the conjecture.

### 2.3 Per-step → per-bit-of-C(M) conversion

The adversary's per-step control bandwidth is in parameter-
space directions. Translating to "bits of C(M_{t+1}) controlled"
requires the inverse map:

```
parameter shift δΘ → SHA-256 bucket shift = ?
```

By the §4 random-oracle reduction (when φ is independent of
Hessian), each independent parameter direction maps to
independent SHA-256 bucket bits — so the conversion is
information-preserving but at the random baseline. T3's edge
over T2 is that hyperparameter control multiplies effective
gradient bandwidth.

### 2.4 The bound (sketch)

Combining the three bandwidths over a window of W steps:

```
I_window ≤ C_B1 · g · W · log₂(N_directions) +
           C_B2 · ⌈W / K⌉ · log₂ R +
           C_B3 · log₂ (W / batch_count) · ⌈W / E⌉
```

where:
- `C_B1, C_B2, C_B3` are channel-efficiency constants
  (≤ 1 by data-processing inequality, typically much smaller).
- `g` is the fraction of gradients the adversary controls.
- `N_directions` is the effective parameter-direction count
  the adversary can steer per step (bounded by the gradient
  budget ‖∇L_max‖).
- `K` is the LR-decision interval (steps between LR changes).
- `R` is the LR-grid size.
- `E` is the steps-per-epoch count.
- `batch_count` is batches per epoch.

The closed-form bound's **goal**: be tight enough that operators
can pick W (the nonce-window length) such that I_window stays
below their target residual (e.g., < 1 bit per window means the
adversary needs ≥ 2^256 windows to steer C(M) to a specific
target).

## 3. Implementation sketch

### 3.1 Formal derivation

Section-by-section in a new doc
`docs/soft-hash-channel-t3-bound.md`:

- §1 Restate T3 model from #000018.
- §2 Define per-window channel formally.
- §3 Bound C_B1 (gradient bias) — Fano's-inequality-style
  argument from information theory.
- §4 Bound C_B2 (LR selection) — finite-alphabet capacity
  argument; LR is a categorical channel with R symbols.
- §5 Bound C_B3 (batch order) — argument that batch-order
  effects on final Q(Θ) are bounded by gradient-noise scale,
  not factorially.
- §6 Combine §3-§5 into a closed-form per-window bound.
- §7 Numeric examples for representative deployments
  (e.g., g=0.05, K=100, R=8, W=10000 → bound in bits).
- §8 Operator guidance: how to choose W given a target
  residual.

### 3.2 Conjecture for C_B3

Standard SGD analysis (Bottou-Bousquet 2008, Hardt-Recht-Singer
2016) shows batch-order effects on final loss are bounded by
the gradient-variance scale, not by the entropy of the
permutation. We conjecture C_B3 ≤ `O(σ_grad / ‖∇L‖)` per epoch,
which is much smaller than `log₂ N!`.

The bound's most important refinement is making this precise.
Random-shuffle SGD has near-zero C_B3; cyclic-shuffle SGD has
O(1) bits per epoch; adversarial-order SGD is the open
question.

### 3.3 Tooling

`bench/scripts/t3_bound_calculator.py` — small CLI that takes
deployment parameters (g, K, R, W, batch_count, gradient_norm)
and emits the closed-form bound:

```
$ python -m bench.scripts.t3_bound_calculator \
    --gradient-fraction 0.05 \
    --lr-decision-interval 100 \
    --lr-grid-size 8 \
    --window-length 10000 \
    --batch-count 1024
{
  "I_window_bits_upper_bound": 3.41,
  "B1_contribution": 2.85,
  "B2_contribution": 0.31,
  "B3_contribution": 0.25,
  "recommendation": "I_window ≈ 3.4 bits/window. To steer
                     C(M) to a 256-bit-specific target, adversary
                     needs ≥ 2^252 windows."
}
```

Operators can plug in their deployment numbers and decide
whether the residual is acceptable.

## 4. Out of scope

- Empirical validation of the bound (separate ticket; needs
  v7 deployment + adversarial training infrastructure).
- Tightening the random-oracle assumption to a concrete PRG
  (covered by #000035).
- Implementing M2 in the v7 codebase (separate ticket).
- T1 / T2 bounds (covered by #000018 §4).

## 5. Acceptance criteria

1. `docs/soft-hash-channel-t3-bound.md` lands with §1-§8 above.
2. Closed-form per-window bound expressed in bits/window with
   named inputs.
3. `bench/scripts/t3_bound_calculator.py` lands; produces
   closed-form output for any (g, K, R, W, batch_count,
   gradient_norm) input.
4. `docs/soft-hash-channel-analysis.md` §9.3 closes — the open
   question becomes "see #000036's bound."
5. Numeric examples cover three representative deployments
   (small / medium / large LR-grid + window combinations).

## 6. Risks

- **Bound too loose to be useful.** If the calculation produces
  e.g. "≤ 100 bits/window", operators have no actionable
  guidance. Mitigation: walk through C_B3 carefully —
  factorial-batch-order naive bound is the loose one. The
  Bottou-Bousquet refinement is what makes the bound useful.
- **Bound depends on unknown gradient geometry.** The
  ‖∇L_max‖ term is deployment-specific. Mitigation: report
  the bound parametrized in ‖∇L_max‖, let operators measure
  it on their deployment.
- **T3 attack model evolution.** Future hyperparameter-control
  surfaces (e.g., adaptive optimizer state manipulation) may
  add B4-B5 bandwidth channels. The framework here generalizes:
  add new B_i terms as new control surfaces are documented.

## 7. Status

**In progress · Phase 1 (formal derivation + calculator) landed
2026-05-10**; pre-review polish pass in `8916bf3`; **math review
in flight with dav1d** (forwarded 2026-05-10 Asia/Kuala_Lumpur
as Tier 2 bundle: `t3-bound.md` + `soft-hash-analysis.md` +
`t3_bound_calculator.py` + `test_t3_bound_calculator.py` + this
ticket). The framework is the deliverable; named constants
(C_B1 = C_B2 = C_B3 = 1) are conservative-but-loose first
estimates that future tightening can replace without changing
the call sites of the closed-form bound. Empirical tightening
tracked separately under #000043. Phase 1 prerequisite (per
original §7) was satisfied: #000034 Phase 1a + #000035 Phase 1
both landed 2026-05-10.

### Phase 1 — formal derivation + calculator (landed 2026-05-10)

- ``docs/soft-hash-channel-t3-bound.md`` — 12-section derivation
  per §3.1 outline. §1 T3 model restatement + M2 setup; §2
  per-window channel formal definition with mutual-information
  decomposition; §3 C_B1 (gradient bias) Fano-inequality bound;
  §4 C_B2 (LR selection) categorical-channel bound; §5 C_B3
  (batch order) Bottou-Bousquet refinement (much tighter than
  the naive ``log₂(N_b!)``); §6 closed-form combined bound; §7
  three deployment numeric examples (small / medium / hardened);
  §8 operator guidance with target-residual → window-length
  solving; §9 closes ``soft-hash-channel-analysis.md`` §9.3;
  §10 open questions + future-tightening paths; §11 calculator
  reference; §12 references.

- ``bench/scripts/t3_bound_calculator.py`` — pure-stdlib CLI
  emitting the closed-form bound for any (g, ‖∇L_max‖, σ_grad,
  K, R, W, N_b, E) input. Returns total + per-bandwidth
  contributions + operator-guidance recommendation. Verified
  against doc §7.1 small-deployment example: produces
  625.87 bits/window vs the doc's hand-calculated 623 bits
  (within rounding).

- ``soft-hash-channel-analysis.md §9.3`` resolution: the open
  question "explicit T3 per-window bound under M2" now points
  at the §6 closed form.

### Phase 2 — empirical validation (not yet open)

The framework is conservative-by-construction. Tightening C_B1
/ C_B2 / C_B3 below the data-processing-inequality ceilings
requires deployment-specific empirical measurements:

- C_B1: feeds from #000034 Phase 1b (Hessian-alignment probe
  on a real v7 checkpoint).
- C_B2: per-deployment 1-Wasserstein measurement of LR-trajectory
  diversity (no ticket yet).
- C_B3: per-deployment SGD shuffle regime measurement (no ticket
  yet — random-shuffle deployments tighten C_B3 by O(√N_b)).

Open as a follow-up ticket once a v7 deployment surfaces empirical
training-loss + Hessian data.

### Closure criterion (refined)

Closes when (a) the closed-form bound lands [done], (b) the
calculator script lands [done], (c) ``soft-hash-channel-
analysis.md §9.3`` is updated to reference this doc [done —
§9.3 closure landed in line 475 of that doc], (d) the conservative
constants either get empirically tightened (under #000043) or
are explicitly accepted by fox as conservative-correct
[pending — gates on dav1d math review verdict].
