docs/tickets: open #000034 / #000035 / #000036#000018 follow-ups

Three new tickets carve up the open questions from §9 of
docs/soft-hash-channel-analysis.md (#000018):

#000034 — Hessian alignment under φ_linear
============================================

Computational. Measure spectrum of W^T W (the v7 reference
embed_hard_to_vec frozen-seed projection matrix) vs typical
training-loss Hessian eigenvalue distributions on representative
checkpoints. Determines whether the linear projection has
structural alignment with low-eigenvalue directions, which would
let T2 adversaries amplify covert-channel steerage beyond the
random-oracle baseline established in #000018 §4.

Deliverable: bench/scripts/phi_alignment_probe.py + verdict
(STRUCTURAL_ALIGNMENT / NO_ALIGNMENT / ANTI_ALIGNED) per
representative checkpoint. Parks until a v7 reference checkpoint
is available; the analysis is empirical-only and useless without
representative training data.

#000035 — PRG choice for φ_PRG
================================

Cryptographic. Pin a specific PRG construction for the M1
mitigation (PRG-based anchor map) proposed in #000018 §5.2.
Recommended: HMAC-SHA-512(seed, digest ∥ counter) → uniform-random
floats in [-1, 1].

Reasons:
  - Tightest dependency surface (stays in SHA family already
    committed via SHA-256).
  - NIST-approved PRF construction (SP 800-108 KDF in counter mode).
  - Speed parity with AES at v7 cadence; PRG cost negligible.
  - Provable security reduction: PRF security from SHA-512
    collision-resistance, structurally stronger than SHA-256.

Deliverable: arborist/v7/anchor_prg.py + tests + known-answer-test
fixture + v7 § 9.10 amendment text. Lands when v7 plastic-training
has a deployment target.

#000036 — T3 per-window budget bound
=====================================

Formal. Derive an explicit closed-form upper bound on the covert-
channel capacity under threat model T3 (hyperparameter adversary)
when M2 (per-checkpoint nonce) is in place. #000018 §6 lists
"bounded by per-window budget" without giving the bound.

Three control bandwidths combine:
  B1 — gradient bias (g · W · log₂ N_directions)
  B2 — LR selection  (⌈W/K⌉ · log₂ R)
  B3 — batch order   (Bottou-Bousquet conjecture: ≪ log₂ N!)

Deliverable: docs/soft-hash-channel-t3-bound.md (§§1-8 formal
derivation) + bench/scripts/t3_bound_calculator.py (operator-
parametrized closed-form). Operators plug in (g, K, R, W,
batch_count, gradient_norm) → read off bits/window residual; pick
nonce-window length to drive residual under their target.

Index updated; Next ID 000037. Cross-reference added to #000018's
status line so future readers see the three follow-ups in line.
This commit is contained in:
russell@unturf.com 2026-05-09 14:50:15 -04:00
parent 7871e1fdfe
commit 951002c372
No known key found for this signature in database
5 changed files with 669 additions and 2 deletions

View file

@ -61,6 +61,9 @@ Newest first. Update on every open/close.
| ID | Title | Status | Opened | Directive |
|----------|------------------------------------------------|-----------------------|------------|-----------|
| #000036 | T3 per-window covert-channel budget bound | open · awaiting go/no-go (#000018 follow-up) | 2026-05-09 | — |
| #000035 | PRG choice for φ_PRG (HMAC-SHA-512 expansion) | open · awaiting go/no-go (#000018 follow-up) | 2026-05-09 | — |
| #000034 | Hessian alignment under φ_linear | open · awaiting go/no-go (#000018 follow-up) | 2026-05-09 | — |
| #000033 | Claim-pack pillar VII (combinatorics) | open · awaiting go/no-go | 2026-05-09 | — |
| #000032 | combinatorics@v1 π* (integer counting kernel) | closed · landed 2026-05-09 | 2026-05-09 | — |
| #000031 | Surface-ingest cited textbooks for claim-pack warrant promotion | open · awaiting go/no-go | 2026-05-09 | — |
@ -97,4 +100,4 @@ Newest first. Update on every open/close.
## Next ID
`000034`
`000037`

View file

@ -1,6 +1,6 @@
# Ticket #000018 — Adversarial soft-hash covert channel analysis
**Status:** closed · landed 2026-05-09 (analysis doc at `docs/soft-hash-channel-analysis.md`)
**Status:** closed · landed 2026-05-09 (analysis doc at `docs/soft-hash-channel-analysis.md`; three §9 open questions split into follow-ups #000034 / #000035 / #000036)
**Opened:** 2026-05-07
**Scope:** Formal threat model + falsifier set for whether training
gradients can route information from training data through soft hashes

View file

@ -0,0 +1,180 @@
# Ticket #000034 — Hessian alignment under φ_linear
**Status:** open · awaiting go/no-go
**Opened:** 2026-05-09
**Scope:** Empirically measure whether the v7 reference
`embed_hard_to_vec` matrix W (frozen-seed linear projection from
SHA-256 digest space → dim_h vector space) has structural alignment
with low-eigenvalue directions of the typical training-loss Hessian.
If yes, the §4 reduction in #000018 is loose under φ_linear and
T2 adversaries can amplify covert-channel steerage beyond the
random-oracle baseline.
**Audience:** maintainers of the v7 plastic-training spec; #000018
follow-up.
**Hard constraint:** measurement-only. This ticket does NOT change
v7 spec or the φ implementation; it produces a residual-channel
bound that informs the M1 (φ_PRG) vs M2 (anchor nonce) priority.
---
## 1. Problem statement
The #000018 analysis (`docs/soft-hash-channel-analysis.md` §4)
shows that under threat models T1 (data poisoner) and T2 (gradient
adversary), the covert channel from training data → committed
hard hash `C(M_{t+1})` is bounded by SHA-256 partial-preimage
hardness — **provided φ is independent of parameter geometry**.
§5.1 flags the v7 reference choice (frozen-seed linear projection)
as not obviously independent. If W's column space aligns with
low-eigenvalue directions of the loss Hessian, the L2 anchor pull
provides cheap parameter movement in directions correlated with
SHA-256 buckets. Cheap = "reachable within a per-step gradient
budget" = exploitable.
This ticket measures whether that alignment exists.
## 2. Design choices
### 2.1 Measurement target
For a representative model checkpoint:
```
W — dim_d × 256 frozen projection matrix
(in v7 reference: digest_as_uint32 → dim_h via
random-seed Gaussian)
H(Θ) — Hessian of L_task at Θ (dim_d × dim_d, symmetric)
{λ_i, v_i} — eigenvalue / eigenvector pairs of H(Θ)
```
Quantity of interest: does W's column space concentrate on the
low-eigenvalue subspace of H(Θ)?
Define **alignment score**:
```
A(W, H) = (Σ_i ⟨W·e_i, v_i⟩² / (λ_i + ε)) / ‖W‖_F²
```
where the sum is over the 256 columns `W·e_i` of W and the
eigenvectors of H, and ε is a small regularizer to avoid
division by 0 on flat directions.
Under random-oracle modeling, A is uniformly distributed across
the eigenvalue spectrum (no preference for low-λ). If A is
concentrated on the low-λ tail, we have evidence of structural
alignment.
### 2.2 Hessian estimation strategy
The Hessian of a 10⁹-parameter model is intractable. Three
approximation choices:
**A. Top-k Lanczos.** Estimate the top-k and bottom-k eigenpairs
via Lanczos iteration. Captures the spectrum's tails — the
ones that matter for the alignment question.
**B. Hutchinson stochastic trace estimator.** Bounds the trace
distribution but doesn't give per-eigenvector alignment.
**C. KFAC / block-diagonal approximation.** Layer-wise Hessian
approximation. Cheap; loses cross-layer structure that may be
exactly where the alignment lives.
**Recommendation:** A. Top-100 + bottom-100 eigenpairs is
empirically tractable on a single GPU for ~10⁸-parameter
checkpoints.
### 2.3 Reference checkpoints
Run the measurement on:
1. v7-reference fresh-init checkpoint (no training).
2. v7-reference after K=1000 steps on a representative task.
3. v7-reference after K=10⁵ steps (mid-training).
If the alignment score remains low across all three, the
structural-alignment concern is empirically dismissed.
If alignment grows during training (e.g., the loss landscape
develops low-λ valleys aligned with W's columns), that's the
exploit pathway and M1 (φ_PRG) becomes the recommended
mitigation.
## 3. Implementation sketch
### 3.1 New script
`bench/scripts/phi_alignment_probe.py`:
```python
def measure_alignment(checkpoint_path, k=100):
# 1. Load Θ, W (from v7 boot manifest).
# 2. Build a small task-loss closure on a fixed eval batch.
# 3. Run top-k + bottom-k Lanczos on H(Θ).
# 4. Compute A(W, H_top) and A(W, H_bottom).
# 5. Emit JSON with eigenvalue spectrum + alignment scores.
...
```
### 3.2 Bench fixture
`bench/fixtures/phi-alignment/sentinel-checkpoint.json` (or
similar) — a deterministic mini-checkpoint we can re-measure
across runs to detect drift in the analysis.
### 3.3 Interpretation thresholds
- A_low / A_uniform ratio > 1.5 → structural alignment confirmed,
M1 (φ_PRG) becomes priority over M2.
- A_low / A_uniform ratio ≈ 1.0 → no alignment, M2 alone is
sufficient.
- A_low / A_uniform ratio < 0.7 φ_linear is anti-aligned with
the loss landscape; the linear projection is actually safe.
## 4. Out of scope
- Full Hessian computation (intractable).
- Implementing M1 / M2 in code (separate tickets).
- Training new models for the experiment (use existing
representative checkpoints).
- Adversarial training that deliberately creates alignment
(out-of-scope; that's an attack-construction experiment, not a
measurement).
## 5. Risks
- **No representative v7 checkpoint exists today.** v7 plastic
training is on the roadmap, not deployed. This ticket assumes
a v7 reference checkpoint becomes available; it parks until
one does. Until then, measurement on a *proxy* checkpoint
(e.g., a small transformer trained with the L2-anchor term
retrofit) lets us derive a preliminary bound.
- **Lanczos convergence on noisy gradients.** Stochastic Hessian
estimation has well-known noise issues; bound calculations
should report confidence intervals.
## 6. Acceptance criteria
1. `bench/scripts/phi_alignment_probe.py` runs against any
v7-reference-shape checkpoint.
2. Output JSON includes per-eigenvalue alignment scores for
top-k and bottom-k.
3. Decision threshold (§3.3) yields one of three verdicts:
`STRUCTURAL_ALIGNMENT`, `NO_ALIGNMENT`, `ANTI_ALIGNED`.
4. Result feeds back into #000018 §9.1 — either closes the
open question (if NO_ALIGNMENT) or escalates the M1
priority (if STRUCTURAL_ALIGNMENT).
## 7. Status
**Open · awaiting go/no-go.** Parks until a v7 reference
checkpoint is available; the analysis is empirical-only and
useless without representative training data. Recommended
deferral to v7 deployment ramp-up.
Closure criterion: `bench/scripts/phi_alignment_probe.py` lands
+ a measurement run against a representative checkpoint
produces a verdict that resolves §9.1 of `docs/soft-hash-
channel-analysis.md`.

View file

@ -0,0 +1,255 @@
# Ticket #000035 — PRG choice for φ_PRG
**Status:** open · awaiting go/no-go
**Opened:** 2026-05-09
**Scope:** Pin a specific cryptographic PRG construction for the
M1 mitigation (PRG-based anchor map) proposed in #000018 §5.2 +
§9.2. The §4 reduction in `docs/soft-hash-channel-analysis.md`
treats φ_PRG as a random oracle; in deployment we need a
deterministic PRG with explicit cryptographic strength assumption.
**Audience:** maintainers of the v7 plastic-training spec; #000018
follow-up.
**Hard constraint:** the PRG security parameter MUST match SHA-256
in the substrate (≥128-bit security level). Adding a weaker PRG
would create a cryptographic-strength asymmetry — adversary breaks
the PRG, channel re-opens.
---
## 1. Problem statement
#000018 §5.2 proposes φ_PRG as the M1 mitigation:
```
φ_PRG(digest) = PRG(seed = published, output_len = dim_h * 4 bytes)
then bytes → floats in [-1, 1]
```
The §4 reduction proves channel-bound under the random-oracle
model for φ_PRG. In deployment, "random oracle" becomes "PRG with
public seed and computational indistinguishability from random."
The reduction holds **modulo PRG security**. Pick a weak PRG and
the reduction's looseness is the PRG's distinguishing advantage.
This ticket pins which PRG.
## 2. Design choices
### 2.1 Candidate PRG constructions
**A. HMAC-SHA-512 expansion.**
```
def phi_prg(digest_32bytes, dim_h):
out = b""
counter = 0
while len(out) < dim_h * 4:
out += hmac.new(seed, digest_32bytes + counter.to_bytes(4, 'big'),
hashlib.sha512).digest()
counter += 1
return bytes_to_floats(out[:dim_h * 4])
```
- **Strength:** HMAC-SHA-512 is a PRF under the standard SHA-512
Merkle-Damgård + HMAC assumption. Distinguishing advantage is
bounded by the SHA-512 collision-resistance bound (~2^256).
- **Dependency:** keeps the substrate's hash family at SHA-{256,512}
— already in the dependency surface.
- **Speed:** ~1 GB/s on a modern x86 CPU; negligible per-checkpoint.
**B. AES-256-CTR with public IV.**
```
def phi_prg(digest_32bytes, dim_h):
aes = AES.new(seed[:32], AES.MODE_CTR, nonce=digest_32bytes[:8])
out = aes.encrypt(b"\\0" * (dim_h * 4))
return bytes_to_floats(out)
```
- **Strength:** AES-256 PRP under the standard AES key-recovery
hardness assumption. Distinguishing advantage bounded by AES key
search (~2^256) under known plaintext.
- **Dependency:** adds `cryptography` package's AES (already in
arborist core deps as `cryptography>=42`).
- **Speed:** ~1.5 GB/s on x86 with AES-NI; faster than HMAC-SHA-512
but the difference doesn't matter at v7 checkpoint cadence.
**C. ChaCha20 with public nonce.**
- **Strength:** ChaCha20 PRF under the cryptographic standard.
- **Dependency:** `cryptography` provides; same as AES.
- **Considered:** redundant with AES — pick one.
**D. SHA-256 as a hash chain.**
```
def phi_prg(digest_32bytes, dim_h):
out = b""
h = digest_32bytes
while len(out) < dim_h * 4:
h = hashlib.sha256(seed + h).digest()
out += h
return bytes_to_floats(out[:dim_h * 4])
```
- **Strength:** **Insufficient.** SHA-256 hash chains are NOT
guaranteed PRFs — known length-extension and predictable
fixed-points make this unsuitable. Reject.
### 2.2 Recommendation
**A — HMAC-SHA-512 expansion.**
Reasons:
1. Tightest dependency: stays inside the SHA family already
committed to by SHA-256 (the substrate's hard-hash). Adding
AES would multiply the assumption surface without
cryptographic gain.
2. Standard NIST-approved PRF construction (SP 800-108
KDF in counter mode using HMAC).
3. Speed parity with AES at v7 cadence (per-checkpoint cost
negligible compared to gradient computation).
4. Provable security reduction: HMAC-SHA-512 PRF security
reduces to SHA-512 collision-resistance, which is structurally
stronger than SHA-256 (output space is 2× larger).
### 2.3 Float conversion
PRG outputs uniform-random bytes. The anchor space is `[-1, 1]^dim_h`.
Convert via:
```
def bytes_to_floats(b):
"""uint32 → float in [-1, 1) via 2 * (u32/2^32) - 1."""
n = len(b) // 4
floats = []
for i in range(n):
u32 = int.from_bytes(b[4*i:4*(i+1)], 'big')
floats.append(2.0 * (u32 / 2**32) - 1.0)
return floats
```
Distribution: uniform on [-1, 1) modulo a 2^-32 quantization
discontinuity; ignored at our precision.
### 2.4 Seed handling
The PRG seed is published (committed in v7 boot manifest). It's
NOT a secret — secrecy isn't the security property. The property
is computational indistinguishability of the OUTPUT from random,
which holds even when the seed is public, because the adversary
can't invert the PRF without solving the underlying SHA-512
problem.
Rotating the seed per-checkpoint becomes the M2 mitigation
(#000018 §5.3) — orthogonal concern; M1 + M2 stack cleanly.
## 3. Implementation sketch
### 3.1 New module
`arborist/v7/anchor_prg.py` (new directory if v7 work hasn't
landed yet; or wherever v7's plastic-training surface is
implemented):
```python
"""φ_PRG — HMAC-SHA-512 anchor map for v7 § 9.10."""
import hashlib
import hmac
PUBLISHED_SEED = b"..." # 32-byte committed seed
def phi_prg(hard_hash_32: bytes, dim_h: int) -> list[float]:
if len(hard_hash_32) != 32:
raise ValueError("hard hash must be 32 bytes (SHA-256)")
block_bytes = dim_h * 4
out = bytearray()
counter = 0
while len(out) < block_bytes:
msg = hard_hash_32 + counter.to_bytes(4, 'big')
out += hmac.new(PUBLISHED_SEED, msg, hashlib.sha512).digest()
counter += 1
return _bytes_to_floats(bytes(out[:block_bytes]))
```
### 3.2 Tests
`tests/test_anchor_prg.py`:
- Determinism: same input + same seed → same output bytes.
- Distinguishing-from-random sanity: chi² test on a sample of
outputs (loose; just catches gross bugs).
- Boundary: dim_h=1, dim_h=10⁶ both produce sensible outputs.
- Seed-change sensitivity: flipping one bit of the seed produces
outputs uncorrelated with the original (Hamming distance ≈
output_size / 2).
### 3.3 Bench fixture
`bench/fixtures/phi-prg/known-answer-tests.jsonl` — fixed
(seed, hard_hash, dim_h) → expected_output_sha256 triples for
regression coverage. Generated once, pinned.
### 3.4 Spec amendment
v7 § 9.10 amendment text:
```
The anchor map φ_PRG(C(M), dim_h) is defined as follows:
Let SEED be the v7 boot manifest's `phi_prg_seed` field
(32-byte committed value).
Let counter range over big-endian 4-byte integers from 0.
Output := concatenate HMAC-SHA-512(SEED, C(M) ‖ counter)
until ≥ dim_h * 4 bytes; truncate.
Convert each successive 4 bytes to a float via
2 * (uint32_be / 2^32) - 1.
The dim_h-vector is the resulting list.
φ_PRG SHALL replace the v7 reference linear projection
embed_hard_to_vec when the M1 mitigation is enabled.
```
## 4. Out of scope
- v7 spec full revision; this ticket lands the §9.10 amendment
text, not the surrounding chapter.
- M2 (per-checkpoint nonce) implementation; orthogonal.
- Empirical Hessian-alignment measurement under φ_PRG (covered
by #000034).
- Performance tuning (PRG eval cost is ~µs per checkpoint;
irrelevant).
## 5. Acceptance criteria
1. `arborist/v7/anchor_prg.py` (or equivalent location) lands.
2. Tests pin determinism + seed-sensitivity + boundary cases.
3. Known-answer-test fixture committed under bench/fixtures.
4. v7 § 9.10 amendment text drafted (this ticket §3.4 is the
draft; final landing waits on v7 spec maintainer review).
5. #000018 § 9.2 closes — the PRG choice question becomes
"HMAC-SHA-512 with 32-byte committed seed."
## 6. Risks / Considerations
- **Future SHA-512 weakness.** If SHA-512 is broken in a way that
affects HMAC-SHA-512 PRF security, the M1 mitigation's
cryptographic foundation cracks. Mitigation: the v7 manifest's
`phi_prg_version` field lets future deployments swap to a
successor PRF without breaking historical replay.
- **Seed compromise.** If the published seed is somehow swapped
by an adversary (e.g., supply-chain attack on the manifest),
the PRG is still PRF-secure but the seed is now adversarial-
controlled. The hard-hash chain (SHA-256 of the manifest)
catches the swap as a chain-break, so this reduces to a
manifest-integrity attack — out of scope for #000018, in
scope for chain-check.
## 7. Status
**Open · awaiting go/no-go.** Doc-only spec amendment + reference
implementation. Lands when v7 plastic-training has a deployment
target.
Closure criterion: `arborist/v7/anchor_prg.py` ships, tests pass,
known-answer-test fixture pinned, v7 § 9.10 amendment text
accepted into the v7 spec.

View file

@ -0,0 +1,229 @@
# Ticket #000036 — T3 per-window covert-channel budget bound
**Status:** open · awaiting go/no-go
**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
**Open · awaiting go/no-go.** Doc-only formal-derivation +
calculator script. Lands when #000018's other follow-ups
(#000034 + #000035) have either resolved or been parked —
the T3 bound's value depends on M2 being the chosen
mitigation.
Closure criterion: bound landed, calculator works against named
inputs, #000018 §9.3 closes.