> ## Documentation Index
> Fetch the complete documentation index at: https://archie.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What are specifications

> Specifications describe each feature, screen, and flow in detail before any code is written — the layer between plan and code.

<Note>Specifications is coming soon. This documentation previews what the section will look like at launch.</Note>

A specification is a structured description of a feature's behavior, written in plain language. It lives between the plan and the code, providing the detail that determines exactly what the build produces.

## Anatomy of a specification

Each feature in your plan generates a specification with five sections:

### Screens

The user-facing surfaces for this feature. Each screen has a purpose, a list of elements (text, inputs, buttons, lists), and the actions available on it. Specifications do not specify pixels — they specify what is on screen and what the user can do with it. Visual styling lives in the [Frontend theming](/docs/features/frontend/theming) layer.

### Flows

A flow is a sequence: the user does X, then Y happens, then they see Z. Flows connect screens. They include success paths, alternate paths, and error paths. Each flow names the actor (which user type), the trigger, and the outcome.

### Behaviors

The non-flow logic. What gets calculated, what runs on a schedule, what fires on an event, what auto-saves. Behaviors are usually one or two sentences each — "when an order's total exceeds \$500, flag it for manual review."

### Validation and edge cases

Required fields, format rules, business rules ("a user cannot order more than 10 of an item"), and edge cases (empty states, network failures, concurrent edits, large datasets). The specification is the place where you say what should happen in each case.

### Copy

Exact text for labels, buttons, placeholders, helper text, success messages, error messages, and empty states. Specifying copy upfront avoids two rounds of "the button text is wrong" after the build.

## How specs relate to plans

The plan says *what* your app does. Specifications say *how each thing behaves*. A plan module called "Orders" might generate a specification covering the order list screen, the order detail screen, the create-order flow, the cancel-order flow, the validation rules for each, and the copy throughout.

When you change the plan (add a module, drop a service), the affected specifications regenerate. When you edit a specification directly, the plan stays the same — you are refining the detail, not the structure.

## How specs relate to code

Specifications are the contract for what the build produces. Each spec section maps to generated code: screens become routes and components, flows become page transitions and form handlers, behaviors become functions, validation becomes form rules and database constraints, copy becomes localization strings. See [Specifications and code generation](/docs/features/specifications/specifications-and-code-generation).

## Where specifications come from

Archie generates an initial specification for every feature in your plan. You edit it the same way you edit plan sections — directly, or through the spec chat for multi-step changes. See [Editing specifications](/docs/features/specifications/editing-specifications).