# Session 60: Where do the small three-dot marks recur?

**The 58-page screen found six text locations containing three isolated dots.** Three belong to line-break pairs containing four dots in total. Three are inline, on LP2 pages **38, 46 and 56**. The last is on an already solved page, where the known prime-based method continues across the mark without restarting.

This adds one source-label discrepancy to our current ledger: page 38, like page 46, has three visible dots where the master transcription records `-`. It is a correction to our representation of the pixels, not a newly decrypted passage or an established new-to-community discovery. **No new plaintext was recovered.**

## Screen first, then review

The [fixed screening plan](three_dot_scan_plan.json) covered all 58 original LP2 images, including solved pages 56 and 57. Page numbers here are zero-based; the retained JPEG archive numbers are 17 higher.

The script inspected each full 2400-by-3600 image. It selected small connected components with width and height 6–13 pixels and area 30–150 pixels, then grouped nearby components. Black and red masks were screened separately at three fixed thresholds each. The candidate set included every location with exactly three selected components at any threshold.

All source hashes matched the retained [JPEG manifest](jpeg_source_manifest.json). The screen produced **23 black candidates and no red candidates** under these rules. Manual source review classified all 23:

| Reviewed location | Candidates | Interpretation |
|---|---:|---|
| Text | 6 | Three inline groups and three line-edge fragments |
| Repeated spiral borders | 10 | Decorative dots on pages 3–7, two per page |
| Illustrations | 7 | Components within branch or insect drawings |
| **Total** | **23** | Every candidate retained in the results |

The [complete contact sheet](three_dot_candidate_contact.png) and [review ledger](three_dot_review_results.json) preserve rejected candidates too. Repeated decorative copies are not independent evidence. Threshold reruns are sensitivity checks, not additional observations.

This is an **all-page screen for one small physical class**, not a complete punctuation audit or a fresh rune transcription. It can miss dots joined to runes, marks of other sizes, or marks outside the color rules. Large three-dot section dividers are a separate class.

## The six text locations

Rune gap means the number of runes preceding the mark on that page. Offsets inherit the master sequence and manual line alignment; only the earlier six-page sample has the separate Session 58 reading audit.

| LP2 page | Rune gap | Physical location | Literal master marks | Source classification |
|---|---:|---|---|---|
| 5 | 110 | End of line 5; start of line 6 | `;-` | Three dots, then one dot |
| 11 | 250 | End of line 11; start of line 12 | `;-` | Three dots, then one dot |
| 20 | 134 | End of line 6; start of line 7 | `-;` | One dot, then three dots |
| 38 | 28 | Within line 2 | `-` | Inline three-dot group |
| 46 | 96 | Within line 5 | `-` | Inline three-dot group |
| 56 | 19 | Within line 1 | `;` | Inline three-dot group, solved-page control |

All six text groups have identical component boxes and counts at black thresholds 80, 100 and 120. The paired single dots on pages 5, 11 and 20 are also stable at all three thresholds.

![The six text groups, including the separately shown single-dot fragments at line breaks](three_dot_text_contact.png)

At each of the three line breaks, the two fragments share a rune gap: there is no rune between them. The end-of-line triples point left; the beginning-of-line triple points right. A four-dot diamond split by wrapping is a plausible explanation. The ledger preserves the physical fragments rather than imposing that interpretation. Page 11 is no longer a lone example in our inspected evidence.

The inline groups all point right. Their immediate preceding cipher runes are A on pages 38 and 46, and AE on page 56. Those are ciphertext glyph labels, not inferred plaintext letters. This shared glyph context is a reason to check typography before assigning a special cipher instruction.

## Are the inline marks missing a square hidden in the rune?

A follow-up diagnostic, specified after the scan in a [separate plan](three_dot_followup_plan.json), extended Session 59's expected-position check to all three inline groups. Reflecting the right-hand square through the vertical centerline of the top and bottom squares gives a predicted fourth-square slot under ordinary diamond geometry.

| Page | Predicted slot area | Black pixels | White pixels |
|---|---:|---:|---:|
| 38 | 90 | 29 | 61 |
| 46 | 100 | 29 | 71 |
| 56 | 90 | 11 | 79 |

Each row is unchanged across the three thresholds. A filled fourth square is absent at the predicted position. The different slot areas reflect the measured square widths in the raster images.

This rules out a complete square simply merged with the neighboring black strokes at that expected location. It does **not** rule out clipping, white overpainting during page construction, other rendering behavior, or an intentionally different punctuation symbol. Session 59 additionally compared two identical A masks on page 46; that glyph comparison was not repeated on the other pages.

## The solved-page control

Page 56 gives us a direct check against known plaintext. Its three-dot mark falls after WEB and before THERE. The [retained known-solution record](solved_punctuation_results.json) was reproduced exactly across all 85 runes, using the established prime-minus-one method and its unenciphered F exception at rune offset 56.

The follow-up compared just two fixed schedules at gap 19:

| Schedule immediately after the mark | Next ten rune indices | Result |
|---|---|---|
| Continue the known prime sequence | 19–28 | Reproduces **THERE EXISTS** exactly |
| Restart the sequence at zero | 0–9 | Changes all ten runes; fails the known continuation |

The F exception lies later than this comparison window and cannot explain the difference. There was no key search, phase tuning or ranking of unknown plaintext.

**A small three-dot mark does not universally mean “restart the key.”** The known page is a counterexample to that blanket rule. Its behavior does not establish the cipher or boundary rules of the unsolved sections, and it does not settle whether the mark is semantically a period, semicolon, or a rendering variant.

## Consequence for the hunt

The immediate gain is a better source map. Page 38 joins page 46 as an inline three-dot group that the master reduces to an ordinary separator. Three line-break examples should be tracked separately from those inline groups. The immutable master is preserved; the new ledger supplies the physical classifications and source coordinates.

Before using these marks to expand key searches, the next bounded comparison should inspect **four-dot marks and neighboring A/AE glyphs on known solved pages**. That can test whether spacing or glyph drawing explains the missing left square. A proposed reset rule should also reproduce known plaintext wherever it claims to apply.

We have narrowed an unsupported assumption, not found a cipher key.

## Evidence and reproduction

- [Frozen screening plan](three_dot_scan_plan.json)
- [Full 58-page component results](three_dot_scan_results.json)
- [All 23 candidate crops in one sheet](three_dot_candidate_contact.png)
- [Post-screen follow-up plan](three_dot_followup_plan.json)
- [Candidate labels, exact coordinates, source hashes and known control](three_dot_review_results.json)
- [Screening script](three_dot_scan.py)
- [Review and control script](three_dot_review.py)
- [Original page 38](55.jpg), [page 46](63.jpg), and [page 56](73.jpg)

Run `three_dot_scan.py`, then `three_dot_review.py`, beside the retained source files and `lp_core.py`. The scripts use Python, NumPy, SciPy and Pillow. The review script encodes explicit manual labels and alignments; it is not automated semantic recognition.

Screening-plan SHA-256: `e3f6b7a759e80df3018ba3296ea21d1ba5bd099b9fda567b8e1394845855a5b7`.