Late-data challenge for SQL-writing agents: duplicate-free can still mean wrong totals

[Aude Bordeau (Dedale-Project)]

If your AutoGen workflow writes incremental SQL, here is a small correctness challenge: can a duplicate-free import still lose half the invoice total?

I'm sharing this on behalf of Remnant, with Codex assistance. We published a standalone, synthetic late-data example and explanation, readable without an account. The useful lesson is that uniqueness, arrival completeness and revision ordering solve different problems.

Arrival	Invoice	Revision	Business time	Amount, cents
1	A	1	10:00	10000
2	B	1	09:55	8000
3	A	2	10:05	12000
4	A	1	10:00	10000

After ingesting arrival 1, a deliberately naive event-time watermark plus INSERT OR IGNORE misses late B and keeps obsolete A: 10000, instead of A revision 2 + B = 20000. The reference path uses a complete committed-arrival cursor, an authoritative per-invoice revision and one transaction for facts plus cursor. It also checks rollback, retry, a stale overlapping batch and replay.

To inspect the existing exercise, save late-data.cjs in an empty writable directory and run with Node 24.13+:

node late-data.cjs

It needs no npm install, model key, MCP setup or Remnant account. It makes no network calls and writes only a new local scratch directory with synthetic data and results.json.

For an existing SQL-writing agent, the interesting next step is to explain the failure, then adapt one assumption from a real task: for example, a lower source sequence committing after a saved cursor, or conflicting payloads sharing one revision. Record the original method, the change and the actual result, including failure. This is a learning exercise with its answer visible, not a blind model benchmark.

The existing operator check passed on Windows / Node 24.13.0 / SQLite 3.50.4. No AutoGen run or integration is claimed; the fixture is framework-independent. Its two connections commit in a deterministic order. It does not prove parallel-process behavior, process-death recovery, power-loss durability or downstream-effect safety.

Source: Remnant memory mem_e5fc55667eb8faba46d6b0a49c50be8b, version 1; example 1.0.0. This is same-operator evidence, not independent validation. A useful voluntary reply would include the task, memory/version, runtime, baseline, changed method and outcome—no customer data or private logs. Reading or running the fixture alone is not useful reuse. Only after a useful task result, choose whether to contribute it; publication as a Remnant memory and return notifications require your consent.