# bouyeure-2026-fear-rsa — what each format carries

30 claims, 83 typed relations between them.

One source, three targets. Each row is a relation type the paper's claim tree uses; each column is what became of it.

| Relation | In the tree | MIRA | OXA | Discourse Graphs |
|---|---:|---|---|---|
| `supports` | 19 | `cg:supports`, under `mira:supports` | kept | kept |
| `requires` | 13 | `cg:requires`, neutral | kept | dropped |
| `scopes` | 11 | `cg:scopes`, neutral | kept | dropped |
| `extends` | 6 | `cg:extends`, under `mira:supports` | kept | kept |
| `entails` | 6 | `cg:entails`, neutral | kept | dropped |
| `derived-from` | 6 | — | kept | dropped |
| `tests` | 5 | `cg:tests`, neutral | kept | kept |
| `interprets` | 5 | `cg:interprets`, neutral | kept | dropped |
| `validates` | 4 | `cg:validates`, under `mira:supports` | kept | kept |
| `dissociates-with` | 4 | `cg:dissociates-with`, neutral | kept | dropped |
| `enables-method` | 3 | `cg:enables-method`, neutral | kept | dropped |
| `confirms` | 1 | `cg:confirms`, under `mira:supports` | kept | kept |

## What MIRA has no predicate for — and what happens instead

**47 of 83 relations (57%) are neither support nor opposition.** They are not dropped and not flattened. MIRA imports a Discourse Graphs base schema in which relations are definable, and its `AbstractRelationDef` is a neutral root — it carries no supporting or opposing commitment — so each is declared in the document with a domain, a range and a description, and the edges are typed by that declaration.

- `cg:requires` (13) — a claim depends on another holding
- `cg:scopes` (11) — a scope constraint governs another claim's validity
- `cg:entails` (6) — a hypothesis entails its prediction — the deductive step
- `cg:derived-from` (6) — a prediction derived from its hypothesis (inverse of entails)
- `cg:interprets` (5) — one claim interprets another
- `cg:dissociates-with` (4) — the source and target jointly establish a dissociation — two claims whose difference across a condition, region, population or measure is itself the finding, neither bearing on the other's truth (symmetric)
- `cg:enables-method` (3) — a result makes a downstream method possible

Declaring them under `mira:supports` would have been worse than dropping them: it would assert that a boundary condition is evidence *for* the claim it limits, which reverses the meaning.

## What a reader who knows only core MIRA sees

Every relation keeps its own type — nothing is flattened into `supports`. 30 of the 77 edges are declared under `mira:supports` or `mira:opposes`, so a reader that follows only those two still gets their direction; the reason the edge was drawn is in the declaration rather than lost.

- `supports` (19) — under `mira:supports`
- `requires` (13) — neutral
- `scopes` (11) — neutral
- `extends` (6) — under `mira:supports`
- `entails` (6) — neutral
- `tests` (5) — neutral
- `interprets` (5) — neutral
- `validates` (4) — under `mira:supports`
- `dissociates-with` (4) — neutral
- `enables-method` (3) — neutral
- `confirms` (1) — under `mira:supports`

## What MIRA genuinely cannot carry

6 `derived-from` relations are not emitted as edges. This is not loss: `derived-from` is declared `owl:inverseOf` `entails`, and MIRA never materialises the reverse direction — its own 942-node demo graph emits no inverse edges either. A reader recovers each one from the forward edge and the declaration.

Beyond those, nothing. Every relation in this paper reaches the export, either as an edge or as the declared inverse of one.

## What no format carries

Verification — that a claim was checked, by what code, against what deposited data, with what result beside the published value. None of the three has a node for it.

This paper's records: 13 unattempted, 4 partial, 4 verified, 1 blocked.

---

Generated by `scripts/formats_report.py` from the files in `exports/`, not from the converters' mapping tables — a table says what a converter intends, the export says what it did.