diff --git a/docs/developer-guide/filter-pre-edit-hook.md b/docs/developer-guide/filter-pre-edit-hook.md
index 312ab6d..5d48f94 100644
--- a/docs/developer-guide/filter-pre-edit-hook.md
+++ b/docs/developer-guide/filter-pre-edit-hook.md
@@ -144,9 +144,9 @@ The captures below are the editor for a table with an `ORDER_DATE` column, opene
 
 The user's clause and Data Controller's clause have to be kept apart, because Row Level Security lives in the second one. Combining them as `( user OR previous-quarter ) AND ( validity + RLS )` keeps RLS applied to both branches. Wrapping the whole existing filter instead - `( existing OR previous-quarter )` - would let the previous-quarter rows through without their RLS condition, so do not take that shortcut.
 
-## The row cap
+## The row and cell caps
 
-`getdata` truncates a result larger than `DC_MAXOBS_WEBEDIT` (250 by default) or `DC_MAXCELLS_WEBEDIT` to the rows within the limit, and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap - the rows past the limit never reach the browser. Check the count before handing the data back, or raise the option for that table in `MPE_CONFIG`.
+`getdata` truncates a result over either `DC_MAXOBS_WEBEDIT` or `DC_MAXCELLS_WEBEDIT`, whichever binds first - a wide table runs out of cells before rows, at floor(cells / columns) rows - and warns against the table name. Widening a filter widens the result, so a hook that adds a quarter can push a table over the cap: the rows past the limit never reach the browser. Check both counts before handing the data back, or raise the options for that table in `MPE_CONFIG`.
 
 ## Matching the filter chips
 
diff --git a/docs/developer-guide/two-rule-sets-one-table.md b/docs/developer-guide/two-rule-sets-one-table.md
index ddfa32a..ebc3196 100644
--- a/docs/developer-guide/two-rule-sets-one-table.md
+++ b/docs/developer-guide/two-rule-sets-one-table.md
@@ -109,7 +109,7 @@ From that moment the changeset is an approval against `ORDERS.ORDERS`. The appro
 ### Other things to watch
 
 - Concurrency behaves correctly here. Both mirrors route their submit to the same base table, so every approval locks, loads and logs against one identity - unlike the two-libref route above.
-- The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` cap truncates the edit screen, with a warning against the table name. [Updating the Filter in a Pre-Edit Hook](/developer-guide/filter-pre-edit-hook/) works through extending that filter.
+- The filter has already been applied to the empty mirror by the time the pre-edit hook runs, so a hook that reads the real table ignores the user's filter unless it re-applies it (`where %inc filtref`). On a small table you will not notice; on a large one the `DC_MAXOBS_WEBEDIT` or `DC_MAXCELLS_WEBEDIT` cap truncates the edit screen, with a warning against the table name. [Updating the Filter in a Pre-Edit Hook](/developer-guide/filter-pre-edit-hook/) works through extending that filter.
 - The hook's output must have the same columns the editor expects - the real table, minus any transaction or processing columns that Data Controller drops on load.
 - The real table must itself be registered in `MPE_TABLES`. The approval screen resolves the table's audit settings from that row, so a changeset routed to a table with no registration cannot be reviewed - the submit is refused up front, naming the table.
 - The mirror's `MPE_TABLES` row is read for the edit screen and the real table's for the load, so keep their `buskey`, `loadtype` and temporal column settings identical.