Four weighted fractional certificates for n = 26, 29, 39, 40, accepted by `sqpack.fractional.certificate.verify`

---

Hello. I have four weighted fractional unavoidable-set certificates that improve the lower bounds this repository currently records for `n = 26, 29, 39, 40`. Each one is accepted by **this repository's own verifier**, unmodified, at commit `80bcdbb`.

Everything is at **https://github.com/wand125/square-packing-bounds** — the four certificates, both checkers, and the search code. I am filing an issue rather than a pull request because there is no `CONTRIBUTING.md` and the operating rules read as an internal agent workflow. Please tell me the form you would want this in, if you want it at all.

## What the certificates prove

| `n` | this repo, `verified_lower_bound` | this repo, `reported_lower_bound` | certificate | over verified | over reported |
|---|---|---|---|---|---|
| 26 | 5.12310562562 (Nagamochi) | 5.3918 (Green, via DS7) | **109/20 = 5.45** | +0.327 | +0.058 |
| 29 | 5.472135955 (Nagamochi) | 5.511708697746 (Green, via DS7) | **557/100 = 5.57** | +0.098 | +0.058 |
| 39 | 6.29150262213 (Nagamochi) | 6.350603018684 (Green, via DS7) | **13/2 = 6.5** | +0.209 | +0.149 |
| 40 | 6.38516480713 (Nagamochi) | 6.406135888746 (Green, via DS7) | **13/2 = 6.5** | +0.115 | +0.094 |

The `n = 40` certificate is not an independent result — a box that fails to hold 39 cannot hold 40, so it follows from the `n = 39` certificate by monotonicity. I built it anyway as a cross-check on the generator, and it is included on that basis only.

Note what the middle column is. For all four cases the standing figure above Nagamochi's closed form is Green's, cited by Friedman's DS7 as a private communication, with no recovered proof. Your `n-029.md` already records this: *"Green's reported lower-bound proof, cited as private communication by Friedman, has not been [verified]"*. These certificates would move all four from `reported` to a machine-checkable footing, and raise the value at the same time.

By monotonicity the `n = 39` bound also covers `n = 40..44` against the DS7 table, and `n = 26`, `n = 29` cover `27` and `30`.

## Verification with your own code

The certificates are JSON: `n`, `L`, `B`, the direction net, and the atom list as exact rationals. The only conversion needed is the net, which we store as a rule rather than a list — `theta_r = 2*atan(r * 83/40000)` for `r = 0..200`, so the half-angle tangents you want are exactly `r * 83/40000`.

With `src/check_with_sqpack.py` from that repository, in the root of a `squares` checkout:

```
$ python3 check_with_sqpack.py cert_n29_L557.json
=== cert_n29_L557.json
n = 29 L = 557/100 = 5.57
atoms = 748 total mass = 453011/15625 = 28.992704 budget = 29
accepted = True (13.8s)
[ok ] Condition 1 atoms carry the declared symmetry: 748 atoms closed under D4 about the centre
[ok ] Condition 2 total mass below n: total 453011/15625 against n = 29
[ok ] Condition 3 net reaches pi/4: final half-tangent 83/200, t^2 + 2t - 1 = 89/40000
[ok ] Condition 4 containment B(1 + D) < 1: B = 9977/10000, D = 83/40000, B(1 + D) = 399908091/400000000
[ok ] Condition 5 every reachable cell carries mass 1: least cell mass 1000003/1000000 at direction 0
=> s(29) >= 557/100 = 5.57
```

All four, single worker, on one laptop core:

| `n` | atoms | distinct under D4 | total mass | margin under `n` | `verify` |
|---|---|---|---|---|---|
| 26 | 1376 | 179 | 646393601/25000000 = 25.855744 | 0.144256 | accepted, 28.2s |
| 29 | 748 | 100 | 453011/15625 = 28.992704 | **0.007296** | accepted, 13.8s |
| 39 | 2724 | 362 | 481487971/12500000 = 38.519038 | 0.480962 | accepted, 73.4s |
| 40 | 1892 | 250 | 975019903/25000000 = 39.000796 | 0.999204 | accepted, 45.1s |

