When the Cut Disappeared

Research often advances by finding a clean way to measure a difficult object. This repository began exploring whether graphical boundaries and discrete invariants could help reason about major mathematics problems. Its working method pairs written proof obligations with small programs: computations can check finite examples or uncover counterexamples, while general claims still need proofs that cover every object in scope.

The most concrete software result so far is a compact Go package for Boolean circuit graphs. A circuit is represented as gates and wires. The package checks gate types and fan-in, validates references and cycles, and evaluates an explicitly supplied partition of the graph. It reports which wires cross between the two sides and calculates the exact interface-state count, 2^w, using arbitrary-precision integers. Tests use a parity circuit and a two-bit ripple-carry adder to check crossing counts and capacities.

That is a useful measuring instrument, but it is not a lower-bound proof. The research notes state this boundary directly: finite cut measurements do not show that a function requires large cuts, that a cut lower bound implies circuit size, or that a result for a restricted geometric model transfers to unrestricted circuits. The roadmap also treats visualization as a way to make a precise argument inspectable, not a substitute for the argument.

The counterexample that changed the plan

The most instructive episode came after the first driver was delivered. The proposed statistic, a minimum balanced cut width, seemed to offer a route from circuit structure to complexity. Ticket 002 records a simple stress test: take any circuit and append a sufficiently long serial chain of double-NOT gates. Each pair preserves the output function. Yet the extra vertices let a balanced partition run through that chain while crossing only one wire. So the measured width can stay at most one even as the representation grows. Taking a minimum over circuits for a function does not repair the problem, because the padded representation is still available for every function.

The response was to stop advancing the route. The September 28 research note and issue closure record the consequence: ordinary circuit size is padding-stable, but it is already the target measure and does not supply the hoped-for cut-derived replacement. Any new invariant must survive harmless changes of representation and satisfy both a lower bound for every circuit computing the target and an upper bound in terms of circuit size. The repository marks those obligations explicitly rather than presenting the finite driver as mathematical progress toward P versus NP.

This is a valuable pattern for agentic research and software work. A small implementation can make a definition concrete enough to test. A ticket can give the investigation an acceptance boundary. A counterexample can close a line of work, and the roadmap can preserve why it stopped so the same idea is not quietly revived as a theorem. Here the code's role is deliberately modest: make a finite claim reproducible, and help expose when the claim is too weak.

The visible history shows a concentrated burst of 21 commits from September 27 to 28, 2026, including the circuit package, research dossiers, two tickets, and a revision of the P-versus-NP plan. Issue 001 records that the quota-enforced test command passed (go vet ./... and go test ./...) when the driver was completed. The current tree has a single Go test file with validation cases and the parity and adder fixtures. The repository documents a Harnez workflow and names theory and driver agent roles, but the commit history alone cannot establish which agent sessions ran or how work was divided. The clearest evidence of harness use is the issue-based trace from implementation through verification and then falsification.

There is still basic repository polish to address. The module contains a library package, but the root Makefile advertises build, run, and install targets aimed at an executable at the module root; issue 001 already notes that installation failed. Capturing this as an open issue is part of keeping the record honest: an elegant research question and a passing package test do not make every project command usable.

Facts

The project does not claim to have solved a Millennium problem. Its strongest public story is more useful and more credible: build a small instrument, state what it can establish, and let a counterexample change the research plan.