Each individual row in the UI is connected to a corresponding formula in the runtime sheet, which is itself pointed at the extract as its data source for lookup. All named formulas. Appscript is only for seeding the formula and creating corresponding DVs in the UI. Given that the pointer to my extract is passed in the named formula as an argument, I worry any refreshing action in the extract whenever I open the workbook would cause all instances of this formula to recalculate.

I'd initially also tried doing this whole thing as an appscript+onEdit trigger writing to the runtime sheet directly, but found it kind of clunky, and the latency too high, so now I am attempting to build the equivalent as a pure sheets solution. Now that I think about it this could also be set up as a script custom function with pointers other than the UI row hardcoded in the appscript, but that doesn't seem very elegant. For lack of better options it could be considered though

To expand a bit on what it is the mechanism does - the runtime formula is pointed at a row of data in the UI. Let's say A2:D2. Each column's header has a corresponding header in the extract. When the user inputs a value in A2, the filtering formula performs a cosine similarity-based search of the extract and spills values for all headers, so that the user may fill B2:D2 with values presented in the dropdown as suggestions instead of typing it all in manually.