Module render 

Rendering the experiment pool for a model to read.

MCP carries text. There is no structured result a client will render for us, so the text is the API: what these functions emit is what the model sees, and its shape decides whether the model can follow a lineage, compare two runs, or notice that it is looking at a dead end.

Three rules hold everywhere below.

• Every result ends with a next: line. A model that has just read a hit should not have to guess what the follow-up call is named or which argument it takes.
• Every experiment shows its run_dir. The pool summarizes; the run directory has the events, the diagnostics and the figures. A model with file tools can go and read them.
• Absence is stated, never faked. “no conclusion recorded” is a useful sentence; a blank line is not.

Every function here is pure — a value in, a String out — so the output is snapshot-tested rather than merely eyeballed.

Functions

branched

Confirmation for kb_branch_from.

conclusion_recorded

Confirmation for kb_record_conclusion.

diff

Two experiments side by side: what changed, what it did to the metrics, and what it cost.

find_similar

Ranked hits for kb_find_similar.

lineage

A lineage tree with the move on every edge — the whole point of recording derivations rather than only parents.

render_pipeline_run

One pipeline run, as the model reads it.

render_study_run

One study, as the model reads it.

stats

Orientation, with honest coverage: how much of the pool actually carries the things the other tools depend on.

summarize_run

A run directory summarized on demand — works on runs recorded long before the pool existed.