`bounded_side` returns `L` in each case, so these are claims of `s(n) >= L` in the form your register carries. I have deliberately not divided by `B`.

The `n = 29` margin is worth a comment: `0.007296` under budget. That certificate sits very close to the ceiling, which is consistent with your `H-034-fractional-piercing-ceiling` framing.

## The other verifier, and why yours is the stronger one

Before running yours, these were checked by a verifier I wrote. It is construction-distinct from yours — a branch-and-bound recursion over centre boxes, not an event-cell sweep — but I want to be straight about the rigour gap, because it runs the other way from what "two independent checks" usually implies.

Mine decides Conditions 1-4 exactly in `Fraction`, and Condition 5 in float64 with an error budget: `EPS = 1e-9` on every geometric comparison, mass threshold `1 + 1e-9`, boxes not subdivided below `1e-7`. The argument that this is sound is that all coordinates are under 100 in magnitude and each compared quantity takes at most six floating-point operations, bounding the rounding error near `1e-13`, while the mass is a sum of at most `10^4` nonnegative terms under 1, bounding its error near `1e-11`. Weights are rounded *up* to multiples of `1e-8` so rounding can only add mass. I believe it, but it is an error-budget argument, not exactness.

Yours decides Condition 5 in exact integers on the weights' common scale, falling back to `Fraction` past `_INTEGER_MASS_LIMIT`, and takes a true minimum over event cells rather than testing a threshold. That is strictly stronger. It answers "what is the least covered mass" where mine answers "is it at least `1 + 1e-9` everywhere I looked".

So the accurate statement is not that these have two equal checks. It is that yours is the one that matters, and mine served as a cheap filter during the search. That your verifier accepts all four is the claim I would want on the record; the box counts from mine (4,811,681 / 2,524,711 / 8,409,303 / 7,531,281, zero failures) are search telemetry, not evidence of the same grade.

If your `epistemics.md` rungs treat a float64 sweep with a stated error budget as `numerically-checked` rather than `verified`, that reading matches how I would classify it myself.

## Attribution

The method is not mine. These are instances of the weighted fractional unavoidable-set certificate of **Burns** and **Massaccesi** (August 2026), which fractionalizes **Stromquist's** unavoidable point sets (1984 memos, EJC 2003) and descends from **Nagamochi's** (2005) weighted score systems. The rational direction net with the `B(1+D) < 1` shrink is Burns's and Massaccesi's; my `B = 9977/10000` with 201 directions is a parameter change, not a new idea. Row generation, dual-priced column generation, and branch-and-bound as the Condition 5 decider are all described in this repository.

What is mine is the choice to point the machinery at `n >= 22`, which as far as I can tell nobody had tried — every published certificate of this type I could find was built for 11 to 21 tiles — plus the search runs and the certificates themselves.

If any of the above misstates who did what, please correct me. I would rather fix it here than have it propagate.

## What I am asking

1. Are these of interest to the register at all?
2. If so, what form do you want — a PR adding `packing/cases/nNN_fractional_certificate/` entries in your layout, an update to the four `packing/frontier/n-0NN.md` records, or something else?
3. Is there a check you would want run before you would consider them, beyond `verify`?

Happy to do the work in whatever shape suits the repository. Equally happy to leave the files where they are and let you re-derive them with your own generator, which may be the cleaner provenance story on your side.

One note on the neighbouring record: `n-029.md` cites Schadt's `5.9338857998` upper bound. These are lower bounds, so the two do not collide — together they bracket `s(29)` between `5.57` and `5.9339`.

Start by reading the existing packing/frontier/n-0NN.md records, especially n-029.md, along with the certificate verifier entry point sqpack.fractional.certificate.verify. Run the four supplied certificates through the repository's verifier and compare the requested contribution form with the existing layout. Done means the maintainers have agreed on the format and the accepted certificates and bounds are recorded consistently, if they choose to include them.

Written by the indexing model from the issue text.