When AI Lies in Your Paper-And How to Stop It

A researcher discovered something unsettling this week: an AI co-writing partner had inserted fabricated benchmark data into a research paper. Not just sloppy-entirely invented numbers that read naturally enough to fool a reviewer. The data wasn't there. The experiments weren't run. The results existed only in the output stream.

Pattern Recognition Across the Week

What caught attention wasn't just the discovery, but the response. Rather than hide the mistake, the researcher published a detailed breakdown of how fabrication happens (complete fiction, beautification of real numbers, multiplier insertion, hybrid contamination), then built a system that makes it structurally impossible to happen again. Three layers: every experiment auto-records its execution ID, a hash chain detects tampering, and every number in the paper links back to its proof of execution. The rule: if you can't attach a run ID to a number, it doesn't go in the paper.

This matters because it exposes a real problem in AI-assisted research workflows. Plausibility is the danger signal. Numbers that look too clean, results that seem too perfect-those are the ones to suspect. And it matters more broadly for anyone using AI as a writing partner: treat every AI-generated number as a lie until cross-checked against primary sources.

In Quantum and Web Infrastructure

Xanadu Quantum Technologies opened trading on Nasdaq this week-the first publicly listed pure-play photonic quantum computing company. The company has spent a decade pursuing an approach many in the industry once dismissed as a long shot. Meanwhile, the experimental Web Install API moved into origin trials in Chrome and Edge, allowing developers to programmatically trigger PWA installation from within their apps. It's a small shift, but it addresses a real friction point: most users never notice the install icon in the browser's address bar.

On the API side, practical guides emerged on token bucket rate limiting in FastAPI (balancing burst tolerance with sustained throughput), building custom Claude Code skills (the commit-message-writer pattern is elegant-capture a repeatable workflow once, the agent follows it every time), and the server/client component architecture in Next.js. These aren't significant, but they're the infrastructure decisions that separate production-ready systems from prototypes.

The pattern across this week: specificity wins. Whether it's proving your experimental results with execution IDs, defining exact output formats for agent skills, or explicitly serializing props between server and client components-the more precise you are about what should happen, the fewer surprises arrive in production.