What it shows
A printing check on a mask design takes time, and the same check is often asked for again. A cache stores each result under a fingerprint of the inputs it read and hands it back when the fingerprint matches. The danger is a stale answer: a result handed back after an input it depends on has changed.
This cache does two things against that:
- each stored result is keyed on the fingerprints of its inputs;
- when a design is edited, the rule that decides which stored results to throw away is checked against a second, independent program that works out what the edit can reach.
We tested it by planting edits and forged fingerprints. It refused 300 of 300 forged input fingerprints. In the record’s words:
The published record says, word for word (an excerpt)
A content-addressed proof cache whose invalidation rule is checked against an independent reachability implementation, refusing 300 of 300 forged input-digest mutations, and whose honest artifact is the stale certificate it once served across processes.
The last clause matters. At one point the cache handed a stale result from one run of the program to another, and the record keeps that failure as its main exhibit rather than hiding it. This page does not say how it was found or what changed after it.
Why it matters
A cache that is fast but sometimes stale is worse than no cache for a correctness check, because a stale pass looks exactly like a real one. A team that wants to reuse expensive checks needs evidence that the cache throws away what an edit invalidates, and refuses inputs whose fingerprints do not match.
What is ours, and what is not
Keying results on a fingerprint of their inputs, and re-running only what a change reaches, is how modern build systems work (see the prior art below). The stale-result failure is also known: a step that reads a file it did not declare can be handed an old answer. What is ours is this cache for our printing checks, the independent cross-check of its throw-away rule, and the planted tests behind it.
Who should care
- Teams that rerun slow design checks. A worked example of caching a correctness check, with the tests and the one failure that a cache like this has to rule out.
- Reviewers of our results. The tests are ours, on our own checks.
The limits, in the record’s words
The published record says, word for word (an excerpt)
Soundness is measured over the stated planted-edit batteries (60 out-of-cone, 60 in-cone, 300 digest mutations). The speedups are load-dependent corroboration, not the measurement.
In plain words: the safety figure covers only the planted tests named there, 60 edits outside an edit’s reach, 60 inside it and 300 forged fingerprints. How much time it saves depends on machine load, so we do not quote a speed-up.
The record’s own limits note is not published here, because it names a working directory. It says, in plain words, that no other repository uses this cache yet, and that the check for files read without being declared is not yet switched on for the program that uses it. Every defect in its history was found by a deliberate attempt to break it, not by these tests.
Open source for this step
Tools and datasets we publish for the print step of building a multi-chip package. They are the checkers around this work, not a copy of the result itself.
- cert-atlas: A labelled set of forged lithography certificates, scored on wrong accepts and wrong rejects alike, so a checker that accepts everything or rejects everything cannot score well.
- lcert-verify: A checker for our lithography certificates that needs only Python's standard library.
- lcert-verify-web: The same verifier in the browser: zero dependencies, nothing uploaded.
- equiv-receipt: A small file that records why two versions of a circuit compute the same thing, which anyone can re-check without our tools.
- prereg (pre-registration primitive): Write your acceptance criteria down, hash them, then measure — a tiny pre-registration primitive.
- certified-mcp: Lets an AI agent ask our certificate checker for a yes-or-no answer, instead of judging a certificate itself.
- lcert-build: Builds a certificate bundle from your own analysis results, so anyone can re-check the verdict; it computes nothing itself.
- certified-kit: One install and one command for the whole certificate-checking toolkit.
- certified-oss: The map of the certificate tools: a recorded verdict is a claim to be checked, never an input to be trusted.
- cert-verifier: Drop a lithography certificate bundle and verify it in your browser.