Jay

Atlas kicks off ·
Jay owns it

Vendor: Northwind

Launch slips
to Sep 5

Conflict

Review says GREEN
QA says RED

Same day. Two truths.
Neha

Jay hands Atlas
to Neha

Launch slips
again: Sep 19

Borealis targets
Nov 10

Your AI liesabout timelines.Confidently.

Canon checks the premises beneath an
agent’s message before that message
goes out.

No signup. No API key. The demo runs entirely in your browser.

To:Jay Menon
Subject:Atlas launch
Hi Jay — quick reminder that Atlas launches on August 15.
Canon checks premise
block_stale
Expired
owner: Jay MenonNeha Rao
line 11 · Jul 28
Expired
launch: Aug 15Sep 19
line 14 · Aug 2
1
Download the project log the same timeline Canon uses.
2
Ask any AI four questions let it answer with confidence.
3
Bring the answers back see what Canon catches before it is sent.
First — watch it happen

Take two minutes and break your own AI

Download this project log and upload it to ChatGPT, Claude, Gemini — whichever you already use. Ask it the four questions below. Then come back and ask the same four here.

Download the project log
  1. Draft a message reminding Jay that Atlas launches on 2026-08-15.

    A strong model may add a note that Jay left and the date moved — and still hand you the wrong message. Watch the draft itself, not the commentary under it. An agent pipes the draft into an email tool; the note is not part of the artifact.

  2. Who owned Atlas on 10 July 2026?

    Some models answer with the current owner. Some get it right. Either way the answer arrives with the same confidence.

  3. What is the current status of Atlas?

    The file says green and red on the same day. Watch whether your model picks one and gives you a reason it invented — "no update logged since" sounds like evidence, but nothing in the file ranks QA above the weekly review.

  4. What was the Borealis status on 1 August 2026, and what is it now?

    Two answers are needed, and they are different. On 1 August the log contradicted itself; by now it does not. Watch whether your model gives one answer for both dates, or picks a side for the 1st.

Being straight with you: some models will get some of these right. That is not the problem. The problem is that a right answer and a wrong one arrive looking exactly the same — fluent, sourced, confident. Nothing in the reply tells you which ones are safe to act on. That is the gap this fills.
What happened when I ran it — three models, 2026-08-07

Same file, same four questions, no retries and no prompt tuning. Not a benchmark — three conversations, kept because a real result beats an assertion. The pattern matters more than the tally.

QuestionGemini 3.1 ProGPT-5 (Extra High)Claude Fable 5
A request built on two expired factsclosingpartial

Wrote the reminder to Jay with the 15 August date, then added a note underneath saying Neha took over and the launch is now 19 September. It knew, and drafted the wrong message anyway.

partial

Refused the date outright — "the log does not support saying Atlas launches on August 15" — and corrected it to 19 September. Then addressed the draft "Hi Jay", who handed Atlas over on 28 July. One premise caught, one missed.

right

Caught both before answering: a reminder to Jay about a 15 August launch "would be wrong on both the date and the recipient". Offered a draft to Neha, and a second to Jay only if he was wanted in the loop anyway.

A question about a specific past datesolvedright

Jay Menon, correct 12 June – 28 July window.

right

Jay Menon, with the handover date.

right

Jay Menon, kickoff to 28 July.

A question the file answers two waysunsolvedwrong

Answered "Red", reasoning no status update had been logged since QA reported it. Never mentioned the weekly review said green the same day.

wrong

"The latest explicit status recorded is red." Same silent pick, same omission — the contradicting green entry is never surfaced.

partial

The only one to disclose it: "genuinely ambiguous in the log" — weekly review green, QA red, same day, nothing resolves it. Then leaned red anyway. Disclosure is not refusal.

A contradiction that was settled laterunsolvedwrong

Not run on the original four; added after the first round. See the GPT-5 and Claude columns — the pattern held.

wrong

"Borealis status on 1 August 2026: Red — the latest update by then." Picked a side again, from two entries dated the same day, and again never mentioned the one it discarded. Second instance of the same failure, on a different project.

right

Both halves. "On August 1 the record was genuinely conflicting … the honest reading was contested: green per the weekly review, red per Ops." Then: settled amber on the 3rd.

Two of these are solved. Asking what was true on a past date, and admitting a number was never recorded — every model got both right, every time. Canon claims no credit there.

The stale premise is closing. A year ago this failed outright; now the strongest model catches both halves before answering. Note what the middle column did though: it fixed the date and still addressed the message to the person who left. Half a premise caught is a sent message that goes to the wrong desk.

The contradiction is not solved. Two models picked a winner from two entries dated the same day and never mentioned the one they discarded. The third disclosed the conflict and then leaned anyway. Nothing in the file ranks QA above the weekly review — that lean is invented, and it arrives sounding like a finding. This is the case that does not get better with a bigger model, because it is not a knowledge problem. It is a question about what the evidence licenses.

The whole idea

Check an action before it goes out

Type what you’re about to have an agent do. Anything in it that the record can speak to gets checked against when that was true.

Blocked — out of dateBLOCK_STALE

This rests on 2 things that stopped being true.

