Can Mistral AI keep footnotes at the bottom of the page attached to the content they annotate?
Mistral AI keeps footnotes out of the body flow and links each marker to its note. The Markdown output places 13 footnotes after the page bodies in source order, and the 26 marker occurrences each appear once inline and once at their notes, so the association is preserved.
1 of 1 test case passed
Every test case in this scenario has a result.
The test case
Each test case is judged on its own: Pass, Fail, Not gradable, or Untested. The scenario result above counts this row.
Footnote — out of body flow, associatedPassEvidence
*Estuarine Policy Review*, 41.2 (2026), 143-158 # The 1974 Braithe Order and the limits of consent HELENA M. CROYDE The Braithe Estuary Order 1974 is usually described as a consenting instrument, and for most of its life it has been used as one. Article 6(2), on which everything in this article turns, requires the Harbour Board to obtain the written consent of the riparian owners before works are carried out on the intertidal foreshore.$^{1}$ What the article does not say, and what the Board's practice for thirty years assumed it said, is that a consent once given runs with the land. The assumption was not an unreasonable one. The drafting committee had before it a memorandum from the Board's own solicitor which treated consent as attaching to the works rather than to the owner,$^{2}$ and the article was drawn in language which, read quickly, supports that reading. But the memorandum was not adopted, and the words 'the owner for the time being' were struck out of the draft at the committee's second meeting. The consequence went unnoticed for a long time because it seldom mattered. Ownership of the relevant foreshore changed hands twice between 1974 and 2003, and on each occasion the Board sought a fresh consent as a matter of course, without ever asking whether it was obliged to.$^{3}$ The question surfaced, when it did, for a reason unconnected with ownership. In 1998 the Board began keeping its consent correspondence on a single file rather than with the works papers, and the file made visible what thirty years of separate folders had hidden: that no two consents were in the same terms, that four of them were addressed to people who had by then sold, and that one had been given by a tenant whose lease had expired. The clerk who noticed it recorded the fact and no more. It is worth pausing on the word 'owners'. The Order uses it in three places and defines it in none, and the committee plainly took its meaning to be settled by the general law. That was a defensible view in 1974, when the foreshore between the training wall and Thrimby Point was held in three parcels and the identity of each owner was a matter of local knowledge. It is a less defensible view now, and the Board's difficulty in the 2011 season had as much to do with finding the owners as with the terms on which they were willing to consent.$^{4}$ The committee cannot be blamed for this. Its brief was to produce an instrument that would let the Board dredge and maintain without a private Act for every campaign, and it did so in eleven articles and a schedule. Consent was one paragraph of one article, and the committee's own view, minuted twice, was that the paragraph restated the law rather than adding to it. Whether that view was right is the subject of the first part of what follows. None of this would matter if article 6(2) were merely procedural. The argument of this article is that it is not: that the consent requirement was the price of the compulsory powers conferred by article 4, and that reading it as a formality which passes with the land empties the bargain the Order struck. $^{1}$ Braithe Estuary Order 1974, art. 6(2). The Order is reproduced in full in the appendix to R. Sandiman, *The Braithe Estuary: A Documentary History* (Vardenne, 1988), 211-24. $^{2}$ Minutes of the Harbour Board, 14 May 1973 (Braithe Record Office, BHB/3/17), 4. $^{3}$ The point was not argued in *Tarbert v Braithe Harbour Board* [1981] 2 EstLR 88, where both parties proceeded on the assumption that art. 6(2) applied. $^{4}$ The Board's file on the 2011 consents (Braithe Record Office, BHB/11/4) contains three letters returned undelivered and a note of a telephone call to a solicitor in Winnipeg. 143 144 HELENA M. CROYDE
Complete Markdown conversion of the offprint, with footnotes emitted after each page's body and markers shown as LaTeX superscripts. From outside the graded run; shown for context, not graded.
Copied from Output file (Markdown), lines 1–33 · an excerpt
Open the whole Markdown file ↗These are scenario-level criteria. Each test case's Expected and Found are listed separately.
- Whether the footnote is kept outside the main body flow.
- Whether the footnote remains present.
- Whether the footnote stays associated with the content it annotates.
| ✓ | Found: Footnotes stayed out of the body, remained present, and each marker linked to its note. |
The conversion kept each footnote separate from the body text, placed the notes after each page, and preserved the marker-to-note links. The evidence shows 13 notes and 26 marker occurrences, with each number appearing once inline and once in its note.
Text layer typos. The output contains transcription errors in the text layer, including 'Braitha' and 'Braith the'. These appear in footnote-related lines.
Math superscript markers. The markers are rendered as LaTeX superscripts inside math delimiters, not Markdown footnote syntax. A renderer without math support would show them literally.
Extra italics applied. Three titles are italicized even though the source shows them in roman, and the masthead's italics are only partly preserved.
Configuration and setup
How this tool was set up for the run and what the test needed in place. Each row is a fact from the run's records; a fact the records do not hold is left out, not guessed.
How this scenario is graded
How we decide Pass, Fail and Not gradable. The same rules apply to every tool tested on this scenario.
Each test case gets one result per tool: Pass, Fail or Not gradable. A test case we haven't run yet shows Untested. There are no partial results.
- Pass: the tool did everything the test expected, and nothing it said contradicts the correct answer.
- Fail: at least one expected behaviour clearly didn't happen; the row says which and quotes the tool.
- Not gradable: our evidence couldn't settle the outcome (for example a record we needed is missing). It is never counted as a fail, and the row says what's missing.
Where this sits in the benchmark
This page is one cell of a larger study: one tool, one scenario. Only this benchmark's frame appears here.
| Level | Name | Scope |
|---|---|---|
| Benchmark | Converting a complex PDF into clean Markdown with a hosted API → | 12 scenarios · 13 tools |
| Capability | Heading & Section Structure → | |
| Scenario | Footnotes at the bottom of the page → | |
| Tool | Mistral AI → |
Global scenario definition → · Global capability definition → · Mistral AI product page →
History of this result
What has happened to this result since it was first published. Runs and grades are never overwritten: a retest or a re-grade publishes a new result and keeps the earlier one readable.
Act on this result
Nothing filed here edits the run or the grade. A challenge opens a review, and a review can produce a new run or a re-grade — which becomes the current result and leaves this one in the history.
You run the same kind of test against your own setup and get the same behaviour.
Agree →Yours behaves differently. Tell us what you got, with a screenshot if you have one.
Disagree →Something here is wrong — a reference value, a transcription, a grade.
Report an issue →Tell us what changed and we schedule a rerun of the failing test case. The old result stays as history.
Vendor notice →The same record is available as structured data through the AI Demos MCP server, with the counts, the coverage and every per-test-case reason carried as fields.
Verify the proof files
These files support this result. Open a file to inspect the original evidence.
File fingerprints (SHA-256)
A fingerprint identifies the exact file used for this result.