> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elestrals.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rulings

> Official clarifications on how a Card behaves, attached to that Card's record.

A ruling is an authoritative explanation of how a Card's effect interacts with another rule, card, or game state. Rulings are issued by the Elestrals organized-play team in response to actual questions that came up at events, and they're the source of truth when a card's printed text is ambiguous.

Every Card carries a `rulings` array. Most have zero entries; a few well-traveled cards have a half-dozen.

## The shape

```json theme={"dark"}
{
  "id": "et-100",
  "name": "Pyrotter",
  "rulings": [
    {
      "id": "rul-1",
      "date": "2024-09-15",
      "text": "Pyrotter's effect resolves before any opposing on-attack triggers."
    },
    {
      "id": "rul-2",
      "date": "2024-11-02",
      "text": "If Pyrotter is destroyed by a Counter rune in response to its activation, the effect does not resolve."
    }
  ]
}
```

## Fields

| Field  | Type     | Meaning                                                                    |
| ------ | -------- | -------------------------------------------------------------------------- |
| `id`   | `string` | Stable identifier (`rul-N`). Use this to reference a ruling.               |
| `date` | `string` | ISO date the ruling was issued.                                            |
| `text` | `string` | The ruling itself. Plain prose, sometimes referencing other Cards by name. |

## How rulings work

* Rulings **do not modify** the Card's `effects` array. The printed text is still the printed text; the ruling is an external clarification.
* Rulings **are cumulative**. A new ruling doesn't supersede an older one unless explicitly stated. Display them all, ordered by date.
* Rulings **don't have format scope** today. A ruling on a Card applies in every format. If that ever changes, the field will become non-`null` non-breakingly.

## Display recommendations

The expected UI pattern is to show the Card's printed effect text first, then a clearly labeled "Rulings" section underneath:

```jsx theme={"dark"}
<section>
  <h2>Effect</h2>
  {card.effects.map((e) => <p>{e.text}</p>)}
</section>

{card.rulings.length > 0 && (
  <section>
    <h2>Rulings</h2>
    <ul>
      {card.rulings
        .sort((a, b) => a.date.localeCompare(b.date))
        .map((r) => (
          <li key={r.id}>
            <strong>{r.date}</strong> — {r.text}
          </li>
        ))}
    </ul>
  </section>
)}
```

Don't merge ruling text into the effect text. They serve different purposes and your users should be able to tell them apart at a glance.

## When rulings change

Existing ruling text is treated as immutable once issued. If a previous ruling was wrong or the rules engine has shifted, the original ruling stays in place (with its original `id` and `date`) and a new ruling is appended that supersedes it. The `text` of the newer ruling will say so explicitly:

```
"This ruling supersedes rul-2. The effect *does* resolve on a Counter response, provided …"
```

This is intentional: TCG players have long memories and a ruling that silently changed would erode trust.

## Card vs Printing

Rulings live on the Card, not on individual Printings. A reprint of the same Card carries the same `rulings` array. There is no separate ruling system for promo-only or starter-deck cards — if a card-game-mechanic ruling exists, it's on the Card record.

## Searching by ruling text

There is no full-text endpoint for rulings today. If you need to find every Card whose ruling mentions "counter rune," you'll need to fetch the Card list via the `updated_since` cycle and grep client-side. We track interest in a `/v1/rulings/search` endpoint — write to support if your use case needs it.