# 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. | 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 | - **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.