The Postgres seam: translate a Postgres plan tree — the map produced by EXPLAIN (FORMAT JSON) — into a chip plan consumable by schedule/schedule, cluster/admit and schedule/run-plan. Pure data in, pure data out; a live database is needed only to produce the JSON.

This is the host-side half of the essay’s split: Postgres parses, rewrites and optimises SQL into a plan tree; this namespace lowers the offloadable fragment of that tree to the chip’s operator graph. What cannot be lowered refuses the whole plan ({:ok? false :reason ...}) — per-subtree partial offload is a later slice.

Postgres chip Seq Scan + Filter ─▶ :scan :preds Hash Join (Inner) ─▶ :join-build (inner) + :join-probe Aggregate (Plain) ─▶ :reduce (fn parsed from Output) anything else ─▶ refusal naming the offending node

Filters are Postgres’s own expression strings (“((amount >= 100) AND (amount <= 500))”); a small recursive-descent parser lowers col OP int comparisons, AND-chains, redundant parens and integer casts, and refuses OR/NOT, function calls, string literals (dictionary encoding is a later slice) and column-to-column comparisons.

Modeling approximation, stated plainly: chip lanes carry a single column (the join/group key). Filters on other columns are accepted, but the reference treats the lane value as the key — real integration pre-projects the key column on the host.