---
title: "Requirements"
description: "Design intent the machine can check — knock-down, the longest part that fits up your stairs, load, deflection, tools, and the standards a design promises to satisfy."
url: https://kaicad.barpom.xyz/docs/schema/requirements
schema: "0.1"
source: packages/spec/src/design.ts
---

# Requirements

`requirements` is where the design says what it is *for*. It is the direct output of the
authoring pack's interview and the direct input to the validator, and it is what makes "why
did you do it that way?" answerable months later.

```yaml
requirements:
  knock_down: true
  max_part_length: 2100
  max_assembled_load: 300
  deflection_limit: span/360
  tools: [table_saw, drill, router, circular_saw]
  finish: oil
  budget_hint: mid
  must_satisfy:
    - standards.bed.slat_gap_max
    - standards.bed.centre_rail_required
  notes:
    - The rails must come off without disturbing the headboard panel.
```

Every key is optional. Each one that is present is something the report can check and, when it
fails, name.

| Key | | |
| --- | --- | --- |
| `knock_down` | boolean | The piece must come apart without breaking a glue joint. |
| `max_part_length` | mm | The longest part that can be carried in. |
| `max_assembled_load` | kg | Distributed load the piece must carry. |
| `deflection_limit` | | `span/360` style, or an absolute mm figure. |
| `max_envelope` | | `{ length, width, height }` the finished piece must fit inside. |
| `tools` | list | What the builder actually has. |
| `finish` | | Free text — `oil`, `lacquer`, `none`. |
| `budget_hint` | | `low`, `mid` or `high`. |
| `must_satisfy` | list | Catalogue standard ids this design promises to meet. |
| `notes` | list | Prose constraints, for the humans. |

## `knock_down`

```yaml
knock_down: true
```

Checked against the joints: every joint on the disassembly path has to be `removable: true`,
with hardware that can be undone. A glued dowel joint in a piece that claims to be knock-down
is a finding, not an oversight to be noticed later.

This is normally the constraint that picks the hardware. A bed that has to come apart wants
bed bolts and threaded inserts; one that does not can be glued and will be stiffer for it.

## `max_part_length`

```yaml
max_part_length: 2100
```

"Has to get up my stairs." Compared against every part's blank length — the size the timber
yard cuts, not the finished dimension — because that is the board that has to come through the
door.

It is worth stating even when you think nothing is close to it. A 2032 mm queen rail and a
2100 mm stairwell is a fact you want checked, not remembered.

## `max_assembled_load` and `deflection_limit`

```yaml
max_assembled_load: 300        # kg, distributed
deflection_limit: span/360     # or an absolute mm figure
```

These drive the deflection checks. The span divisor is the convention: `span/360` is
structural practice and stricter than furniture needs; `span/200` is where sag becomes visible
and is the usual figure for a shelf.

The check reads the **resolved material's** modulus of elasticity, so a pine shelf and a
maple one of the same size get different answers, and the finding carries a computed
suggestion — a thickness, or a span, that would pass.

## `max_envelope`

```yaml
max_envelope:
  length: 2200
  width: 1700
  height: 1000
```

The box the finished piece must fit inside. Different from `max_part_length`, which is about
getting the parts in; this is about the room it ends up in.

## `tools`

```yaml
tools: [table_saw, drill, router, circular_saw]
```

What the builder has. A design that needs a mortiser when the list says otherwise is worth
saying out loud, and it changes which joinery is a reasonable suggestion in a repair.

Common values: `table_saw`, `circular_saw`, `mitre_saw`, `bandsaw`, `router`, `drill`,
`drill_press`, `planer`, `jointer`, `domino`, `pocket_hole_jig`, `chisel`, `hand_tools`.

## `must_satisfy`

```yaml
must_satisfy:
  - standards.bed.slat_gap_max
  - standards.bed.centre_rail_required
```

Catalogue standard ids the design promises to meet. Listing one turns its check from advisory
into a **requirement of this design**, and the finding cites the source — who says so, not
just that something is wrong:

```
DOM-002  A 1636 mm bed needs a centre support rail with at least one leg to the
         floor. Mattress warranty conditions for queen and larger sizes require
         one above 1370 mm width.
```

Every standard carries a citation, because an uncited number is an opinion and the value of
this validator is that it is not giving you opinions. The full list is in
[Standards](/docs/catalogue/standards).

## `notes`

```yaml
notes:
  - The rails must come off without disturbing the headboard panel.
  - Matching the existing bedside tables — walnut, oiled.
```

Prose, for the people. Nothing checks these, and they are still worth writing: they are the
constraints that explain the design to whoever reads it next, including the model asked to
change it.

## Why this section pays for itself

Requirements are what a repair reads. When the validator raises a finding and you paste the
report back, the model fixing it can see that the piece has to come apart, that nothing may
exceed 2100 mm, and that the slat gap is a promise rather than a preference. Without that, a
plausible fix — glue the cleat, lengthen the rail, spread the slats — can satisfy the finding
and break the design.