The second month — where Finch is now

Two months ago I set out to build a system that reasons on its own. As I write this, it never has — not once, not cold, not without a hand to guide it back when it slips. Every promotion it has earned came through supported reasoning, not independent solving.

That's the most honest sentence I can open with, and it isn't the confession it sounds like. The surprise of these two months wasn't how far the system climbed. It was learning what learning actually costs once you refuse to let a system fake it — and why the slow, expensive version is the only one I'd trust.

This is the first proper retrospective since the opening devlog: the numbers, the architecture, the three things that genuinely surprised me, the pivot that reorganized everything, and what's still broken.

The numbers

• 5 topics under active study: python, marketing, analysis, writing, economics
• 107 sub-areas — discrete competencies inside those topics (e.g. python/type_narrowing, marketing/positioning, analysis/cost_benefit_analysis)
• 138,000+ substrate triples — small structured facts the system has extracted from sources and lessons. About 41 MB of structured knowledge.
• Tier distribution: 6 expert, 43 proficient, 35 competent, 20 active (working toward competent), 2 delegated, 1 stuck
• Zero mastered sub-areas yet — and only 6 at expert
• One topic (writing) has graduated every sub-area to expert. The other four are in progress.

That last bullet is the one I'd point at. One of five topics fully graduated to the second-highest tier in two months — that's the pace this architecture produces, and it's the pace it's supposed to produce. Why it's that slow, and why I think slow is the right answer, is most of what follows.

The architecture, in one paragraph

The system reads sources, extracts small structured claims, and builds a knowledge graph from them. To learn a sub-area, it has to do more than ingest — it has to write deliverables (essays, code, decision frameworks) that get graded by an adversarial reviewer with a high bar. Pass a series of progressively harder reviews and the sub-area gets promoted: beginner → competent → proficient → expert → mastered. Each tier requires a clean window of several consecutive passes — a single lucky session doesn't graduate anything. The reviewer is empowered to say "you don't actually understand this" and refuse to promote, or demote outright, and that lever has been pulled more than once.

The point of the architecture isn't quick wins. It's making it expensive to fake understanding — so that when the chart says a topic is expert or mastered, the label means something real. There are no inflated claims here.

Three things that surprised me

1. The honesty discipline is the hardest thing to teach.

The single most common failure mode isn't "doesn't know the answer." It's "fills in plausible-sounding details the knowledge graph never contained." Asked about a specific dictionary key, it invents one. Asked about an error type, it invents one. The shape of the answer is right; the specifics are sometimes made up. The architecture's whole job is to catch that and refuse to reward it.

Building a reviewer strict enough to catch this turned out to be unexpectedly load-bearing. Without it, the system grades its own output charitably and graduates sub-areas it hasn't earned.

2. Substrate density determines what's learnable — not study hours.

Some sub-areas have thick substrate: hundreds of triples, multiple converging sources. The system can produce real reasoning on those. Other sub-areas have thin substrate — a few dozen triples, one or two sources — and no amount of study-loop repetition improves depth, because there's nothing underneath the prose to ground in.

I spent a few weeks confused about why certain sub-areas weren't progressing. The answer turned out to be that they weren't going to — not until the underlying graph got thicker. So I built tooling to flag thin-substrate sub-areas and queue them for targeted ingestion before further study attempts, instead of grinding against material that couldn't carry the weight.

3. The reviewer doesn't grade vibes — it grades reasoning trails.

The promotion gates don't ask "is this a good essay?" They ask "did this answer reach its conclusion through verifiable substrate and stay grounded to the question, or did it confabulate?" The system has to leave a trail — for every claim, which fact in the graph supports it. When the trail is broken, the reviewer demotes regardless of how confident the prose sounds, or even how correct the final answer happens to be.

This is what makes the project different from a chat interface. The thing being optimized isn't fluency — it's the relationship between the output and the underlying knowledge. A correct answer isn't good enough on its own if there's no evidence it came from something the system actually knew. It's allowed to infer, but it has to test that inference against what's in the graph.

The big pivot

Over the past two weeks I shipped a structured reasoning layer — a deterministic traverser of the knowledge graph that assembles a constrained reasoning chain for a given question. This layer doesn't generate text. Its only job is to gather the structured evidence a question needs to be answered honestly. The generator that sits on top of it has one job: say what the reasoning layer found, and nothing it didn't.

That separation turned out to be the right call. The previous setup had the generator choosing its own evidence, deciding what to use, and writing the text — which gave it far too many degrees of freedom to drift. With the reasoning layer in front, the generator is boxed in: here's exactly what the substrate supports, write only that. On the questions where this is fully wired, the invention failure mode dropped meaningfully.

It's not solved. The generator still occasionally invents specifics — variable names, error semantics, syntax details — that the reasoning layer never handed it. I'm working on a version that targets exactly that discipline, trained on paired examples showing both what to write and what not to write. Whether it lands as a measurable improvement is a question I'll have data on later this week.

What's still broken

• Zero cold passes. The system never solves a sub-area's verification exercise on the first attempt without assistance. Every promotion so far has come through guided correction loops. The original ambition was independent reasoning; the honest reality today is supported reasoning. However, there are more layers planned to close that gap back toward the original intent.
• One topic at expert tier in two months. That's roughly 2× slower than my initial estimate. The substrate-density discovery explains part of it. The larger part is long-running bugs — nearly every time the system gets stuck, I can eventually trace it to one thing that's off in the code. That's a better problem to have than "this can't work," because it's fixable.
• Some sub-areas are stuck. A handful keep failing the same promotion gate session after session. I have tooling to detect this and route them to remediation, but remediation only works sometimes. New remediation steps are coming online to remedy the remediation — which is about as recursive as it sounds.
• Marketing and economics are early. Marketing has 24 sub-areas with no experts yet; economics has 18, all still in active study. These two topics will decide whether the architecture generalizes or whether it's secretly tuned to python, writing, and analysis. I think it's generalizing — there are hints in the daily snapshots pointing that way — but I won't claim it until those two topics show it.

What's next

Three things on deck for the rest of June:

1. The first mastered sub-area. The mastery tier requires a passing capstone — a topic-level integration challenge, not a sub-area drill. One writing sub-area is close. Whether it gets there honestly is the real test of whether the reviewer holds its line under the capstone shape.

2. The first proficient promotion in marketing. If marketing graduates a sub-area to proficient without me softening any gates, that's evidence the architecture works on a topic with thinner, less-formal substrate than python. If it doesn't, the answer is almost certainly that it needs more substrate first.

3. The new generator. Either the new training run produces a measurable lift on grounded prose or it doesn't. The data will tell me within days.

If you've been following along — thank you. From the outside the pace probably looks slow. From the inside it looks like two months of pulling threads, finding the load-bearing ones, and rebuilding around them as fast as I can. It's often eight to ten hours a day, six days a week. The architecture is mostly stable now, and I can see the light at the end of the tunnel. The next two months are about whether the gates hold while the learner pushes through them — and what it looks like when the first mastered topic becomes a working apprentice in the certification pipeline.

Compiled June 19, 2026 — from system logs, memory and the larger plan notes.