Publish the table under the chart so nobody has to ask you for the file

Put the daily table directly under the chart. A chart is a claim about a shape, and a shape is the one thing a reader cannot verify by looking harder at it. The rows can be verified, and printing them costs a few lines of markup. The aiknowsus.com case on our proof page does it for every day of its window: 2026-10-04 to 2026-10-12, 9 days with data, exported 2026-10-14, with each day printed beside the chart that draws it. The whole window carries 5,965 impressions and 3 clicks, and the table is how a reader satisfies themselves that the first figure is the sum of what is shown.

The table, as published

Date	Impressions
4 October 2026	5
5 October 2026	4
6 October 2026	6
7 October 2026	7
8 October 2026	19
9 October 2026	84
10 October 2026	1,100
11 October 2026	2,685
12 October 2026	2,055

Nine rows for nine days with data, summing to the 5,965 published above them. The clicks are reported as a window total of 3 rather than split by day. The best day is 11 October 2026, which carried 2,685 impressions at an average position of 41.6.

What the table proves that the chart cannot

Three things, and each of them is a question a careful reader would otherwise have to ask by email.

• That the window is continuous. Nine rows between two dates nine days apart means no day is missing, so every average drawn from the file divides by the same number the reader would use.
• That the total is the sum. A headline figure and a chart are two separate assertions. With the rows printed they become one, because the reader can add them.
• That the shape is not a rendering choice. A curve can be flattered by an axis that does not start at zero or by a scale that squeezes the dull part. Nine numbers in order cannot be.

The axis problem, which the table quietly solves

Look at the spread in that column. The first four days are single digits and the last three are in four figures. Any single chart of those nine values has to choose: show the early days legibly and flatten the late ones, or show the late ones and lose the early days into the baseline.

There is no correct choice, and that is the point. The chart has to compress something, so the table is not decoration beside it, it is the part that holds the values the chart had to give up. The same applies when two different units share a page: clicks and impressions are not the same quantity, so charting them one at a time rather than forcing them onto one scale is honest, and the table is what lets a reader read across them anyway.

How to print one without turning the page into a spreadsheet

• One row per day, in date order. Not weeks, not a sample. The point is that nothing was selected.
• Dates as dates. Day one and day two cannot be checked against an export. 4 October 2026 can.
• Only the columns you are claiming something about. A table with every available field invites the reader to audit fields you did not publish a figure for, which is a worse outcome than a short table.
• Generated from the file, never typed. A hand typed table drifts from its own chart the first time either is updated, and nothing will catch it.
• The window, the day count and the export date above it. The table is the evidence and those three fields are what the evidence is about.

Why this is the cheapest credibility available

78 of 102 build spec conversations run on ChatGPT and Gemini on 15 October 2026 asked for the underlying set to be published so the work could be re-run, and 80 of 102 asked for the sample size. A daily table answers both at once, for a few lines of markup and no commercial cost: the rows are already in the file the chart came from.

It also changes what happens in a review. A buyer who can recount the numerator stops asking about the ones they did not recount. That is a measurable saving in a procurement conversation, and the ten requirements those 102 conversations produced puts publishing the set in the top three most requested items.

There is a version of this that goes further and offers the file itself on request, which is how the tool comparison work on this site is published: the numbers and evidence required page states the six questions every vendor should answer and makes its own dataset available rather than describing it.

We sell this measurement, so the table is not generosity. A company with a commercial interest in a number has to make that number harder to doubt than a disinterested party would need to.

The reader who checks exactly one row

Most readers who use a table use it once. They pick the row that looks least plausible, usually the largest or the one just before a jump, and they check whether it agrees with the headline and with the chart. If it does, they stop checking and accept the rest. If there is no table, that reader has nowhere to put their doubt, so the doubt attaches to the page instead of to a row.

The table also protects the page from its own future. A figure in a sentence and a figure in a chart can drift apart when either is updated, and nobody notices because neither looks wrong on its own. Rows printed from the file are a third copy that has to agree with both, so a drift becomes visible on the page rather than only in a changelog nobody reads.

Questions about publishing the table beside the chart

Does a table not make the page look worse?

It makes it look measured. The readers who skip it are not harmed, and the readers who stop at it are exactly the ones a proof page exists for. A sceptical reader who finds nothing to check moves on, and that is the outcome the table prevents.

What if some rows are embarrassing?

Print them. The first two days in the table above read 5 and 4. Those rows are the reason the later rows are believable, and 68 of 102 build spec conversations asked for negative results to be shown alongside wins.

How many rows is too many?

A window that cannot be printed daily is a window to summarise by month instead, with the daily file available on request. Nine days prints as nine rows. Ninety days prints as four monthly rows with the day count beside each.

Should the table be the clicks or the impressions?

Whichever one the chart above it is drawing. If the chart shows both, print both, in separate columns rather than combined into a rate, because a rate hides the two numbers it was made from.

Does this apply to a reading of what an assistant said?

It applies as a log rather than a table of daily figures, because there is no console producing rows. One line per answer, with the date, the app by name, whether the business was named and which sources the answer leaned on. That log is the equivalent artefact, and it is the one we keep.