Part I — The Shape of Data · seven builds, seven receipts
These are bench-and-harness exercises: the chapter ships four tests, one avalanche measurement, one O(1) bench, one worked walk, and one named gap, and every experiment below is either a re-run, an extension, or a stress of one of those. Receipts you produce should look like the chapter's own — a passing test name, a numeric line from a harness, a ratio against a baseline, or a delta against the published BLD-* ledger entries.
Run it live — GQL console
Point at the public read-only instance (no key needed) or your own engine
(start it with GIGI_CORS_ORIGIN=* for browser access — dev only).
—
E3.1Reproduce BLD-HASH-SUITE-4 and BLD-O1-BENCH
Build
Clone gigi at commit 66f18a0, run cargo test --lib hash:: and cargo run --release --bin bench_o1, and capture both outputs into a local harvest/repro_ch03.txt.
Receipt
Suite line 4 passed; 0 failed from src/hash.rs:156--230 and a four-row \(N \in \{10^3,10^4,10^5,10^6\}\) table where every ratio prints pass under the bench's \(1.5\times\) ceiling. Diff your ns/query column against my \(\{623.4, 785.6, 1145.4, 1371.4\}\) on src/bin/bench_o1.rs; if your slope curve has a different cache knee, write one line saying which \(N\) moved and how much.
Bonus
Re-run with taskset/cpu-affinity pinned to one core and report whether the \(N=10^5\) wobble shrinks.
E3.2Re-measure avalanche on a fork of the mixer
Build
Copy harvest/book_ch3_avalanche.rs as book_ch3_avalanche_v2.rs, change one multiplicative constant in wymix or wy (try replacing 0x94d049bb_1331_11eb with another odd 64-bit constant), and run 2,048 keys \(\times\) 64 single-bit flips \(= 131{,}072\) experiments.
Receipt
A printed mean Hamming distance, plotted against the BLD-HASH-AVALANCHE value of \(32.0032\). Anything outside \(32 \pm 0.05\) means your constant degrades the quotient; report it as a refutation rather than a fix.
Bonus
Try an even constant. The mixer should visibly break — show me the broken number.
E3.3Stress the rotation constant 17
Build
Fork HashConfig::hash at src/hash.rs:81--99, replace the (i as u32 * 17) % 64 with each of \(\{0, 1, 8, 17, 32, 64\}\), and run tdd_1_6_composite_key plus a custom composite-key avalanche harness (3-field key, single-bit flips across all fields).
Receipt
A table of (rotation constant, composite-key avalanche mean, tdd_1_6 pass/fail). The chapter claims \(\gcd(17,64)=1\) is what makes the rotation visit all 64 shifts; your row for rotation \(=0\) should show (a,b) and (b,a) colliding and the test failing.
Bonus
Find the worst non-zero rotation constant under 64.
E3.4Forge the missing collision fallback
Build
In a branch, extend BaseStorage::Hashed at src/bundle.rs:195--200 with a secondary HashMap<Vec<u8>, BasePoint> keyed by the composite-key bytes from encode_value. On insert, if the BasePoint slot is occupied AND the existing key bytes differ from the new ones, redirect to the secondary map. Wire a tdd_1_8_collision_fallback that forces a same-BasePoint collision by patching a test HashConfig to return a fixed value, then asserts both records survive.
Receipt
New test green; existing cargo test --lib hash:: still 4 passed; chip task task_fda0056d referenceable in the commit message. This closes BLD-HASH-COLLISION-GAP as designed in Remark 1.1.
Bonus
Add a Prometheus counter gigi_hash_collision_fallback_hits_total and scrape it from /v1/metrics.
E3.5Benchmark the single-integer fast path against the general path
Build
Add a benches/hash_fast_path.rs (or extend benches/o1_proof.rs) that runs \(10^7\) iterations of HashConfig::hash on a one-field integer schema versus the same many iterations of HashConfig::hash_int_fast from src/hash.rs:73--79.
Receipt
Two ns/op numbers, plus a bit-equality assertion: hash_int_fast(42) must equal 0x5640fadf718bdd6b, matching the BLD-HASH-WORKED-WALK line. If the equality breaks, your build is wrong — not the chapter.
Bonus
Profile the general path with cargo flamegraph and confirm the Vec allocation in encode_value is the dominant cost the fast path bypasses.
E3.6Replay the worked walk on a key of your own
Build
Adapt harvest/book_ch3_worked_example.rs to walk your key (any integer or a 3-field composite) through encode \(\to\) seed \(\to\) wy per field \(\to\) rotated XOR \(\to\) finalize, printing every intermediate as the chapter does for id=42.
Receipt
The walked final value must equal HashConfig::hash for the same record and schema; the harness must assert_eq! the two and exit zero. Archive the run to harvest/walk_<yourkey>_<date>.txt.
Bonus
Pick a negative integer; verify the sign-bit flip in encode_value produces the byte that the upcoming Part II range scanner will sort correctly.
E3.7Stress cross-bundle non-collision
Build
Create \(1{,}000\) bundles with schema name "test_<i>" for \(i \in [0, 1000)\), hash the same record id=42 in each, and collect the \(1{,}000\) BasePoints into a set.
Receipt
Set size \(= 1{,}000\), zero collisions, demonstrating BLD-HASH-CROSSBUNDLE at population. Print the two-bundle pair I shipped (0x5640fadf718bdd6b for "test", 0x9a40c5de4c63820d for "test2") as the first two rows to confirm your build agrees with mine.
Bonus
Now rotate the base seed via from_schema_with_base_seed and confirm all \(1{,}000\) addresses move — the forward-secrecy property §3.4 stages for Part VI.