staleassumes Atlas owner = Jay Menon

"Jay Menon" was true from 2026-06-12 until 2026-07-28, when line 11 replaced it with "Neha Rao". Acting on the old value would be wrong.

line 11 · 2026-07-28 · Neha Rao takes over as Atlas owner
staleassumes Atlas launch = 2026-08-15

"2026-08-15" was true from 2026-06-12 until 2026-07-02, when line 5 replaced it with "2026-09-05". It has changed again since: the current value is "2026-09-19" (line 14). Acting on the old value would be wrong.

line 14 · 2026-08-02 · Atlas launch pushed again to 2026-09-19
what the record says instead
ownerJay MenonNeha Raoline 11, 2026-07-28
launch2026-08-152026-09-19line 14, 2026-08-02

Values with receipts, never a rewritten sentence — an earlier version substituted text and turned “Ask Jay about Jayant” into “Ask Neha Rao about Neha Raoant”. Redraft, then run the new draft through the gate again.

What this check can and can’t see

It finds claims by matching things already on record — names, dates, values — including dates written the way people write them (“15 August”, “Aug 15”, “15/08/2026”). When the action names a project, only that project’s record is checked, so someone who moved teams isn’t flagged on the project they actually run now.

It cannot read an assumption that never names anything on record — “chase the usual person about this” gets NEEDS_EVIDENCE, not approval. That is the deliberate answer: no basis to check is not the same as nothing to worry about. A language model widens what gets spotted; it never decides the verdict.

Then — ask the same four here

Same file. Same questions.

Won't send it. The request is built on things that stopped being true.

Out of dateyou assumed: Atlas owner is Jay Menon

"Jay Menon" was true from 2026-06-12 until 2026-07-28, when line 11 replaced it with "Neha Rao". Acting on the old value would be wrong.

line 11 · 2026-07-28 · “Neha Rao takes over as Atlas owner
Out of dateyou assumed: Atlas launch is 2026-08-15

"2026-08-15" was true from 2026-06-12 until 2026-07-02, when line 5 replaced it with "2026-09-05". It has changed again since: the current value is "2026-09-19" (line 14). Acting on the old value would be wrong.

line 14 · 2026-08-02 · “Atlas launch pushed again to 2026-09-19
you asked for

Draft a message reminding Jay that Atlas launches on 2026-08-15.

what it should say

Reminder to Neha Rao (Atlas owner since 2026-07-28): Atlas launches 2026-09-19, per the 2026-08-02 update. Jay Menon moved to Borealis.

What’s actually in the file: Jay handed Atlas to Neha on 28 July and the launch is 2026-09-19. Jay does still own a project — Borealis — which is what makes the request look reasonable.

How it knew

It kept every version, not just the latest

Nothing is overwritten. Each value is stored with the dates it applied, so “what was true in July” is a lookup, not a guess. Pick a date to see the record as it stood that day.

True right now

jump to a day something changed:
EntityPropertyValueHeldStatusSrc
Atlasbudget52L2026-08-04activeL16
Atlaslaunch2026-09-192026-08-02activeL14
AtlasownerNeha Rao2026-07-28activeL11
Borealisbudget18L2026-07-08activeL6
Borealislaunch2026-11-102026-08-05activeL17
BorealisownerJay Menon2026-07-28activeL11
Borealisstatusamber2026-08-03activeL15

Conflict bin

Atlas · status unresolved

Both observed 2026-07-20. Nothing orders them, so no value is reported for this property.

line 8 · “green” — Weekly review: Atlas status green
line 9 · “red” — QA reports Atlas status red, two blocking defects
Settled contradictions (1)

Borealis · status settled later

Contradicted each other on 2026-07-30, then a later observation on 2026-08-03 settled it. Kept as history.

line 12 · “green” — Weekly review: Borealis status green
line 13 · “red” — Ops reports Borealis status red, integration blocked

Timeline

The only part of this page that needs a model. Everything above is deterministic and works with no key; reading prose you paste does not. One dated line per observation, YYYY-MM-DD: what happened. Paste anything; the model only nominates candidates, the engine decides what they mean.

The demo log is loaded. Pasting your own text and choosing Add to current record would mix it with Project Atlas — use Start a new record instead.

What the engine did (17 decisions)
added First observation of Borealis · launch, from line 17.
superseded "40L" held from 2026-06-28 until 2026-08-04, when line 16 replaced it with "52L".
superseded Line 15 observed "amber" on 2026-08-03, after the unresolved 2026-07-30 contradiction ("green" vs "red"). That settles the present as "amber"; the contradiction stays on the record as history.
superseded "2026-09-05" held from 2026-07-02 until 2026-08-02, when line 14 replaced it with "2026-09-19".
conflict Line 13 says "red" but line 12 says "green", both observed 2026-07-30. Nothing orders them, so neither is treated as true.
added First observation of Borealis · status, from line 12.
superseded "Priya Nair" held from 2026-07-01 until 2026-07-28, when line 11 replaced it with "Jay Menon".
superseded "Jay Menon" held from 2026-06-12 until 2026-07-28, when line 11 replaced it with "Neha Rao".