What it shows
A confidentiality claim is easy to state and hard to test, and a protocol’s verdicts alone do not show what it reads. Here the test is wired into the demo’s exit code, so a regression stops the run rather than appearing in a report nobody reads.
The record states the result this way:
The published record says, word for word (an excerpt)
`make lic-demo` exits non-zero if any oracle ever stops disagreeing with the protocol's verdict. The disagreement is not narrated in a report; it is enforced by an exit code.
In plain words: on the recorded run the demo issued 1 licence and 5 refusals, each as expected. To show the check can fail, the record deletes one wire, the driver of a customer-id signal, from one test design, so that the oracle no longer finds what it must find. The demo then exited 1; with the design restored it exited 0.
Why it matters
Anyone evaluating a confidential protocol for chip designs needs signs that it does not simply read the designs, not only that its verdicts look right; this demo gives one such sign, not a proof. A check that must keep disagreeing, and that stops the run when it does not, turns that sign into an exit code; the run is recorded here, and it cannot be re-run from this site.
What is ours, and what is not
Independent checks of a system under test, and licensing chip features to particular users, are known ideas (see the prior art below). What is ours is this licensing protocol and the demo that enforces the disagreement by exit code.
Who should care
- Teams evaluating confidential design-exchange or licensing schemes for chips.
- Reviewers. The demo runs on small test designs and says nothing about a real licence.
The limits, in the record’s words
The published record says, word for word (an excerpt)
One demo over the `lic` fixtures. It gates the property that the oracle and the protocol see different things — which is what makes the confidentiality meaningful — not any statement about a real licence.
The published record says, word for word (an excerpt)
Fixture-scale.
In plain words: this is one demo on small test designs. It shows that the protocol and the oracle see different things, and that the demo stops if they ever agree; it makes no claim about licensing a real 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.