· VerifyCore Labs
Ten results, and who they are for
Every result on our home page in one place: the lab’s own plain statement, its figure, what it means for the team that would use it, and what it does not claim.
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.
VerifyCore Labs is an AI research lab. Our agents do the research, and every result links the lab’s file that states it; where the run record behind a figure is not published, the result’s page says so. Below are ten of our results. Each comes with one figure, what it means for the team that would use it, and what it does not claim.
A fast coupling model, graded by outside solvers
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.
FastCap graded the sample sets and Palace graded one slice of layouts only. On every sample set measured, the lab’s fast model came closer to them than the lab’s own pair-by-pair sum did.
What it means for you
If you buy or build fast extraction tools: accuracy graded only by a vendor’s own software is not independent. Here two outside programs served as graders: FastCap graded the sample sets and Palace one slice of layouts only, and on them the lab’s fast model came closer than the lab’s own pair-by-pair sum did. What this gives a buyer today is a fast model checked against outside programs for one property; it does not yet give a reliable size for the improvement.
What it does not claim
- It covers capacitance only, and only the model’s coupling numbers between different wires.
- Inductance still comes from the lab’s own two-dimensional solver, because the outside tool for it returns an unusable answer on the multi-wire case.
- The Palace check covers a single coupling-heavy slice of layouts, with most of its points left out.
- The lab’s own record holds several different figures for how much closer the fast model came to FastCap, so this site prints no size for the improvement.
- What it beats is the lab’s own pair-by-pair sum, a baseline the lab defined; the lab’s own records say full-wave field solvers do not use that sum.
Fixed-size memory for reordering AI network data
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.
The lab ran its own network simulator over a grid of 64 simulated cases. In it, the lab’s model of STrack, a published fixed-size design by Le, Pan and Newman, needs this many times the reorder memory that the lab’s design does, on average (a geometric mean). The lab’s own check confirms the figure only to two decimal places, so read it as about twice. In bytes the gap is often small, and in some cases STrack needs less.
What it means for you
If you build network cards or switch chips for AI clusters: traffic spread over many paths arrives out of order, and a card that buffers it needs memory that grows with the data in flight. This design keeps a small note of fixed size instead. Measured against the lab’s model of a published fixed-size design (STrack) on the same simulated grid it uses less memory on average, but often by only tens of bytes.
What it does not claim
- It is a network simulation, not silicon, and every number comes from the lab’s own simulator, including its model of each design it is compared with.
- The fixed-size designs it is measured against are the lab’s model of STrack, a published design by Le, Pan, Newman and others, and a second bounded-state design in the lab’s simulator: the lab’s model of the receiver-driven clear-to-send (CTS) admission Meta describes (Gangidi and Zeng, SIGCOMM 2024, section 5.2.2).
- No public Meta source states that design’s reorder memory.
- Against both, the memory saving is small, often tens of bytes, and in some cells they hold less memory: the second design nearly half the time.
- The lab’s files also show much larger savings.
- Those compare against cards that buffer all out-of-order data, which is not the fair comparison, or are separate measurements that must not be added together.
- They are in the exact wording.
- STrack was added to the lab’s adversarial test runs against the design only late in the work; the details are on the evidence page.
Checked brightness ranges for chip prints
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.
For every pixel of each one, the brightness the lab’s detailed simulation gives fell inside the range the check computed. An approval check built on the ranges made no wrong approvals after a fault the lab found was fixed; that count is from a smaller approval test on some of the same masks on which the fault was found, not a held-out test.
What it means for you
If you sign off masks or sell the software that does: an approximate check that approves a pattern the slow simulation would reject costs you later. This check computes a brightness range for every point of the image, and on the lab’s test masks the detailed simulation never fell outside it; the range leaves out the rounding error of one internal step. What it gives a buyer today is a finite test against the lab’s own simulation, not a guarantee about real silicon.
What it does not claim
- The range is checked against the lab’s own detailed simulation on one fixed grid, not silicon, and it leaves out one rounding step, so it is not a guarantee.
- The range leaves out the rounding error of one internal calculation step, so the lab’s word “guaranteed” holds only apart from that error.
- The lab’s record gives no size for that error.
- It is a finite set of test masks, and the checks within one mask are correlated rather than independent trials.
- Before the lab found and fixed a fault, the approval check built on the ranges gave 90 wrong approvals in the same test.
- After the fix it gave none, on the same set of test masks where the fault was found.
- Cases just across a threshold are untested: not observed, and not excluded.
- The speed figures the lab quoted before 2026-09-24 did not match the file they were taken from and are no longer claimed; its current timings depend on machine load and are corroboration only.
Crash recovery for AI assistants’ multi-step changes
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.
The lab killed the program mid-change at each of them, and each time a fresh program recovered the change whole or not at all from the log on disk.
What it means for you
If your assistants change files and databases, a change that dies halfway can leave them half-updated, with nothing to finish or undo it. This layer writes each change to a log on disk first and recovers from it after a crash, for plans it accepts before they run. At the moments the lab chose, recovery was all-or-nothing every time. At random moments it was not always, and the lab publishes their count (the run record is not published), which is what a buyer needs to know before relying on it.
What it does not claim
- It covers only plans the layer accepts before they run.
- A plan is accepted only if it has at most one action that cannot be undone (such as sending a message), that action comes last, and it carries a replay key (a label that makes repeating the action harmless).
- Other plans are refused or left for a human operator.
- At the moments the lab chose, every recovery was all-or-nothing.
- Killed at random moments instead, some recoveries were not, and some undid work that had already been committed.
- This is recorded in the lab’s claim; the run record is not published.
- The lab has not fixed these failures yet.
- The tests killed the program; they did not cut the power, so whether the log’s writes reach the disk in the right order is untested.
- The random kills sample the ways a crash can happen (they reached 85 distinct crash states) rather than covering them all.
- The world tested is small: a set of files and one database table, with scenarios and a grader the lab wrote.
- The method is standard in databases, and other researchers have published transactions for AI agents’ tool calls already: SagaLLM and Cordon.
The capacitance flat models leave out
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.
of one simplified connection’s capacitance (its charge-storing capacity), measured with the connection driven as one of a pair, sits at its two ends, which flat, two-dimensional models leave out. The lab’s own solver was checked first against shapes with exact answers, then against FastCap, an outside solver run on the lab’s own mesh of the shape.
What it means for you
If you design chip packages or sell the software that models them: a flat model of a vertical connection misses the charge stored at its two ends by construction. The lab built its own three-dimensional solver to measure that share and checked it against shapes with exact answers and against FastCap, an outside solver run on the lab’s own mesh. What this gives a buyer today is a measured size for what a flat model leaves out on one simplified connection, not yet a correction shown to matter on a real package.
What it does not claim
- It is measured for one simplified connection: a bare cylinder in a uniform insulator at one standard size, without the pads and metal planes a real package connection ends in.
- The share is of the capacitance when the connection is driven as one of a pair (the lab’s “driven-pair” capacitance).
- That flat models miss the ends is well known.
- Whether the missing share changes any figure the lab’s own models sign off on has not been tested.
- FastCap ran on the lab’s own mesh of the shape (the grid of small patches the shape is split into).
- FastCap’s own answer changes, when that mesh is made finer, by about as much as the two solvers differ from each other.
- So the mesh alone could explain the difference, and closer agreement than that cannot be claimed.
- No automated check in the lab’s code recomputes this result’s headline share, so treat that figure as a measurement reported once, not one re-checked on every run.
- The lab uses the measured end share as a correction in one of its two-dimensional solvers only, checked for layouts up to the size the lab labels N=8.
- It is not yet built into the lab’s sign-off certificates, and the lab’s other two-dimensional solvers still leave the ends out.
An Ultra Ethernet recovery design, proved in a model
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.
that in the lab’s one model (only one of them without a size limit) its recovery design never passes data on out of sequence order, or twice. It shows this design meets the standard’s rule; it does not show the standard requires this particular design.
What it means for you
If you build or test Ultra Ethernet network cards that use its ordered-delivery mode: machine-checked evidence that this design for the loss-recovery step keeps the standard’s ordering rule, in the lab’s one model. It shows the design meets the rule; the standard allows other designs that also meet it, so it is not a reason every implementer must use this one.
What it does not claim
- It is a result in one small formal model.
- It is not a legal opinion, and not a claim that the design is essential to the standard; no professional opinion has been obtained.
- It runs one way only: the standard’s words do not require this design.
- In the same model, 39 different compliant receivers do without it.
- It is about ordering, not delivery: the model has no lost-data resend, and no receiver in it is guaranteed to make progress.
- A receiver that delivered nothing would also satisfy the rule.
- Only the ordered-delivery mode of the standard is modelled, and the state spaces are small.
- Two of the four checking tools were run only on a small version of the model, with two pieces of data over two paths.
- Only one of the four is unbounded: it is not limited to a small fixed model size, as the other three are.
- All four check the same model, so a modelling mistake would pass all four together.
Pair-by-pair coupling estimates overstate the worst case, in a model
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.
Adding up coupling one pair at a time does this for every layout in one narrow family, inside the lab’s simplified physics model. The computer search covered the whole family, not a sample. Inside that simplified model it guarantees a minimum size for the overstatement; the limit line below says what happens against the lab’s more exact solver.
Adding up coupling pair by pair overstates the worst coupling by at least 1.10467× (at least 10.467%), rounded down from the certified value.
What it means for you
If you build or use fast extraction tools: in the sources the lab searched, the pair-by-pair sum appears only with sampled examples of how wrong it can be. This computer search covers every point of one family of four-connection layouts and gives a guaranteed minimum over-estimate in that model, not a sample. A too-high estimate errs on the cautious side, and our record does not say what it costs a package designer.
What it does not claim
- It holds inside a simplified physics model the lab froze, not a full field solve, for one narrow family of layouts whose sizes and spacings are held inside a fixed range.
- Against the lab’s more exact solver the over-estimate is smaller (about 9.8 percent) and was measured on examples only, not proved.
- It says nothing about fabricated or measured silicon, and nothing about what an over-estimate of this size costs a package designer or whether it matters for sign-off.
- The claim assumes that fast extraction tools add up coupling pair by pair.
- The lab’s own record notes that no source is given for which commercial tools do.
- One paper in the lab’s prior-art list treats pairwise against many-body electrostatics rigorously, for a different shape (dielectric spheres).
Tool combinations that leak a secret
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.
covered, by the lab’s account, every sequence of up to three AI-assistant tool calls in the lab’s test world. Three smallest combinations leak the stored secret and only one of them is a pair, so approving tools two at a time misses the other two. This site does not show how the number of runs maps onto the number of sequences.
What it means for you
If you decide which tools an AI assistant may combine: approving tools one or two at a time can miss a combination of three that leaks a stored secret. This is an executed record, which the lab reports as exhaustive, of which combinations are dangerous in one test world, run on real files and a real database.
What it does not claim
- It is one constructed test world: ten tools, one stored secret, outlets the lab designed, and a verdict that depends on three of the five trust assumptions the lab declared, meaning assumptions about what the test may take as trusted.
- This site does not list the five.
- A standard technique, tracking where the secret’s data flows (taint analysis), would also catch all three combinations.
- What this adds is an executed record of which combinations leak.
- The run-time check that enforces the result lets an approval be used only once, but it remembers that only while the program runs.
- In the lab’s test, one approval used for three calls of the network-send tool let exactly one copy of the secret reach the outlet, so the once-only rule held while the program ran.
- But nothing stores that the approval was used, so an approval loaded again from disk, or shown to another process, counts as unused and works again.
- The result is about the lab’s ten tools; it is not shown for the tools of real assistants.
Where deletion receipts can be fooled
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.
a signed deletion receipt can check out while the data is still recoverable or was never deleted, shown against the lab’s two receipt checkers, including a colluding auditor whose receipt both checkers accept.
What it means for you
If you must show customers or regulators that data was deleted: a receipt that only proves a key was destroyed is easily mistaken for proof that the data is gone. The lab built two checkers for such receipts and published the ways each can be fooled, including a colluding auditor, so a buyer knows what a receipt does not prove.
What it does not claim
- It is a small simulation, not a real deployment: the data sits in an ordinary file on one computer that the program reads straight into memory, not in an AI serving system or on a GPU.
- It shows how a deletion receipt can be fooled in that setup; it is not a measurement of any real AI serving system.
- The deletion technique, throwing away the key that unlocks the data, is standard and not the lab’s.
- The result is a set of demonstrated failure modes, not a deletion guarantee: it says what a receipt does not prove.
- Both receipt checkers were written by the lab, and they accept a colluding auditor’s receipt when nothing was erased.
- A cryptographer has not reviewed them.
Signing off some tiles near a chip-mask edit, in simulation
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.
In the lab’s single-edit tests, checks against a full recomputation, point by point, found no tile the method signed off that was worse. That is 0 violations across 9,175,040 comparisons; this site does not say how many edits or tiles they came from.
What it means for you
If you sell mask-correction or verification software: fully re-simulating every affected tile after every change is the slow step at full-chip scale. This method signs a changed tile off when a bound the lab computes on the edit’s effect fits inside the safety margin the tile already had. On the lab’s test edits it has so far spared only a small share of the recomputation.
What it does not claim
- The sign-off applies only when the edit’s computed effect fits inside a tile’s margin, and on the lab’s test edits that spared only a small share of the recomputation (the figure is in the limit line above).
- This site does not name what checks the bound on an edit’s effect, and the bound relies on the edit’s declared reach (its “declared halo”) being right, as the chain test below shows.
- It is shown for single, isolated edits in the lab’s own simulator, not on silicon.
- The lab also tried a chain of four edits in a row.
- It set the “declared halo” (how far an edit is declared to reach) to zero on purpose, a setting it stamps “not a certificate”.
- Then it let through 9 of 64 tile checks that came out worse than a full recomputation, by up to 4.3267 nm (nanometres).
- Declared honestly, the same chain let none through.
- Soundness over chains of edits in general is not established.
- Grey or partial edits, and other masks, are not covered.
- The lab’s own record also says that beyond the point where the mask stops printing correctly (its “printability cliff”), the method costs more time than recomputing.
Where to go next
Each result has its own page with the problem, its limits in plain words, the lab’s exact wording and figures, the prior work it builds on, and the files to check it yourself.