The dump is the referee

Every chapter before this one taught you to read something the compiler or the runtime already produced: a dump, a header, a trace. This one asks you to produce something instead. Pick one of the three projects below, and the deliverable is yours to ship, not ours to hand you.

The standard is the same one this whole site holds itself to: a claim without a dump or a measurement behind it is not a claim, it is an assertion. Every one of the three projects ends the same way, with a write-up someone else could check against your evidence without having to take your word for it.

Implement the minimal PJRT C API surface, following the integration guide, until jax.devices() on your machine actually sees a device you built. You will not write a fast backend; you will write the smallest one that compiles and runs at all, filling in the struct-of-function-pointers chapter one introduced with real, if trivial, implementations.

The deliverable is the repository plus a write-up of every struct you had to fill in and why, in the order you filled them. That ordering is the real artifact: it is the map of what PJRT actually requires from a backend, stripped of everything a mature plugin adds on top.

Pick one program relevant to a model you actually care about, and dump it with every pass, the same flags chapter four taught. Then read the whole dump, start to finish, and annotate the ten passes that changed the program the most.

The deliverable inlines before-and-after excerpts for each of those ten passes and does the arithmetic on what moved: bytes written, bytes read, in the same spill-style accounting chapter three's metadata and chapter six's buffer assignment set up. A reader should be able to follow your ten annotations and understand the compile the way you do, without opening the dump themselves first.

Pick one fusionSeveral ops compiled into one kernel so intermediates stay in fast memory instead of round-tripping through HBM. XLA’s central optimization, with an exact limit.taught in /l/xla → decision from this site's own fusion x-ray and reconstruct why the compiler made it, arguing from the policy chapter five laid out, profitability and fusibility, not intuition about what looks efficient.

Then verify your reconstruction the only way that counts: dump the same program with --xla_disable_hlo_passes=fusion, measure both versions on whatever backend you have, and report the difference. If your reasoning about why the compiler fused what it fused is right, disabling fusionSeveral ops compiled into one kernel so intermediates stay in fast memory instead of round-tripping through HBM. XLA’s central optimization, with an exact limit.taught in /l/xla → should cost exactly what your argument predicts.

Whichever project you pick, the bar is identical: every claim in your write-up is carried by a dump or a measurement with its provenance stated, chip, dtype, shapes, method, the same discipline every gate on this site has held to since chapter one. Ship the deliverable, then hand the write-up alone, with no verbal explanation, to someone else and watch whether they can reproduce one number or one dump from it. If they can, the write-up did its job. If they cannot, the gap is the next thing to fix, not the deliverable to declare finished.