# Edition numbering & lineage policy

| | |
|---|---|
| **Status** | Adopted |
| **Version** | 1.0 |
| **Date** | 2026-05-26 |
| **Applies to** | All `.lavs` files signed by Project Lavos LLC |
| **License of this document** | CC BY 4.0 |
| **Editor** | Matthew Scott · Project Lavos LLC |

This document answers the question *"what makes Edition II?"* before the first edition is signed. It is intended to be load-bearing for buyers, verifiers, marketplace operators, and future Lavos design practice — anyone who needs to know what a Lavos edition number means and what it does not mean.

---

## 1. The unit of an edition is a slug

Every Lavos design release is identified by a **slug** — a short, stable, lowercase identifier (e.g., `cube`, `mobius`, `torus-knot`, `voronoi`, `lsystem-tree`, `neural-mesh`). The slug is the lineage key. A slug names a *formation family* — the geometric idea, the math, the specific instantiation that has been committed to.

A slug **MUST NOT** be reused across formation families. Once a slug is signed at Edition I, it is permanently bound to that formation family for the lifetime of the Lavos practice.

The slug is recorded in the `provenance` URI of every edition (e.g., `lavs-encoder://lavs-format@<sha>/build-mobius.ts?...`) and is encoded in the filename (`<slug>.lavs`).

## 2. Editions within a slug are numbered copies of one configuration

For a given slug at a given spec configuration, `editionTotal` numbered copies are released. Each numbered copy:

- carries the **same scene bytes** (identical positions, materials, lights, camera framing) as every other copy in the run
- carries a **different `editionNumber`** (1-indexed)
- is **separately signed** at signing time, so the signature includes the edition number — making every numbered copy cryptographically unique even when the scene bytes are identical

`editionTotal` is **frozen at signing**. Once Edition I is signed, the total release size for that slug cannot be increased or decreased. Open editions (`editionTotal = 0`) are similarly frozen at signing — once open, always open; once closed at N, always closed at N.

This is the limited-numbered-copies pattern. It matches print-edition semantics: 33 copies of one configuration, each numbered, each signed, each provably authentic.

## 3. What makes Edition II of the *same slug*

There are exactly three valid paths to Edition II under an existing slug:

### 3.1 Sale of the next numbered copy

The most common case: Edition I of `mobius` is sold; the next buyer receives Edition II. Same scene bytes, same configuration, edition number 2, signed at sale time. This is sequence, not variation.

### 3.2 Parametric variant under a new sub-slug

If the practice wants to release `mobius` in a different configuration — different palette, different parameters, different aesthetic decision — that release **MUST** use a new sub-slug, not a new edition number of `mobius`. Convention: append a descriptive suffix.

Examples:
- `mobius` — the canonical teal polished Möbius
- `mobius-violet` — the same Möbius geometry, violet polished material
- `mobius-thick` — wider strip width parameter
- `mobius-klein` — different surface entirely (Klein bottle), if the practice chooses to ship it under a related lineage

Each sub-slug is its own edition run with its own Edition I, its own `editionTotal`, its own signature.

The reason for sub-slugs (rather than higher edition numbers on the same slug): the buyer of `mobius` Edition I bought *this exact configuration in numbered copy*. Releasing a different configuration as Edition II of the same slug breaks that promise — the buyer's edition number stops meaning what they bought.

### 3.3 Re-seal under spec major increment

If LAVS-002 (a future major spec increment) requires re-sealing existing editions for compatibility, the re-sealed editions ship as **the same slug at the new spec major** — same scene structure, new bytes. This is not Edition II in the lineage sense; it is the same edition expressed in a new container. The original LAVS-001 bytes remain valid for any consumer that still parses them.

## 4. What does NOT make Edition II

- Re-rolling the random seed of a deterministic generator. The seed is part of the configuration; changing the seed produces a different configuration and therefore a different slug (or sub-slug).
- Fixing a runtime rendering bug on `projectlavos.com`. The live site is the studio; the sealed edition is the release. Runtime bug fixes do not invalidate or replace any sealed edition.
- Updating the encoder version. Re-running the encoder against the same scene description with a newer encoder version produces the same bytes (if the encoder is conformant) or different bytes (if the encoder has changed). In the first case, no new edition is created. In the second, the configuration has effectively changed — release under a new sub-slug or a new spec major (see §3.3).
- Tweaking the material values for aesthetic reasons after Edition I is signed. Once signed, the configuration is locked. To release a tweaked aesthetic, ship under a new sub-slug.

## 5. The slug never forks

A slug is monotonic. Once `mobius` Edition I is signed, the slug `mobius` is bound forever to that geometry + that material + that lighting + that framing.

If the practice later regrets the configuration of an early signed edition — material reads wrong, framing chose the wrong angle, the lighting was off — the early edition remains canonical for what it is. The fix ships as a sub-slug, **not** as a re-issued Edition I. The buyer of the early edition holds an artifact that is provably first.

This is the load-bearing rule for buyer trust: nothing they buy can be retroactively superseded by a "better Edition I of the same slug." There is no second Edition I.

## 6. Unsealed parametric exploration

The practice may explore parametric variations of any slug freely while editions remain unsealed. Unsigned `.lavs` files (no `signatureAlgorithm` in the Edition block) are explicitly **release candidates** — they may be discarded, re-rolled, materially altered, or never released. The lock applies at signing time, not at sealing time.

## 7. Edition Zero

`editionNumber = 0` is reserved and not currently used. Producers **MUST** emit `editionNumber >= 1` per LAVS-001 §8.1. Edition I is the first edition; there is no Edition Zero.

## 8. Authority

The slug-to-lineage binding is established by the **first signed `.lavs` file** under that slug. The signing key on that first file becomes the canonical signing identity for that slug. Subsequent editions under the same slug **MUST** be signed by the same identity (or its documented successor under the key rotation policy — see [`KEYS.md`](./KEYS.md), and the published rotation policy at `https://lavos-pubkey.projectlavos.com/rotation-policy.md`).

If two signed files claim the same slug under different signing identities, the file with the earlier `year` and earlier signing timestamp is canonical; the later one is unauthorized and should be refused by conformant viewers.

## 9. Signing prerequisites

No `.lavs` file under this catalog is signed until the six prerequisites in `KEYS.md` §6 are satisfied (YubiKeys provisioned, pubkey URL live, revocation list published, signing infrastructure tested). Until then, every shipped edition is a release candidate per §6 above.

---

*This document is binding policy for editions signed under the identity of Project Lavos LLC. It is published alongside the LAVS-001 specification for any party who needs to interpret what a Lavos edition number does and does not represent.*