A Summer of Sharpening

On August 29 the entire platform, 25 repositories, produced ten commits. In the June numbers post a day like that would have read as an outage: that workflow was merging 29 pull requests a day and I published the throughput as the story. But August 29 was one of the most productive days of the year. It produced two orchestrated research batteries, nine briefs and reports with 163 evidence captures behind them, and a policy research report with a claim ledger and a build loop that regenerated the document seven times in twenty minutes until its own verification passed. The work did not slow down this summer. It changed shape, away from output and into sharpening, and this post is about where the effort went.

The numbers are still here, because this is a numbers series and the series does not skip a down month. Since June 10, measured through the end of August: 4,141 commits and 2,244 merged pull requests across the fleet, with merges holding at the June baseline through July, easing through most of August, and then closing the month with its largest single merge day of the whole summer; 488 new specification documents, peaking in July; and, rising through all of it, more than a hundred authored research documents that never touch git at all. Read as one metric, the summer decelerated. Read as a portfolio, the effort moved down the stack, out of typing and into four systems that make the typing count for more.

What the merges bought first#

A fair reading of 2,244 merges is churn, so before the quiet systems, a sample of what shipped on the visible surface. This site's navigation was rebuilt from scratch around a content graph: every project, post, and tool is an entry in a public manifest, and the homepage now renders six interchangeable views over that one graph, a curated overview, a filterable index, a systems map, a scatter plot, an altitude ladder, and a timeline, each behind a hard performance budget with its own code split. The finance section was reorganized around goals instead of tools: a start page that routes by what you are trying to learn, the sidebar regrouped into four goal groups, and an intro header on every route saying plainly what each tool does and does not do. A new page inventories every equation the platform uses, rendered from the same registry the code imports, so the math on the site and the math in the engines cannot drift apart. The blog gained structured answers on sixteen posts, an instant-indexing lane, and a receipt-hashing gate for a new series that publishes its verification evidence beside every claim. Even the 404 page got the treatment: a sweep read the live analytics, found where real visitors hit dead ends, and turned the top offenders into redirects. That is the typing the ledger does count. The rest of the summer went underneath it.

Memory that outlives the session#

The first investment extends the institutional memory system I wrote about in July, and it earned its keep by surviving its worst failure. Every working session is distilled overnight into typed records: a decision with its date, an open loop with its owner, a gotcha with the exact command that triggers it. The store holds tens of thousands of these records, redaction runs at ingest so the corpus is safe to back up, and query tools sit in front of it so any session can ask what the fleet already knows about a repo, an error message, or a half-remembered choice. This summer it grew self-healing lanes: a pass that hunts contradictions between stored facts, a staleness review that flags claims about code that has since moved, and a closure pass that retires open loops whose work quietly shipped. Each lane had to clear an evaluation gate before it was allowed to touch the store; the first gate scored nineteen for nineteen against a hand-graded counterfactual baseline before the pipeline ran live once.

The impact is quiet and constant. Sessions start already knowing what June decided. The standing rule is now that no session may declare "there is no record of that" without asking the memory system first, and the recall log that enforces it shows questions settled from the store that would otherwise have been re-litigated from scratch. For a team of one, that is the difference between a career of experience and a goldfish with good tooling.

A screen that refuses to flatter me#

The second investment is the statistical screen that sits between market data and anything I might act on. Every hypothesis gets a pre-registered cell in an append-only ledger before it runs: this signal, this slice of the universe, this window. Results land once and are never edited, and the false-discovery correction is applied across the entire family of tests rather than per test, so running more experiments raises the bar for each one instead of buying more lottery tickets. When a contamination review found the early candidate pool had leaked its benchmark, the whole pool was killed rather than argued for. The screen's confirmed-discovery count, after a summer of hardening, is zero. That number is the system working. I wrote in June that the most dangerous result I produce is the one I was hoping for; this is that sentence built into infrastructure, hobbyist research run for the engineering, and the engineering's first product is an honest null.

