# render — what a renderer actually materialized
A plan names what should exist before any target syntax does.
A rendering records what a renderer actually produced.
This boundary keeps intention and material separate.
The renderer receives planned authority, offers typed token trees under declared seats, and receives materialized units whose identities and digests are taken from those exact trees rather than supplied beside them.
## Authority in
The plan is the only source of a unit's semantic key, profile, origin, publication address, and digest contract.
The renderer names a seat and offers the token tree produced for it.
The sink joins those two authorities, so a call site cannot pair one seat's tree with another seat's planned facts.
A seat the plan did not declare cannot become a rendered unit because it offers no planned member to materialize against.
## Material out
A rendered unit carries the planned facts it answers to, the tree actually produced, its identity, and the digest of its canonical bytes.
The tree remains the sole holder of those bytes; inspection text is a human projection and never material read back into a decision.
A rendered projection is the non-empty, bounded sequence of units one renderer wrote.
It preserves rendering order as observation material while also offering roster-ordered readings to the proof and delivery owners downstream.
The canonical-byte ceiling is derived from declared token-source magnitudes rather than fitted to one current projection catalog.
Exact boundary controls establish the renderer's own admission law, while one catalog-bearing maximal-load recipe crosses the grammar's interacting top-level maxima with explicit headroom and each independent count maximum has its own boundary witness.
Growth in a projector or an admitted grammar maximum therefore reaches a tracked witness before it reaches an adopter as an unexplained resource refusal.
## Composition
The request road gives the renderer a sink over one plan and then hands the finished rendering to closure.
Closure reconstructs the plan membership from the units, settles missing or doubled seats, proves every digest, and owns delivery joins.
Explanation reads the proved rendered roster only after that agreement exists.
Keeping those acts in later homes is load-bearing.
A sink that rejected a missing or doubled seat would be attempting to prove the rendering while it was still being written.
## Trust ceiling
This home establishes that every unit was materialized from a member the plan declared and that its identity and digest name the exact tree it carries.
It does not establish that the complete planned roster was filled, that a seat was filled only once, that a publication address is unique, or that any delivery is ready to emit.
Those are closure questions over the complete rendering and plan.
It also does not interpret generated syntax, prove semantic correctness of the caller's renderer, join units into deliveries, emit tokens, or decide repairs.
## Refusal boundary
Rendering stops at the first local impossibility: no material was written, a seat has no planned member, or a declared rendering magnitude would be exceeded.
Each refusal remains an ordinary typed error and projects through the shared diagnostic road without inventing related issues or ownerless repair advice.