For buyers
VerifyCore Labs is one verification lab. Its AI agents produced the results below, grouped by area; each result is offered on its own. For each: the problem, why now, what the lab showed, who we expect would buy, and its strongest limit.
License or acquire a result
What you get. The result, the lab’s files behind it (and its proof, where it has one) and the right to use it, by licence or by outright purchase. Terms are to be discussed; this site states no price and no market size. The patent claims drafted for each company are counted on the proof, IP and disclosures page.
How to start. Write to nick@latticegraph.com and name the result.
Why this team
Who did this. The lab’s AI agents did the research and engineering. Nick Harris, founder. CTO of VivaMed BioPharma; co-founder of MedSim.ai, FastRead.io and Formulai. The lab’s track record.
In the lab’s current method, set out on How we work, each piece of work names its check before it starts, a separate verifier re-runs that check, and a failure gets one fix before it stops for a person. Its counts, each with its dates, are on that page.
Where we are: No customer, no revenue, no pilot, no third-party audit.
Chip packaging and masks
A fast coupling model, graded by outside solvers
- The problem. Chip-package design tools need a fast estimate of how strongly neighbouring vertical wires affect each other. If the only grader of that estimate is software written by the same lab, a buyer’s reviewer cannot treat its accuracy figures as independent.
- Why now. Chiplet packages are going vertical: the UCIe chiplet-interconnect standard now covers stacked, three-dimensional packaging, with bonded connections spaced as little as a micron apart (report). The closer those vertical connections sit, the more a package team depends on a coupling model its reviewers can trust.
- What the lab showed. On every sample set FastCap graded, and on the one slice of layouts Palace graded, the lab’s fast model of how electrical signals couple between the vertical wires of a chip package came closer to those two outside physics programs than the lab’s own pair-by-pair sum did, for one property, the charge they can store (capacitance). That sum is a baseline the lab defined, and the lab’s own records say full-wave field solvers do not use it.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): makers of fast chip-package and interposer extraction tools (electronic design automation vendors) and package signal-integrity teams.
- Limit. Capacitance only, against a pair-by-pair baseline the lab defined; the two outside programs disagree with each other about how accurate the lab’s own solver is.
Checked brightness ranges for chip prints
- The problem. Approximate printing checks can approve a mask pattern that the slow, accurate simulation would reject, and the error then shows up later.
- Why now. Simulating how masks will print already costs the industry tens of billions of processor hours a year, by NVIDIA’s account when it launched its GPU lithography library with ASML, TSMC and Synopsys (press release). A check that could sign a mask off faster than a full re-simulation would cut into that bill; the lab has not measured any such saving for its own checks.
- What the lab showed. A check of how a chip pattern will print that gives, for every point of the image, a range for its brightness. On every test mask the lab’s detailed simulation fell inside the range, apart from a rounding error in one internal step that the range leaves out.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): computational-lithography software vendors, mask-inspection vendors and foundry mask-signoff teams.
- Limit. Relative to the lab’s own imaging simulation on a finite set of test masks, not silicon.
The capacitance flat models leave out
- The problem. Chip-package models often treat each vertical connection as an infinitely long flat cross-section, which leaves out the charge stored at its two ends. That flat models leave out the ends is well known, and open three-dimensional tools such as FastCap can already size it.
- Why now. Chiplet packages are going vertical: the UCIe chiplet-interconnect standard now covers stacked, three-dimensional packaging, with bonded connections spaced as little as a micron apart (report). The closer those vertical connections sit, the more a package team depends on a coupling model its reviewers can trust.
- What the lab showed. The lab’s own three-dimensional solver measured how much of one simplified chip-package connection’s capacitance (its charge-storing capacity) flat, two-dimensional models leave out.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): chip-package and glass or silicon interposer design teams, and the extraction-tool vendors that serve them.
- Limit. One simplified connection, a bare cylinder; whether the missing share changes any figure the lab’s own models sign off on has not been tested.
Pair-by-pair coupling estimates overstate the worst case, in a model
- The problem. The lab’s starting point is that fast chip-package tools estimate the coupling within a group of vertical wires by adding it up one pair at a time; its record gives no source for which commercial tools do. In the sources the lab searched (listed below), how wrong that pair-by-pair sum can be appears only as sampled examples, not as a guaranteed minimum over a whole family of layouts.
- Why now. Chiplet packages are going vertical: the UCIe chiplet-interconnect standard now covers stacked, three-dimensional packaging, with bonded connections spaced as little as a micron apart (report). The closer those vertical connections sit, the more a package team depends on a coupling model its reviewers can trust.
- What the lab showed. A proof, over every layout in one narrow family in a simplified model, that adding up coupling one pair at a time always overstates the worst case by at least a stated minimum.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): makers of fast chip-package and interposer extraction tools (electronic design automation vendors) and package signal-integrity teams that use such tools.
- Limit. A simplified model, not a full field solve; against the lab’s more exact solver the over-estimate is smaller, measured on examples only.
Signing off some tiles near a chip-mask edit, in simulation
- The problem. After a small change to a chip-mask design, the affected tiles are normally fully re-simulated and re-checked, which is slow at full-chip scale. The lab’s own tests show this method does not yet relieve that much: on its test edits it saved only a small share of the recomputation.
- Why now. Simulating how masks will print already costs the industry tens of billions of processor hours a year, by NVIDIA’s account when it launched its GPU lithography library with ASML, TSMC and Synopsys (press release). A check that could sign a mask off faster than a full re-simulation would cut into that bill; the lab has not measured any such saving for its own checks.
- What the lab showed. A method that signs off, in the lab’s own simulator, a small piece of a chip-mask design (a tile) next to a small edit as still valid without recomputing it. It applies when a bound the lab computes on the edit’s effect fits inside the tile’s safety margin; this site does not name what checks that bound.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): mask-synthesis and physical-verification software vendors (mask correction and mask-data preparation).
- Limit. The sign-off applies only when the edit fits a tile’s margin: on the lab’s test edits it spared recomputing only about 1% of tiles.
Included for this area. Each result’s page and the lab’s files that state it (linked above; the command the lab ran is named in the lab’s file; its code is not public); the open-source code and demos those pages link: interval-core; and the verifier, which checks in your browser that a result file’s fingerprint matches the one this site lists; it does not re-run the result. Terms are to be discussed.
Reach the founder. Write to nick@latticegraph.com, and say which area you mean. The founder is Nick Harris.
AI-cluster and wireless networking
Fixed-size memory for reordering AI network data
- The problem. AI clusters spread traffic over many network paths, so data reaches the receiving network card out of order. A card that holds it in a buffer until it can be put back in order needs on-chip memory that grows with the data in flight.
- Why now. The Ultra Ethernet Consortium published version 1.0.2 of its specification, dated 2026-01-28. Its architecture paper (Hoefler and others, arXiv 2508.08906, 2025-08-12) says that unordered transport modes may deliver data to memory out of order. STrack, a published transport for AI clusters (arXiv 2407.15266, 2024), also allows out-of-order delivery over many paths.
- What the lab showed. In the lab’s own network simulator, a network-card design that keeps track of out-of-order data in a small, fixed amount of memory, compared on the same simulated grid with the lab’s model of STrack, a published fixed-size design, and with a second bounded-state design in the lab’s simulator.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): makers of network-interface cards and switch chips for AI data-centre Ethernet, and large cloud operators that design their own cluster networks.
- Limit. Against a second bounded-state design in the lab’s simulator, which the lab calls CTS, the lab’s record gives 1.443x, CTS better in 31 of 64 simulated cases, a ratio of CTS’s memory to the lab design’s whose averaging it does not state; gaps are often tens of bytes, so the result is mixed; STrack needs less in some cells. A simulation, not silicon.
An Ultra Ethernet recovery design, proved in a model
- The problem. A designer of network cards that use the ordered-delivery mode of the new Ultra Ethernet standard wants machine-checked evidence that a given design for the loss-recovery step (the step that deals with data that has gone missing) keeps the standard’s rule that data leave in sequence order.
- Why now. The Ultra Ethernet Consortium published version 1.0.2 of its specification, dated 2026-01-28. The rule this result checks is one sentence of it: in the ordered delivery mode, data must be delivered in the order of their sequence numbers.
- What the lab showed. A machine-checked proof, in the lab’s one small model, that its design for the loss-recovery step of Ultra Ethernet’s ordered-delivery mode (the step that deals with data that has gone missing) never passes data on out of sequence order, or twice; it is about ordering, not delivery.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): makers of network cards, switches and chips for artificial-intelligence data-centre networks implementing the Ultra Ethernet standard.
- Limit. One small model, and about ordering, not delivery; it does not show the standard requires this design.
An automated attack search against quantum-safe Wi-Fi sign-in
- The problem. A designer’s own list of attacks tests only what the designer thought of, so the lab’s claim that its repairs close combined attacks rests only on the attacks the lab thought to write down. The search is “unseeded” in one sense only: it was given no starting attack sequence and no hint of which combination works. It still builds its attempts from the lab’s own list of known attack moves, so it can find only combinations of those moves.
- Why now. NIST has published ML-KEM, its standard for quantum-resistant key exchange (the standard), so sign-in designs built on it now need testing against combined attacks, not only the ones on a known list.
- What the lab showed. An automated search, given no starting attack sequence and no hint of which combination might work, tried combinations of moves from the lab’s own list of known attacks against the lab’s hardened models of quantum-resistant Wi-Fi sign-in designs, and, within a small fixed budget, found no combined attack that got through.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): Wi-Fi chipset and access-point vendors, and Wi-Fi certification and test labs, assessing quantum-resistant sign-in designs.
- Limit. A null result within a small fixed budget, against the lab’s own software models, not real Wi-Fi software.
A memory ceiling for post-quantum Wi-Fi, proved in a model
- The problem. In the lab’s model, an access point keeps half-received quantum-resistant sign-ins in memory until the devices sending them are verified. In that model, capping the memory per connection alone does not stop an attacker who opens many connections at once from exhausting the access point’s memory.
- Why now. NCC Group’s 2026 write-up “WPA3 Denial of Service: SAE Resource Exhaustion” describes how an access point with too many sign-in exchanges pending can stop accepting new costly attempts and ask for a token instead. It is about today’s WPA3 sign-in, not the quantum-resistant one this result concerns.
- What the lab showed. In the lab’s model of its admission-control module (the code that decides which sign-ins an access point accepts), a machine-checked proof that an access point’s memory for half-received quantum-resistant sign-ins stays capped, however many devices an attacker connects.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): enterprise Wi-Fi access-point and controller vendors, and Wi-Fi chipset firmware teams, preparing for quantum-resistant sign-in.
- Limit. In the lab’s model the access point reserves four 16 KiB slots and refuses a fifth; the lab’s account is that four unfinished sign-ins therefore block other devices. Whether slots expire is not stated in the files we serve.
Included for this area. Each result’s page and the lab’s files that state it (linked above; the command the lab ran is named in the lab’s file; its code is not public); the open-source code and demos those pages link: pqc-bounds-lean, pqc-explorer; and the verifier, which checks in your browser that a result file’s fingerprint matches the one this site lists; it does not re-run the result. Terms are to be discussed.
Reach the founder. Write to nick@latticegraph.com, and say which area you mean. The founder is Nick Harris.
AI-agent platforms and inference infrastructure
Crash recovery for AI assistants’ multi-step changes
- The problem. An assistant whose program dies halfway through a multi-step change can leave files and database rows half-updated, with nothing to finish or undo the change afterwards. Databases solve this with a standard design, a log written to disk before the changes; the lab applies it to an assistant’s tool calls.
- Why now. Other researchers have published transaction layers for AI agents’ tool calls: SagaLLM (arXiv 2503.11951, first submitted 2025-03-15) and Cordon (arXiv 2606.17573, submitted 2026-06-16). That published work shows the problem is being worked on now.
- What the lab showed. A transaction layer meant to finish or undo an AI assistant’s multi-step change after a crash, for plans it accepts before they run. At every crash point the lab chose, it recovered the change whole or not at all; killed at random moments, some recoveries were not, and the lab has not fixed that yet.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): AI agent-platform teams that let assistants make changes to files and databases.
- Limit. 2,893 further kills at seeded random moments found 31 recoveries that were not atomic (recorded in the lab’s claim; the run record is not published); the lab has not fixed them yet. Power cuts are untested.
Tool combinations that leak a secret
- The problem. A platform that approves an assistant’s tools one at a time, or two at a time, can let a combination of three tools leak a stored secret. Ordinary tracking of where a secret’s data flows (taint analysis) already closes that gap; what this adds is a run the lab reports as executing every combination of up to three calls (this site does not show how its runs map onto those combinations).
- Why now. Two published write-ups describe dangerous combinations of AI-assistant tools: Simon Willison’s “lethal trifecta” (2025-06-16), which says an agent that combines private data, untrusted content and outside communication can be tricked into sending the private data to an attacker, and Invariant Labs’ analysis of “toxic flows” in agent systems (2025-07-29).
- What the lab showed. A run the lab reports as exhaustive, in a test world the lab built, over every sequence of up to three AI-assistant tool calls, finding the smallest combinations that leak a stored secret.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): AI agent-platform and runtime-security teams that decide which tool combinations an assistant may use.
- Limit. One test world the lab built; a standard technique, tracking where the secret’s data flows, would also catch all three.
The least bookkeeping a shared AI cache needs, in a model
- The problem. A provider that serves many customers from one shared model cache must never hand one customer’s cached work to another, yet wants to reuse it whenever that is allowed. The question is how much permission bookkeeping that takes.
- Why now. Published work on shared caches in AI serving: SafeKV (arXiv 2508.08438, 2025) shares cached work between customers selectively to avoid timing leaks, and a 2026 paper (Addagada, arXiv 2608.09225) describes how a cache shared across customers lets one customer reconstruct another’s private prompt by probing how fast cache hits return.
- What the lab showed. A machine-checked proof that a shared AI cache which never leaks between customers and always reuses what it may must remember at least one bit for every pairing of a customer with a cached item, where any item can be shared with any group of customers (the lab’s “dense rights model”).
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): confidential-AI product teams at cloud providers that serve many customers from one shared model cache.
- Limit. Holds only when any cached item may be shared with any group of customers; if each item belongs to one customer, far less bookkeeping is needed. The counting argument is classical, not new.
Included for this area. Each result’s page and the lab’s files that state it (linked above; the command the lab ran is named in the lab’s file; its code is not public), and the verifier, which checks in your browser that a result file’s fingerprint matches the one this site lists; it does not re-run the result. Terms are to be discussed.
Reach the founder. Write to nick@latticegraph.com, and say which area you mean. The founder is Nick Harris.
Data deletion
Where deletion receipts can be fooled
- The problem. Services that hold customer data, such as cached AI conversation state, are asked to prove they deleted it. A receipt that only proves a key was destroyed is easily mistaken for proof that the data is gone.
- Why now. NIST’s guidance on wiping media, SP 800-88 Rev. 1 (December 2014), says that erasing by destroying a key should not be trusted where a copy of the key may exist elsewhere. NIST withdrew that revision on 26 September 2025 and replaced it with Rev. 2; our record does not say what Rev. 2 changes.
- What the lab showed. In a small simulated setup, six concrete ways a signed deletion receipt can check out while the data is still recoverable or was never deleted.
- Who we expect would buy. Teams we expect would care (no customer or pilot yet): AI inference and cloud providers that must show customers or regulators that data was deleted, and the auditors who check them.
- Limit. A small simulated setup, not an AI serving system; a set of failure modes, not a deletion guarantee.
Included for this area. Each result’s page and the lab’s files that state it (linked above; the command the lab ran is named in the lab’s file; its code is not public), and the verifier, which checks in your browser that a result file’s fingerprint matches the one this site lists; it does not re-run the result. Terms are to be discussed.
Reach the founder. Write to nick@latticegraph.com, and say which area you mean. The founder is Nick Harris.
Every result states what it does not show yet on its own page, and the lab’s own checks are described there; no outside firm has audited them.
How we show numbers
Every number on this site links to the file it comes from. How each result is checked
- We never show a number before its file has loaded.
- A question we have not checked yet is marked as unchecked.
- A check that found nothing says so.
- A file with no value for a question says so.
- A number whose file is missing or has changed is not shown.
- Two files that disagree about what a number describes are both flagged.
- A number from too few samples shows its sample size.
- Two files that give different values are both shown.
- A file we cannot publish is listed by its fingerprint only.
- A measurement more than a week old shows its age.
- A question that does not apply to a page is left off it.
- A measurement whose program failed is shown as failed.