Part I — The Shape of Data · seven builds, seven receipts
The chapter's spirit: every claim it makes about \(\sigma_0\), \(\delta\), and fiber widening has a harness behind it. Your exercises rerun that harness, vary it, and break it on purpose — the receipts you produce should look like the chapter's BLD-SEC-* lines.
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).
—
E2.1Reproduce the worked example
Build
Check out gigi at 66f18a0, stand up a sensors bundle with the prologue's key and the chapter's three defaults (temperature=20.0, humidity=40.0, status=ok), insert the two session records, and call deviation_norm on each.
Receipt
Your stdout matches the BLD-SEC-WORKED-TDD block byte for byte: s-001 -> deviation_norm = 0 and s-002 -> deviation_norm = 2. Archive your harness next to harvest/book_ch2_worked_example.rs.
Bonus
Insert a record with all three fields deviating, confirm \(\|\delta\|=3\), and explain in one log line why TDD-1.4 is not also pinned by the spec.
E2.2Instrument the absent-section convention
Build
Add a unit test against src/bundle.rs:2893-2904 that calls deviation_norm on a BasePoint never inserted, then on the same point after inserting the schema's defaults verbatim. Both should return 0; the engine must distinguish them somewhere else.
Receipt
A passing test tdd_devnorm_absent_vs_default_zero that asserts get_fiber(bp).is_none() for the first case and is_some() for the second — proving an empty bar and a played-as-written bar share a norm but not a storage state.
Bonus
Add a Prometheus counter on get_fiber miss-vs-hit and scrape /v1/metrics to show the two cases diverge in the gauge.
E2.3Replay fiber widening on your own bundle
Build
Take any non-sensors bundle you have lying around (or stand up a fresh orders), insert a few records, then call add_field (src/bundle.rs:3727-3755) with a new column and a declared default. Read every old record back.
Receipt
The widened zero_section() prints with the new coordinate appended; every pre-widening record reads back at exactly that default on the new field; deviation_norm for those records is unchanged. Capture the before/after as a single log block in the BLD-SEC-WIDENING format.
Bonus
Time the add_field call against \(N\in\{10^3, 10^5, 10^6\}\) stored records and plot the \(O(N)\) in-memory extension. I claimed it ships as an eager linear pass — show me your slope.
E2.4Benchmark the DHOOM dividend against the histogram
Build
Run the chapter's employee dataset (the ten records I measured for BLD-SEC-HISTOGRAM, modal defaults) and a second dataset where every field has a declared default matching a near-universal mode — e.g.\ an IoT bundle whose status is ok 99% of the time. Encode both with dhoom::encode_json and compute bytes-saved-per-record.
Receipt
Two histograms of \(\|\delta\|\), two compression ratios, and one sentence that names which dataset's measure concentrates near \(\sigma_0\). The employee numbers should reproduce my \(\{2:7, 3:3\}\) histogram.
Bonus
Find or synthesize a dataset where the deviation-norm histogram is flat across \(0,\ldots,k\) and confirm DHOOM stops paying — the formalism still holds, the dividend does not.
E2.5Refute (or confirm) that DHOOM calls zero_section
Build
Grep src/dhoom.rs for any reference to zero_section, then trace how the encoder actually picks its per-document baseline. Write the trace up as a one-page note.
Receipt
Your grep matches my 2026-06-12 result (no hits) or has changed since — either way, name the function in dhoom.rs that selects the modal value written to the header, and cite the file:line. If the spec's line 37 has been wired up since I checked, that's the receipt; if not, the trace is.
Bonus
Open a PR that adds a feature-flagged path dhoom::encode_json_against_schema which uses the declared \(\sigma_0\) as the baseline, and measure the byte delta on the employee dataset versus the data-derived baseline.
E2.6Stress-test the section contract
Build
Forge a record whose stored key disagrees with the BasePoint it's filed under — bypass the public Store API and write directly through whatever the lowest-level insert path exposes in src/storage/types.rs. Then call integrity::scan (or whatever the engine's audit hook is named at your SHA).
Receipt
The audit flags the violation as a \(\pi \circ \sigma \neq \mathrm{id}_B\) failure with the exact base point in the log line. If the engine currently accepts the corrupted insert silently, that itself is the receipt — file an issue citing Definition 1.2.
Bonus
Add a debug-mode invariant check that runs \(\pi \circ \sigma\) on every put and panics on disagreement; show the new test catches your forged record.
E2.7Wire the three verbs to one Store
Build
On a bundle you control, hit each of SECTION, NEAR, HOLONOMY, and CURVATURE on src/bin/gigi_stream.rs against the same base point. Verbs without implementations should return a clean error; verbs with implementations should return values traceable to a method on the underlying Store.
Receipt
A table of {verb, HTTP status, response shape, backing Store method} — four rows, with the unimplemented verbs honestly marked. This is the engineering version of the chapter's claim that those verbs “stand on” the four definitions.
Bonus
Pick the cheapest unimplemented verb on your SHA, wire a stub that returns \(\|\delta\|\) for CURVATURE as a placeholder, and document why that's wrong — second differences, not first — in the doc comment.