The Reference-Data Problem

Every engineering, finance, or analytics report leans on a quiet pile of reference data. Steel section properties. Soil bearing capacities. Discount rates by region. Material unit costs. Tax codes. None of it is the point of the report — but it's the input that every real number in the report depends on.

The traditional pattern is ugly: keep the reference table in a separate spreadsheet, look up the row you need, and type the value into your document. If the source table updates, you find every place you used it and retype. If you typed the wrong row, the whole calculation downstream is wrong and there's no audit trail back to the lookup.

GridDoc handles this the way a spreadsheet always has — with VLOOKUP — except the lookup table doesn't have to live in another file. It can sit on the canvas, in a block right next to the calculation that uses it.

How VLOOKUP Works on the Canvas

GridDoc's formula engine treats every block as addressable. A table block with material properties is just as referenceable as a single cell. So VLOOKUP works the same way it does in Excel — give it a lookup value, a range, a column index, and an exact-match flag — but the range can be a different block on the same page, on a different page, or in a different region of the spatial canvas.

The pattern is:

1. Drop a table block with your reference data — say, a list of W-shape steel sections with their Sx, Zx, Ix, and ry values.
2. In a formula block elsewhere on the canvas, write =VLOOKUP("W12X26", SteelSections, 3, FALSE) to pull a specific value out.
3. The result updates live. If you correct a value in the reference table, every formula that looked it up recalculates.

You can name the block (SteelSections) so the formula reads cleanly, or reference it positionally if you prefer.

Why This Matters in a Document

In a spreadsheet, this is unremarkable — VLOOKUP has been there since 1985. The shift is that it works inside the document you actually deliver. Reviewers can see exactly which row of the lookup table fed the calculation. They can change a row in the table and watch the affected numbers update on the spot. They never have to chase down "where did this 2.93 come from?" — the lookup is right there.

A few concrete patterns that fall out of this:

• Material library at the top of a calc package. One table of section properties, referenced by every member design block below. Swap a section, the whole package recalculates.
• Unit conversion table. A small reference block that maps imperial to metric. Every conversion in the document pulls from it. No more drift between sections that converted independently.
• Code-mandated factors. Wind exposure factors, seismic site classes, load combinations — values that come from a code table. Put the relevant subset of the table in the document, look up the row that applies, and the source is documented inline.
• Cost or rate tables for financial reports. Regional discount rates, currency conversions, tax brackets — looked up by row, never copy-pasted.

A Note on the Other Lookup Functions

VLOOKUP is the most common, but the same model applies to HLOOKUP, INDEX/MATCH, and lookup-by-name patterns. Anything that resolves to a value in a table block can feed a formula anywhere else on the canvas. The cross-block reference is the underlying mechanic; VLOOKUP is just the most familiar way to use it.

Try It

If you've ever maintained a spreadsheet and a Word doc in parallel because the spreadsheet had your lookup tables, try moving the lookup table into a GridDoc block instead. The calculation, the reference data, and the narrative end up in the same file — and stay in sync without you doing anything.

Open a GridDoc and try it — drop a table block, name it, and reference it from a formula block somewhere else on the canvas.