> For the complete documentation index, see [llms.txt](https://docs.openbrim.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openbrim.org/quick-guides/design-results-from-the-spreadsheet.md).

# Design Results from the Spreadsheet

Code checks can be designed **one row at a time from the spreadsheet**, and their results read three ways without opening a report: as a **cell** in the sheet, as a **colour** on the 3D model, and as a **value chip** on each painted member. The traditional **Design** button (whole project) still works and fills the same cells and paint.

{% hint style="info" %}
This works for any object type whose library definition declares result columns (in the building library today: column, beam, wall and punching code checks, slab strips and slab rebar zones). Nothing is specific to D/C — a type declares which of its results are shown and how.
{% endhint %}

## 1. Run the analysis first

Design reads analysis results, so run **Analyze** (or accept the previous results after a reload) before designing. If design cannot run yet, a notice says why instead of running:

* *"The analysis results are not loaded - an edit unloads them. Use the analysis button (Analyze, or View FEA when stored results were found) > Use Previous Analysis Results, in the 3D view alone or the FEA view, or run the analysis again, then design."* The analysis button is on the card at the top left of the 3D view and the FEA view; it is not shown while the 2D plan is on screen.
* *"The compiled model is waiting to be loaded. Click Load Model (in the 3D view alone or the FEA view), then design."*
* *"The compiled model is loading. Wait for it to finish, then design."* or *"The model is not compiled yet."*: design runs once the compile is done.
* *"The model did not compile. Fix what the compile reported, then design."* (or *"... some inputs failed validation. Fix them, then design."*)
* *"There are no analysis results. Run the analysis first, then design."*
* *"The analysis results are out of date. Run the analysis again, then design."*

The check is never started for you. An edit to a check row, its template, a slab strip or a slab rebar zone does **not** invalidate the analysis; an edit to the structure (a column size, a load) does, and every row on that analysis is then marked as not current.

## 2. Design a row

Open the code-check sheet (e.g. **Code Checks → Column Code Check**). The result columns sit at the right of the input columns: **D/C**, **Axial D/C**, **Shear D/C**, … for a column or wall; **D/C**, **Flexure D/C**, **Shear D/C**, **Torsion D/C** for a beam.

Slab design has two sheets, and only one of them is a check:

* **Slab Design → Slab Strip Results** — what each design strip needs: **Required Top Steel**, **Required Bottom Steel**, **Top Design Moment**, **Bottom Design Moment** and **Shear**, each the largest value along the strip. A strip takes no bars and has no D/C.
* **Slab Design → Slab Rebar Zones** — the check. On the **Reinforcement** tab the bars you enter sit beside **D/C**, **Top D/C**, **Bottom D/C**, **Required Top Steel** and **Required Bottom Steel**. Designing a zone designs the strips it reads with it, so a zone row can be designed on its own.

1. Right-click a row (or a selection of rows) → **Design** / **Design N Rows**. Only those rows are extracted and designed — a few rows take about a second; the whole sheet is the traditional cost.
2. The cells fill as each row finishes. A cell reads:
   * a **number** — designed on the current analysis and current inputs (red when over the limit);
   * a grey italic number with a **stale** tag — it was designed, but the row, its template, the member or the analysis changed since; right-click → **Design** to refresh it;
   * *run analysis* / *not designed* — nothing to show yet.
3. **Open Detailed Report** on a row opens that check's own report (designs it first if needed).

The **column header** menu of a result column offers **Design all N rows** and **Design the M rows that are not current**.

## 3. Paint the model by a result

Right-click a result cell or its header → **Paint 3D by \<column>**.

* Each member the row is about is coloured on its value, on a scale whose limit is an **edge** of the palette (green … orange below the limit, red above it). **A member that fails is red**, also when its number is under the limit (it fails something the ratio does not measure) or when it has no number at all (a rebar zone with no bar). Members without a current value are grey, everything else is ghosted, and the legend says how many rows are current: *"D/C - 12 of 95 current"*.
* A **slab strip** is drawn as a **diagram along the strip**: a line on the slab coloured by the value at each design station, with the value standing up from it as a ribbon. The two strip directions stay separate lines.
* A **slab rebar zone** is drawn as a **patch on the slab**, filled in the colour of its value. Where two zones overlap — the two bar directions over one column — a failing zone shows over a passing one, and otherwise the larger value. A zone that fails has a red outline; one that fails without a number (no bar where steel is needed) is red and prints no value. Hover it for the reason. A uniform mat has no patch of its own; it colours the slab.
* **Value chips** print the number on each painted member (at each strip's governing station, inside each zone's patch). Over-limit values are red; stale ones italic. Where chips would overlap, the worst values win; zoom in to see the rest. **Show/Hide Values in 3D** on the same menu toggles them.
* **Hover** a painted member to read its result. On a strip's diagram the plate gives the value at the station under the pointer and the strip's largest value; on a zone's patch it gives that zone's results, and the zone is outlined.
* **Click** a painted member, diagram or patch to open its detailed report.
* Selecting a row in the sheet highlights it in 3D (a ring on a column; the strip's band or the zone's outline on a slab).
* **Clear 3D Paint** restores the model.

## 4. Export

Result columns are exported to Excel with the sheet: a current value as a number, a stale one as *"\<value> (stale)"*, an undesigned cell blank.

## 5. From an AI agent

The desktop app's MCP tools cover the same flow: `design_objects` (design the given rows), `get_design_results` (read every result column of the given rows with its state), and `paint_design_results` (paint by a column, `values` for the chips, `clear: true` to remove). The same actions are available to any RunAction client as `RunDesignFor`, `GetUnitResults`, `PaintUnitResults` and `ClearResultPaint`.

## For library authors

A result column is a `<O T="DesignResult">` in the row type. It is written like a parameter — `N` is the column, `D` the header, `V` the number — and it is not one: nothing is materialised on the instance, saved, or evaluated at compile time. Every path is relative to the design object.

```xml
<O N="DesignResults" T="Group">
    <O T="DesignResult" N="cc_dc" D="D/C" V="RCCC.GoverningDCRatio" Limit="1"
       Pass="RCCC.PassFailResult" Obj="ccColumn" Report="RCCC.ColumnDesRep" />
</O>
```

* `V` — the path (through the row's `T="DesignRun"` object) to the number the cell shows.
* `Limit` — the pass/fail edge of the paint scale; `D` — the column title; `Category` — the sheet tab (default General).
* `Pass` — the calculator's own 1/0 verdict: 0 marks the cell, chip and hover as **fail** whatever the number is, and the member is painted red. `Valid` / `Status` — a 1/0 "the check ran" flag and the text to show when it did not (a strip with design strips off is *failed: NOT CHECKED …*, not a green 0). `Fail` — a 1/0 flag read when `Valid` is 0: 1 says the missing number is itself the failure (demand and no bar), so the paint draws the member red instead of leaving it grey.
* `Obj` — what the row is about, i.e. what is painted and highlighted (`ccColumn`, `ccWallSegment.LinkedSW`, `ccSlab.sl_slabpieces`). `Unit` — the design object when the row is not it.
* `Report` — the Document opened by *Open Detailed Report* and by a click on the paint.
* For a result **along a line** (a slab strip): `Field` (the per-station values), `Points` (their \[x,y] positions, in order along the line), `Mask` (1/0 per station), `Layer` (a key such as the strip direction) and `Width` (the band width drawn when the row is selected).
* For a result that belongs to a **patch** of the object it is drawn on (a slab rebar zone): `Region`, the path to a plan polygon. An empty region colours `Obj` whole.
* `Needs` — the objects whose analysis results this result reads besides the row's own (a rebar zone reads its slab's design strips). Designing the row designs those with it, and a change to one of them makes the row stale. Point both `Needs` and `Region` at **exported** parameters: they are read for every row after every edit, and a parameter that is not exported makes the reader build the row's whole library definition first.

See `docs/plans/on-demand-design-results.md` in the platform repository for the design notes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openbrim.org/quick-guides/design-results-from-the-spreadsheet.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
