What it shows
A protocol that keeps each design private cannot be checked against the full answer from inside the protocol, because nobody inside it has the full system. A test needs an outside view that has everything.
The record states the result this way:
The published record says, word for word (an excerpt)
`scr/1.0`'s `flatten_assembly` + `oracle_depends` construct the whole-system netlist across all four PRIVATE designs at once — something no participant and no verifier can do — and solve the miter directly, giving an independent ground truth to check the protocol's verdict against.
In plain words: the test-only check joins the four private test designs into one circuit and solves the question directly, so the protocol’s verdict can be compared with an answer reached without the protocol. The recorded test run printed 48 passed in 12.02s. To show the comparison can fail, the record makes the check answer without solving; the test suite then exited 1, and with the code restored it exited 0.
Why it matters
A confidential protocol’s verdicts are only worth trusting if they have been checked against the true answer somewhere. An outside check with full access, used only in testing, gives that answer for the test designs.
What is ours, and what is not
Joint computation over private inputs, and solving a property of a combined circuit directly, are known (see the prior art below). What is ours is this protocol and the test-only check built against it.
Who should care
- Teams evaluating confidential multi-party chip design checks.
- Reviewers. The check is a test instrument on small test designs, not something the protocol ships.
The limits, in the record’s words
The published record says, word for word (an excerpt)
An oracle used to TEST the protocol; it is not part of the trust chain and could not be deployed, because its power is exactly the power the protocol denies its participants.
The published record says, word for word (an excerpt)
Fixture-scale, combinational, and the oracle is a test instrument rather than a shipped capability.
In plain words: the outside check could never be part of the protocol, since it needs every private design; it exists only to test the protocol. The tests use small combinational designs, not a full chip.
Open source for this step
Tools and datasets we publish for the package step of building a multi-chip package. They are the checkers around this work, not a copy of the result itself.
- physics-lint: One command that checks a folder of physics models against a fixed set of named physical rules, with findings straight into CI.
- maxwell-lint: Flags a coupling extractor whose answers no passive set of conductors could produce.
- sparam-lint: Is your signal-response model physically possible? Five physical laws checked from the command line.
- interval-core: The interval arithmetic core behind our proofs over whole families of layouts.
- touchstone-tools: Read, write and convert Touchstone files, the standard text files that record how signals pass through a package's connections, and refuse to write one that cannot be read back.
- physics-lint-mcp: The physics checks, callable by an AI agent.
- physics-lint-action: A GitHub Action that fails the build when a model breaks one of a fixed set of named physical rules.
- Signal-response validity corpus: A labelled corpus of physically invalid signal-response networks, and a scorer that grades any checker against it.
- screening-ceiling: The screening-ceiling family as an open dataset.