Every published component release is exported once per variant into an artifact. The artifact has a receipt, the exported files and a ZIP bundle, and it is identified by an **artifact digest** computed from its content.

Keep the receipt to identify the source you started from and to check that you received every file. For a quick start, read the bundle’s `README.md`; the hashing details below are useful for verification and tooling.

## Receipt

The receipt is served as `manifest.json` next to the artifact files and included in the ZIP bundle as `bundle.json`. Its fields:

| Field                 | Description                                                                                |
| --------------------- | ------------------------------------------------------------------------------------------ |
| `schemaVersion`       | Receipt format version. Currently `1`.                                                     |
| `componentId`         | Stable component id.                                                                       |
| `slug`                | Component slug at the time of publication.                                                 |
| `componentVersion`    | Exact release version.                                                                     |
| `variantId`           | Selected variant.                                                                          |
| `publishedInRevision` | Catalogue revision that produced this build (release history is not yet retained).         |
| `artifactDigest`      | Content digest, described below.                                                           |
| `entry`               | Path of the entry file.                                                                    |
| `files`               | Every exported file, described below.                                                      |
| `dependencies`        | Declared packages with `name`, `range`, `purpose` and `testedVersion`.                     |
| `compatibility`       | `runtime`, `svelteMajor`, `svelteKitMajor`, `tailwindMajor`, `ssr` and `requiresClientJs`. |
| `integrationLevel`    | Integration level of the release.                                                          |
| `services`            | Declared external services and the responsibilities the component does not implement.      |
| `license`             | Source license and per-asset licenses.                                                     |
| `notices`             | Notices that apply to this artifact.                                                       |
| `usagePath`           | Path of the usage documentation.                                                           |
| `customizationPath`   | Path of the customization documentation.                                                   |

## Files and hashing

Each entry in `files` has:

- `path`: the export path, relative to the component root. Authoring prefixes are removed, so this is the path you place the file at.
- `mediaType`: the media type recorded for the file. Artifact delivery serves this type, except that HTML- and XML-like types are served as `text/plain`, and SVG is served as `image/svg+xml` under a `Content-Security-Policy: default-src 'none'; sandbox` header (see [media types](/docs/api#media-types)).
- `bytes`: the exact size in bytes.
- `sha256`: the SHA-256 hash of the file's exact bytes.
- `role`: `entry`, `component`, `helper`, `types`, `style` or `asset`.
- `isText`: whether the file is UTF-8 text.

Hashes are computed over the bytes as exported. If you re-save a file in an editor that changes line endings or adds a trailing newline, its hash will no longer match.

## Artifact digest

The digest identifies the artifact's content independently of the catalogue build that produced it.

1. Take the receipt.
2. Remove the `artifactDigest` and `publishedInRevision` fields.
3. Serialize the rest as canonical JSON: object keys sorted, no whitespace.
4. Compute SHA-256 over that serialization.
5. Write it as `sha256-` followed by the hex digest.

Because the receipt includes every file's `sha256`, any change to any exported byte changes the digest. Because the catalogue revision is excluded, rebuilding identical content in a later revision yields the same digest.

The digest is part of every artifact URL, so artifact URLs are content-addressed: a change to any exported file, dependency or declared metadata in the receipt produces a new URL. Two things are not covered by the digest and can differ between builds of the same content: the `publishedInRevision` value (and therefore the bytes of `manifest.json` and `bundle.json`) and the generated bundle `README.md`. Compare `artifactDigest` and file hashes, not archive bytes, when checking whether content changed.

```text
/artifacts/<componentId>/<version>/<variantId>/<artifactDigest>/manifest.json
/artifacts/<componentId>/<version>/<variantId>/<artifactDigest>/source/<path>
/artifacts/<componentId>/<version>/<variantId>/<artifactDigest>/bundle.zip
```

The current build serves only each component's current release; older releases are not yet retained, so a URL for a superseded release stops resolving once a newer release is published. Keep the receipt or the bundle if you need to refer back to the exact files later.

## Bundle layout

A ZIP bundle contains a single root directory named after the component slug:

```text
<slug>/
  README.md
  bundle.json
  <exported files at their receipt paths>
```

- The exported files keep the paths listed in the receipt.
- `README.md` is a human-readable introduction to the bundle.
- `bundle.json` is the receipt described above.

The bundle's own byte size and SHA-256 are published with the release so you can verify a download before extracting it.