> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bedrock.cv/llms.txt
> Use this file to discover all available pages before exploring further.
# Grid System
> The universal coordinate system for cross-discipline coordination.
The **Grid** is a building's coordinate system. Grid lines (A, B, C / 1, 2, 3) are shared across every discipline and every floor in a drawing set. Grid intersection "B-3" refers to the same physical location on the architectural, structural, mechanical, electrical, plumbing, and fire protection sheets.
This is how trades coordinate: "the duct at B-3 clashes with the beam at B-3."
## Three models
The grid system uses three entities:
| Model | Scope | Description |
| ----------------- | ------------- | --------------------------------------------------------------------------------------- |
| **Grid** | Project-level | A named grid system for a building. One per building, multiple for campus projects. |
| **GridLine** | Grid-level | A single named line: `"A"` (vertical) or `"3"` (horizontal), with sort order. |
| **BlockGridLine** | Block-level | Maps where a grid line appears visually on a specific VIEW block (normalized position). |
A project can have **multiple Grids** -- for campus projects with multiple buildings, buildings with rotated wings, or additions. Each Grid is an independent coordinate system. Within a single building, the grid is the same on every floor (it extrudes vertically through the structure), so a 50-story building still has one Grid.
## Cross-block alignment
Grid lines serve as **shared control points** for aligning coordinates across different blocks. When Bedrock detects grid lines on a VIEW block, it creates BlockGridLine entries recording each grid line's normalized position (0-1000) within that block.
Two blocks that share the same GridLines can be spatially aligned by mapping through these control points.
```
Mechanical Plan (M-101) Structural Plan (S-201)
+------------------------------+ +------------------------------+
| A B C | | A B C |
| | | | | | | | | |
| | duct--+--------| | | | | beam | |
| | | | | | | |========| |
| | | | | | | | | |
+------------------------------+ +------------------------------+
BlockGridLine entries: BlockGridLine entries:
GridLine "A" → position: 100 GridLine "A" → position: 120
GridLine "B" → position: 400 GridLine "B" → position: 420
GridLine "C" → position: 700 GridLine "C" → position: 720
```
Both blocks reference the **same GridLine records** ("A", "B", "C"). The shared grid lines act as anchor points for computing an affine transform between the two blocks' coordinate spaces.
## How alignment works
To check if a duct on M-101 clashes with a beam on S-201:
1. The duct Feature on M-101 has `bounds` at position 350-650 (between grid A and C)
2. The beam Feature on S-201 has `bounds` at position 420-720 (between grid B and C)
3. Using shared grid lines as control points, compute an affine transform between the two coordinate spaces
4. Map the duct's position into the structural block's space
5. Detect that they overlap near grid B -- potential clash
This works across:
* **Different disciplines** on the same floor (architectural vs structural vs MEP)
* **Different floors** of the same building (same Grid, different sheets)
* **Different revisions** of the same sheet (grid lines are stable across revisions)
Grid-based alignment is more robust than pure image alignment because grid lines are **semantically meaningful** anchors. They do not shift between revisions or vary between disciplines the way drawing content does.
## Key fields
### Grid
| Field | Type | Description |
| ------------ | ------- | ----------------------------------------- |
| `id` | string | Unique identifier |
| `project_id` | string | Parent project |
| `name` | string? | Display name (e.g., "Main Building Grid") |
### GridLine
| Field | Type | Description |
| ------------- | ------- | -------------------------------------- |
| `id` | string | Unique identifier |
| `grid_id` | string | Parent Grid |
| `label` | string | Line label: `"A"`, `"B"`, `"1"`, `"2"` |
| `orientation` | string | `"vertical"` or `"horizontal"` |
| `sort_order` | integer | Ordering within the grid |
Unique constraint: `(grid_id, label)` -- no duplicate labels within a grid.
### BlockGridLine
| Field | Type | Description |
| -------------- | ------- | --------------------------------------------- |
| `id` | string | Unique identifier |
| `block_id` | string | The VIEW block |
| `grid_line_id` | string | Reference to GridLine |
| `position` | integer | Normalized position (0-1000) within the block |
Unique constraint: `(block_id, grid_line_id)` -- each grid line appears at most once per block.
## Grid intersection queries
Query features by grid intersection to find everything at a specific location across all disciplines:
```
query_feature({ grid_intersection: "B-3", project_id: "prj_01ABC" })
```
Returns all features near grid intersection B-3 across all sheets and disciplines.
```bash theme={null}
GET /features?grid_intersection=B-3&project_id=prj_01ABC
```
## Use cases
| Use case | How the grid enables it |
| --------------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Cross-discipline coordination** | Query the same grid intersection across arch, structural, and MEP to see all elements at one location |
| **Clash detection** | Align two discipline blocks via shared grid lines, then check for overlapping features |
| **Revision alignment** | Grid lines are stable between revisions -- use them as anchors to diff feature positions |
| **Location-based queries** | "What is at grid B-3?" returns features from every discipline on every floor |
## Next steps
How cross-references work.