clay-borg/specs/OrnamentRegister.md

# Ornament register — what we claim does not matter

The declarations required by [`Ornamentation.md`](Ornamentation.md) §2.1.

**Every row is a claim that something does not affect the game.** This
project's finding register is largely a list of times that claim was
wrong, so each declaration carries a **falsifier**: the rule or
observation that would make it mechanism. A declaration that cannot be
wrong is not a claim (§2.1, invariant I5).

`grounded` is how the claim is supported — `rule` (the edition says so),
`measured` (we checked), or `provisional` (nobody has ruled, and we chose).
**`provisional` is a legitimate state and must be said out loud**; quietly
canonising a provisional default is a mistake this project has already
made once.

<!-- ornament-register:begin -->

| id | ornaments | grounded | state | raised |
|---|---|---|---|---|
| O1 | hand order | provisional | declared | 2026-08-07 |
| O2 | who shuffles and deals | provisional | declared | 2026-08-07 |
| O3 | where a seat is drawn | rule | declared | 2026-08-07 |
| O4 | card typography and illustration | rule | declared | 2026-08-07 |
| O5 | symbols and glyphs | provisional | declared | 2026-08-08 |
| O6 | colours and design tokens | provisional | declared | 2026-08-08 |
| O7 | card backs, bill of materials, print manifest | rule | declared | 2026-08-08 |

<!-- ornament-register:end -->

- **O1 — hand order.** The *contents* of a hand are mechanism; the order
  the cards sit in is not. No numbered rule in `GroundRules.md` refers to
  a card's position within a hand, and `PlayerView.hand` is a `Vec` whose
  order comes from dealing, not from a rule.
  **Falsifier:** any rule that refers to a card's position in hand —
  *"play your leftmost"*, *"reveal the top of your hand"* — or any engine
  behaviour that varies with it. Invariant I1 is the standing check:
  sorting must not move `state_hash`, because a hash that moved would
  break every trial note's binding (ADR-0019 D3) and every replay.
  **This is the one that prompted the category**, from the request to
  drag cards between hand slots.

- **O2 — who shuffles and deals.** The deck's permutation *is* mechanism
  and comes from the seed; the ceremony around it is not. Nothing in the
  rules names a dealer, and the hands are identical whoever performs it.
  **Falsifier:** a rule that gives the dealer a decision, an advantage, or
  an order of dealing that changes who receives which card. Note the deal
  is **not** ornamental — only the ceremony around it is.

- **O3 — where a seat is drawn.** Seat *order* is mechanism: GR-R08
  rotates Lead, so who follows whom binds. **Where a seat appears on the
  drawn ellipse does not**, provided the drawn order preserves the
  rotation order.
  **Falsifier:** any rule referring to physical position — *"the player
  across from you"*, *"your left-hand neighbour"* as distinct from the
  next in rotation. This is `rule`-grounded rather than provisional
  because GR-R08 states the ordering that binds.

- **O4 — card typography and illustration.** How a card looks does not
  change what it does. **But it is not ours to invent**: ADR-0015's
  discipline holds.
  **Falsifier:** a card whose meaning is carried by its layout or art
  rather than its text, which is a real possibility in a game about
  perception.
  **Updated 2026-08-08, and the earlier version of this row was wrong.**
  It said nothing could be declared until `Player_Mats` and `Glossary`
  were read, and treated both as ornamentation-bearing. They have now been
  read, and **`Player_Mats.csv` carries GR-R03** — the stress gate — in
  its `choice_rule` column. Both files are vendored as mechanism; what
  remains ornamental on a mat is the symbol, the colour and the title,
  which is why this row is now `rule`-grounded: the rules text lives in
  columns we read, so what is left is demonstrably decoration.

- **O5 — symbols and glyphs.** `Symbols.csv` gives each concept a glyph,
  an ASCII fallback and an icon brief. The engine names concepts in words
  and never in glyphs, so nothing it computes can depend on them.
  **Falsifier:** a rule that distinguishes two things only by their
  symbol, or a `symbol_id` that appears in a rules text as the sole
  referent for something. Note `symbol_id` is currently unread in **six**
  vendored files, which is what this row licenses — and if that ever
  becomes load-bearing this row is how we find out.

- **O6 — colours and design tokens.** `Design_Tokens.csv` is a palette
  with usages. No rule refers to a colour, and seat colour is a label for
  a seat the engine already identifies by `PlayerId`.
  **Falsifier:** a rule keyed to colour — *"the red player leads"*, a
  colour-coded suit — or a component whose identity is only its colour.
  **Provisional**: nobody has ruled that colour is non-binding; we
  observed that no vendored rules text mentions one.

- **O7 — card backs, bill of materials, print manifest.** `Back_Designs`,
  `BOM` and `Print_Manifest` describe a physical print run: stock, cut
  sizes, quantities to manufacture.
  **Falsifier:** a *back* that distinguishes two decks the rules treat
  differently — which is exactly what `back_design_id` would encode, and
  it is unread in four vendored files. That is a real hazard rather than a
  theoretical one: hidden information is what card backs are *for*, and a
  game about concealment could easily make one load-bearing.
  `rule`-grounded because the engine's hidden information is modelled from
  the rules text (face-up/face-down, `Hidden` visibility), not from print
  data.

## What is deliberately absent

**No row for animation, timing or movement.** Those are ornamentation, and
they belong to `clay-animate` (§3). A declaration here is a claim about
*the game*; how a renderer performs it is that renderer's business.