Start with the runtime, packages, services and limitations to decide whether a component fits your project. The tables below explain the structured metadata behind those requirements. The website, the public API and the MCP server all read the same generated manifests, so a declaration means the same thing wherever you see it.

## Identity and versions

| Field     | Meaning                                                                                       |
| --------- | --------------------------------------------------------------------------------------------- |
| `id`      | Stable identifier such as `cmp_pricing_grid_001`. It never changes, even if the slug does.    |
| `slug`    | The public URL name. Previous slugs are kept as aliases so old links keep working.            |
| `version` | An exact `MAJOR.MINOR.PATCH` release. Retrieval always uses an exact version, never "latest". |
| `status`  | `published`, `deprecated` or `withdrawn`. Drafts never appear in public output.               |

A **deprecated** release remains retrievable while it is the component's current release, and carries a reason, a date and, where there is one, a replacement component and migration note. Older releases are not yet retained once a newer release is published. A **withdrawn** release can no longer be retrieved; requests for it return the `WITHDRAWN` error with a public reason and, when available, a replacement.

## Compatibility

| Field              | Values                                                                                                                                                                                         |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `runtime`          | Determines whether SvelteKit is required. `svelte` works in any Svelte 5 project. `sveltekit` needs SvelteKit, for example because it imports `$app/*` or `@sveltejs/kit`.                     |
| `svelteMajor`      | Always `5`.                                                                                                                                                                                    |
| `svelteKitMajor`   | The SvelteKit major the component targets (`2`), or `null`. Required for `sveltekit` components and may also be set on portable `svelte` components; it does not make SvelteKit a requirement. |
| `tailwindMajor`    | Always `4`.                                                                                                                                                                                    |
| `ssr`              | `supported` renders on the server. `client-only` must only render in the browser.                                                                                                              |
| `requiresClientJs` | Whether the component needs JavaScript in the browser to be usable.                                                                                                                            |

## Kind and integration level

The **kind** describes what the component is: a `section`, a `control`, a `composition` of other parts, or an `integration-recipe`.

The **integration level** describes how much your project has to supply:

- `presentational`: renders markup from props. Nothing to connect.
- `local-interaction`: manages its own client-side state, such as a disclosure or a carousel, without talking to a server.
- `service-required`: needs a service you provide, such as form delivery or payments. The component declares what it does not do.
- `kit-recipe`: a SvelteKit integration pattern delivered as helper and snippet files, with instructions for the route or server code you create in your own project. See [SvelteKit recipes](/docs/sveltekit-recipes).

## Dependencies and services

`dependencies` lists third-party packages with the supported semver `range`, the `purpose` of each package, and the `testedVersion` resolved when the release was built. Svelte and Tailwind themselves, and SvelteKit (including `@sveltejs/kit` imports) for `sveltekit` components, are prerequisites, not dependencies.

`services` lists external services a component expects. Each service entry has a category, a description, the configuration you must provide and a list of **responsibilities the component does not implement**. Read that list carefully: a contact form that renders fields does not deliver email for you.

These declarations drive the dependency filter, which has three values: `none` (no third-party runtime package and no external service), `third-party` and `external-service`. More in [dependencies and assets](/docs/dependencies-and-assets).

## Files

Each release exports an explicit allowlist of at most 50 files. Every file has a role: `entry`, `component`, `helper`, `types`, `style` or `asset`. Paths are relative, and a `suggestedDirectory` tells you where the component expects to live. Keep the relative paths intact when you copy files.

## Usage, props and customization

Each release documents a usage summary, an example, required props and known limitations, plus a prop table with types, defaults and descriptions. Customization lists the palette tokens you can override and a short guide. See [customization](/docs/customization).

## Preview trust boundary

Previews run the component's own code, which has been reviewed in the catalogue repository, inside a same-origin iframe. The iframe isolates layout and styles from the surrounding page and blocks navigation and form submission, but it is not a security boundary against hostile code. Accepting user-submitted components would require serving previews from a separate origin.

## Appearance

`modes` lists the supported appearance modes (`light`, `dark`). When dark mode is supported, `modeSelection` describes how your project selects it for that component. Do not assume every component follows the same mechanism.

## Accessibility, license and provenance

Every release includes accessibility notes and known limitations ([accessibility](/docs/accessibility)), a source license and per-asset licenses ([license](/docs/license)), and a provenance record stating whether the component is `original` or `adapted`.