This summer the screen's ledger was compacted into immutable segments, its backup gap closed, and its research strategist re-enabled against a 48,000-cell test backlog it drains on a schedule, at a budgeted pace, without me touching it. Its output is memos, not actions, and nothing it finds gets believed by default. That is the point.

A floor under the data#

Third, the data itself. Any long backtest quietly assumes you can see the companies that died, and most free data cannot. Worse, the shortcuts fail in ways that look like success. One free daily-price archive, downloaded and checked this month, turned out to be a survivor-only backfill: the current index membership projected into the past, every dead company absent. And dead tickers do not stay dead; symbols get reused, so a naive lookup for a delisted name can return a different company wearing the same letters. So the summer's data-mining push went at the survivorship assumption directly, from regulatory filings as primary sources. What exists now, as running code with its own diagnostics: a delisting-event table built from Form 25 filings back to 2006, with each event classified by whether the company actually left the universe or just changed venues; a point-in-time fundamentals loader over the SEC's Financial Statement Data Sets, which reach back to 2009; a daily index-membership table so the universe is defined by what was actually in it, not what survived; a fund-holdings harvest from archived N-Q filings as an independent cross-check on that membership; a quarterly high-low price extractor for the dead names themselves, pulled from the Item 5 tables of their old 10-K filings; and a coverage census that pushed the hardest filing family from 25 percent extraction to 75. Behind the synthesis sit 221 captured filings as evidence. The result is a measured boundary instead of a vibe: I know exactly which claims the free primary record can support, and the one gap that remains, daily prices for the dead names, is named in the synthesis rather than papered over. The posture is measurement first; nothing gets certified for use until the floor holds.

A product built on paper first#

The fourth investment produced no code at all. A new product spent the summer as a stack of numbered rulings: competitive landscape, packaging and signing, pricing, trust and autonomy boundaries, release mechanics, each question argued to a decision before implementation gets to exist. Every ruling reads the same way: the question, a verdict, the reasoning, and one concrete recommendation, so a later disagreement argues with a written position instead of a vague memory. This is the spec-first method from the April playbook applied at product scale, with the judgment front-loaded where changing your mind is cheap. When the building starts, it will start the way the best weeks of June did: from a brief that already removed the need to guess.

Refining the machine that does the work#

Underneath all four runs the same discipline, applied to the workflow itself. The operational lessons file is now 26 numbered entries, and the standing rule for each is that prose is advice; only a check is a guarantee. Lessons get promoted into enforced gates, and the summer's additions show the shape: the scheduled job that reported success for weeks while failing every run became a health check that judges config rot, exit result, and staleness as three independent signals; the deploy that once clobbered a backend-owned file became a generated exclude list with a post-deploy probe that fails loudly; the watchdogs themselves get a deliberately planted failure each week to prove they still bark. A weekly pass sweeps the week's corrections back into the briefs, specs, and configs that caused them, so the same mistake has somewhere harder to live. The payoff showed up at the end of August, twice. First a three-day integration wave merged 59 pull requests across 12 repositories. Then the month's final evening merged 157 more in one sitting, the largest merge day of the summer, with the gates doing the reviewing that used to be my evening. A backlog that size clearing in one pass is not a burst of heroics; it is what the review machinery makes routine. Refinement is not a pause in the work. It is the work that makes the next wave cheap.

Where that leaves it#

The series now has three points, and they measure different questions. April asked whether the workflow could ship at all. June asked how fast. This summer's answer is about what the speed runs on: a memory that compounds, a screen that cannot be flattered, a data floor that holds weight, a product argued out before it is built, and a machine that turns its own mistakes into gates. The fall gets to spend all of it. Productivity used to look like shipping. This summer it looked like sharpening, and the difference only shows up in next month's numbers.

---

Previous in the series:

• Ten days of June: the SDD velocity numbers, seven weeks in
• One week of SDD in production: the numbers
• SDD isn't about managing AI agents, it's about managing context