DEV Community: Ken W Alger

Views Measure Views

Ken W Alger — Thu, 01 Oct 2026 19:32:00 +0000

Nine years in, I finally worked out what else to count.

A writer I follow, Sylwia Laskowska, recently published a post about accidentally becoming a blogger. She has been writing on DEV for about a year, and the numbers attached to that year are impressive: hundreds of thousands of views and tens of thousands of followers.

I have been on DEV for more than nine years. This morning I am at 48,408 total views.

Before I go any further, I want to be clear about something, because the essay that usually follows a comparison like that is insufferable. Building a large readership for accessible, useful developer writing is genuinely difficult, and doing it in a year is more difficult still. I would like more people to read my work. I can learn a great deal from writers who are better than I am at audience building, topic selection, accessibility, and community participation.

So this is not a piece about why small numbers are secretly good. It is a piece about what I spent nine years failing to separate.

The number that stopped me using one of my metrics

I recently pulled nine years of my own data out of the DEV API, mostly to make a chart of follower growth with my publication dates marked on it, so I could see which posts moved the line.

The chart was useless, and the reason is instructive.

In 2026 I gained roughly eighteen thousand followers. My 2026 posts have about fourteen thousand views between them. You cannot acquire eighteen thousand readers from fourteen thousand page loads. The daily follow rate sits around 130 and does not respond to whether I publish anything, and about 37% of the usernames carry auto-generated hex or numeric tails. It is reciprocal-follow farming, it is endemic, and it has nothing to do with me or my writing.

Here is the cleanest version of it. Since the middle of September, my follower count has gone from 18,148 to 21,048. Over the same fifteen days, my total view count went from 46,774 to 48,408.

Two thousand nine hundred new followers. One thousand six hundred and thirty-four new views.

I gained nearly twice as many followers as readers, and a follower is supposed to be a reader who liked something enough to want more. That number had been sitting on my profile for months looking like evidence of something.

A page view is at least an honest measurement. Somebody loaded the page. That is real information, and I think "vanity metric" is an unfair label if it is taken to mean meaningless.

The trouble starts when we quietly change the claim from "this post received more views" to "this post was more successful."

Successful at what?

A page view is real. It just is not the whole story.

In corporate content the answer to that question is usually explicit. A post might exist to attract someone searching for a problem, introduce a product, move that reader toward a trial, and eventually help create a customer. Ten thousand views with no downstream behaviour may be worth less to that company than five hundred views that put twenty qualified developers into the funnel.

Personal writing has a funnel too, just a much vaguer one. Someone reads one article, encounters another a month later, starts recognising the name, follows, leaves a substantive comment, references the work elsewhere. The page view was real. It was not necessarily the outcome.

It also helps to remember that a broadly useful JavaScript tutorial and an article about authority boundaries in AI-generated software are not competing for the same reader. One is relevant to a large share of a developer community. The other starts with a much smaller pool of people who already care about capability security and the distinction between correctness and authority.

That is not so different from comparing the audience for a popular fantasy novel with the audience for a presidential memoir. Both books can be excellent. Both can do exactly what their authors intended. Their potential readerships are still radically different.

Audience size is partly a property of the artifact and partly a property of the market around it. That sounds obvious about books. Writers forget it remarkably fast while staring at a dashboard.

An article can also have a desired consequence without a button under it. Sometimes I want someone to challenge the argument. Sometimes I want a developer to recognise a problem in their own system. Sometimes the entire intended outcome is that a reader leaves with a question they were not asking ten minutes earlier. That still gives me something to evaluate against. It just refuses to appear as conversion=true in an analytics dashboard.

Quality, audience fit, and distribution are different problems

I have come to think of online writing as at least three separate problems.

Writing quality is the craft problem. Is the argument coherent? Is the explanation useful? Did I do the research? Is there something here worth another person's time?

Audience fit is the relevance problem. How many people where I publish are likely to care about this subject? How much prerequisite knowledge does it demand? Can someone scrolling a feed see immediately why the question matters to them?

Distribution is the discovery problem. How does the article reach those people? Search, followers, newsletters, speaking, community participation, platform curation, links from other writers, or some combination.

Those interact, but they are not interchangeable. An article has to clear all three, and failing any one of them produces the same disappointing number for completely different reasons.

flowchart LR
    W["Article"] --> Q{"Quality"}
    Q -->|"weak"| X1["Nobody finishes it"]
    Q -->|"strong"| F{"Audience fit"}
    F -->|"wrong room"| X2["Few people care"]
    F -->|"right room"| D{"Distribution"}
    D -->|"not found"| X3["Nobody sees it"]
    D -->|"found"| R["Readers"]

    classDef gate fill:#FFFFFF,stroke:#166534,color:#14532D,stroke-width:2px;
    classDef miss fill:#FEF2F2,stroke:#991B1B,color:#7F1D1D,stroke-width:2px;
    classDef good fill:#E8F3EE,stroke:#166534,color:#14532D,stroke-width:2px;

    class Q,F,D gate;
    class X1,X2,X3 miss;
    class W,R good;

That is the diagnostic value of separating them. Three posts can land at 80 views apiece and need three entirely different responses. A good article can have poor audience fit. An accessible article can have excellent fit and no distribution. A technically modest piece can answer a question a hundred thousand people are asking today. A strong argument can address a question five hundred people know they have.

For most of my writing life I concentrated almost entirely on the first variable and assumed distribution would sort itself out. Sometimes it did. Frequently it did not. My own numbers say that plainly: about 4% of my traffic comes from search, which for someone whose best-performing historical work is evergreen reference material is a distribution problem rather than a quality one.

I did not start with a content strategy

Nine years ago my public technical writing grew out of databases, because databases were the work I was doing and the community I was in. I did not sit down with a personal-brand document. I wrote about what I knew, what I was learning, and what developers were asking about.

Those articles accumulated into something larger. People began associating my name with certain subjects, questions led to more articles, and some of that work became durable enough to keep attracting readers years later. My database writing eventually included MongoDB's Building with Patterns, one of the most heavily visited bodies of content I worked on there.

That history matters when I wander. If I publish one Rust article today, it does not arrive with nine years of association between my name and Rust behind it. That does not mean developers are uninterested in Rust, or that my readers dislike it. It may simply mean I have not given a Rust audience any reason to know who I am.

Those explanations imply completely different responses. If I wanted Rust to become a real part of my writing, one underperforming article would tell me almost nothing. I would need several useful pieces, participation in that community, and time. If I do not want that, the article stays an interesting experiment.

"This article performed poorly" is an observation. "There is no audience for me here" is an interpretation.

Personal writing gets to discover its strategy

I have spent enough of my career around corporate developer content to know that content strategy matters. A company generally knows why it is publishing: which developers it wants to reach, which capabilities it needs explained, which search terms it wants to own. The strategy should exist before anyone fills the editorial calendar.

Personal writing is stranger. You can chase a question because it bothered you on Tuesday. You can abandon a series when you have nothing else useful to say. You can spend weeks on a technical experiment and then publish something ridiculous because you started wondering whether all the photographs on your phone technically make it heavier.

You can also discover the strategy after you have written enough to see the pattern. That has increasingly been my experience. Articles I thought were about AI verification, provenance, missing information, audit evidence, memory, and authority turned out to be different views of the same few questions. I did not design that body of work and then manufacture articles to fill it. The writing is how I found it.

The conversation that prompted this piece made me realise that is less different from corporate strategy than I assumed. Sylwia described writing mostly by intuition while still making choices about what she wants to be known for, which audiences interest her, which adjacent topics fit, and which opportunities she ignores.

That is a content strategy. It just has a governance structure of one.

A company may need content, DevRel, product marketing, SEO, and leadership involved in deciding whether a newly discovered audience matters. A personal writer can notice something in the comments on Tuesday and run the experiment on Thursday. The strategic question is nearly identical. The path from observation to decision is not.

Signals are not instructions

This matters because audiences talk back. A recurring question in the comments may reveal an adjacent audience you did not know you had. Search traffic may show people finding an article for a reason you never anticipated. A series may attract platform engineers when you thought you were writing for application developers.

That is useful information. It is not an order.

A writer can discover that beginner tutorials have an enormous reachable audience and still decide not to build a body of work around them. A company can discover that a group of users loves a product for an unexpected use case and still decide that market does not fit the strategy.

Discovering an audience is not the same as deciding to serve it.

This is where "write more of whatever did best last week" collapses. It is the same loop with one step deleted.

flowchart LR
    A["Write"] --> B["Publish"]
    B --> C["Signals<br/>views · comments<br/>search terms · who shows up"]
    C --> D{"Is this where<br/>I want to go?"}
    D -->|"yes"| E["Build an audience here"]
    D -->|"no"| F["Note it. Leave it alone."]
    E --> G["Strategy"]
    F --> G
    G --> A

    classDef step fill:#E8F3EE,stroke:#166534,color:#14532D,stroke-width:2px;
    classDef signal fill:#FFFFFF,stroke:#5CA08A,color:#14532D,stroke-width:2px;
    classDef gate fill:#FEF2F2,stroke:#991B1B,color:#7F1D1D,stroke-width:2px;

    class A,B,E,F,G step;
    class C signal;
    class D gate;

The diamond is the part that gets skipped. Without it the loop still runs, it just runs on autopilot, and the writer ends up somewhere chosen by whatever the feed rewarded in a given week.

Metrics tell you what happened. Readers reveal opportunities you did not know to look for. Neither one gets to decide what you want the work to become. The feedback loop needs interpretation.

I eventually wrote down some rules

Once I could see a body of work forming, it became tempting to turn every passing thought into another strategic article. So I wrote myself a gate.

For the deliberate part of my technical writing, I now ask whether there is a disputable claim, whether investigating it will put pressure on an actual artifact, whether I have standing through a project or experiment, whether it advances rather than repeats the larger body of work, and whether a reader should do or question something differently afterward. I also want to know what would falsify the claim before I start assembling evidence for it.

The artifact-pressure test is deliberately hard. If investigating an idea will not change code, a specification, an ADR, a schema, or a demo, it probably does not belong in that stream. The investigation also has to be capable of failing. Building fixtures that encode what I already believe proves very little.

That produces a shape I have become fond of:

Here is what I thought.
Here is what would have convinced me I was wrong.
Here is what I built.
Here is what happened.
Here is what changed.

Those are not my rules for everything. I deliberately keep another lane with almost no gate at all: career observations, language experiments, satire, community responses, project archaeology, and pure curiosity only need to be worth writing.

A publishing strategy should help me recognise strong work. It should not make me ask permission before being curious.

Some of it is luck

There is one variable I cannot put into a strategy with any confidence.

I can study years of data and conclude that Tuesday at 9:00 a.m. Pacific is the right time to publish. That says nothing about whether it is right for this article. A major news event may take the morning. Three other posts aimed at the same readers may appear within the hour. A moderator may promote something. A Gem may land. Another writer with a large audience may link to you. None of that says anything new about the quality of the work, and each can transform its distribution.

Strategy does not eliminate luck. It changes the conditions under which luck operates. You can improve the writing, understand the audience, participate in the community, publish consistently enough that people know you exist, and make the work easy to find.

You can engineer more opportunities for an outcome without engineering the outcome itself.

And when luck does hand you an unexpected success, strategy comes back. A surprising audience appearing is another signal, not a mandate. You still have to decide whether it points somewhere you want to go.

What I actually track now

I still look at views. Pretending otherwise would be silly. If one article gets 5,000 and another gets 40, I want to know why. I just no longer think the first was 125 times more successful.

The outcomes I care most about do not fit in a platform dashboard. A reader challenges a claim and I change the model. A comment exposes a missing invariant. An experiment breaks the answer I expected to publish. An article changes code, a specification, or an architecture decision.

That has become much less theoretical lately.

I published an article that began with a refractometer and a batch of homemade wine, arguing about the difference between a measurement and the state we infer from it. The comments pushed it considerably further: version the correction rule, spend more measurement budget on consequential baselines, decide how conflicting instruments get adjudicated before seeing the readings, distinguish evidence that survives a restart from evidence that dies with the process.

An article about authority boundaries in AI-generated code did the same thing. Readers pushed on capability lifetime, consumable authority, semantic authority diffs, denied-call telemetry, and who is permitted to modify the authority boundary itself.

Those comments did not just increase engagement. They changed the model. Those are propagation effects rather than distribution metrics, and I have started tracking them separately: research-induced change, engagement from people with standing outside my field, independent use of a concept, substantive challenges and extensions, and whether writing has started consuming so much time that the projects supplying it have stopped moving.

My numbers support the split more cleanly than I expected. Across nine years I have 1,372 reactions and 683 comments. Roughly one comment for every two reactions is a strange ratio, and it is concentrated almost entirely in recent work. My 2017 tutorials pulled more than twice the traffic of everything I wrote in 2026 and produced 26 comments in three years. The 2026 essays, with a third of the traffic, have produced hundreds. One of them has a comment thread 35 replies deep.

One body of work got found and skimmed. The other gets read and argued with. For years I evaluated both with the same number.

A related consequence: a technically unsuccessful investigation can make a successful article. If I start with a hypothesis, state what would falsify it, build something capable of producing an answer I do not control, and find out my model was wrong, that is useful. Possibly more useful. It tells the reader something, it changes the artifact, and it often exposes a better question than the one I started with.

I have a line in my current content plan that says missing a publishing day beats manufacturing a weak post. Nine years ago I am not sure I would have been comfortable with that.

Nine years later

I am still working this out. I still publish things and wonder whether anyone will care. I still occasionally write something I expect to perform well and watch it vanish. I still publish something on a whim and find it landed exactly where it needed to.

The difference is that I now have more ways to recognise success when it shows up wearing something other than a large number.

A successful post might reach 30,000 people. It might produce a conversation that changes the next article. It might expose a flaw in an architecture. It might give someone language for a problem they were already having. It might lead to code. It might turn out to be part of a body of work whose shape I could not see when I wrote the first piece.

And sometimes it might simply be an article I wanted to write, written well enough that I am still happy to have my name on it years later.

Views measure views. They are a real measurement of a real thing, and they do not independently measure rigour, usefulness, influence, audience fit, changed behaviour, changed artifacts, or whether the writing moved me toward a better question. Sometimes those correlate. Sometimes they do not. Mine told me almost nothing for nine years, and the twenty-one thousand followers told me less.

The useful question is not "Was this post successful?"

It is "What did I want this post to do, and what happened because I published it?"

Those are much harder numbers to put on a dashboard. I think they are also the ones worth learning to notice.

Thanks to Sylwia Laskowska for the conversation that prompted this, and for the encouragement to write some of it down.

The Most Useful Line on Your AI Cost Report Is the One You Can't Explain

Ken W Alger — Thu, 01 Oct 2026 13:16:00 +0000

Attribution, allocation, and why "unknown" belongs in the schema.

This piece grew out of a comment thread on Sarvar Nadaf's Per-Agent Cost Tracking for Multi-Agent AI on AWS. The schema below was worked out in that conversation, in public, and it is better for it. Where a specific idea came from the exchange, I have tried to say so.

Most AI cost dashboards answer one question well: how much did this run cost. Total tokens, model spend, per-agent spend, latency, tool usage. Those are real and useful numbers, and for a while they are enough.

They stop being enough the moment your system becomes a composition. Once a request flows through a retriever, a knowledge graph, three specialist agents, and a supervisor that synthesizes their output, the total tells you almost nothing about what to change. A run can be correct, return HTTP 200, look healthy in every latency-and-errors panel, and still cost forty percent more than an identical run that produced the same answer. The overspend is real. It is just not anywhere you are looking.

To find it, you have to stop asking where the money was spent and start asking what caused it to be spent. Those are different questions, and the gap between them is the whole subject of this piece.

Where a Cost Is Incurred Is Not What Caused It

Consider a retrieval operation that costs $0.004: searching, ranking, fetching. That is the direct cost, and it is easy to attribute. It happened on that span, you can measure it, done.

Now suppose that retrieval returned 20,000 tokens, and all of them were hydrated into a supervisor's context on the next step. The supervisor then costs $0.009. How much did the retrieval really cost?

The direct answer is still $0.004. But that is no longer the interesting answer, because the retrieval also caused cost somewhere else. It inflated the supervisor's context, and some portion of that $0.009 exists only because the retrieval handed it too much material. The cost was incurred at the supervisor. It was caused, in part, at the retriever.

This gives you two distinct dimensions, and a useful cost model has to carry both:

Where the cost was incurred. This is just the span. Directly observed, low ambiguity.
What caused or contributed to it. This is the interesting axis, and it is the one no aggregate dashboard shows.

A record that captures both might look like this:

span_id: retrieval-104
direct_cost: $0.0040
primary: retrieval
returned_tokens: 20000

downstream:
  span_id: supervisor-105
  attributed_cost: $0.0021
  caused_by: retrieval-104
  attribution_method: proportional

The dollars are single-counted. We do not charge the $0.0021 twice. The supervisor genuinely incurred it; the retrieval genuinely contributed to causing it; and the record says both without inventing money. What we have added is lineage: a link from a downstream cost back to the decision that helped produce it.

The Hard Part Is Honesty About How You Know

Here is the question that breaks naive versions of this: how do we know retrieval-104 actually caused $0.0021 of the supervisor's cost, and not some other amount?

Sometimes you can measure it. If you have a controlled comparison where the only meaningful change is that retrieval result, the delta is real evidence. Supervisor costs $0.006 without the retrieved material and $0.009 with it, so roughly $0.003 of downstream cost is attributable to that retrieval. That is measured causation, and it is the strongest claim you can make.

Most production traces do not give you that. In a real run the supervisor is carrying system instructions, conversation state, the outputs of other agents, tool results, and the retrieved material, all at once. There is no clean counterfactual. So you fall back on allocation: split the supervisor's context cost proportionally by the tokens each source contributed. That is a reasonable method. It is not measurement, and the receipt must not pretend it is.

This is why the single most important field in the whole schema is not a dollar amount. It is this:

attribution_method:
  - measured_delta
  - proportional
  - estimated
  - unknown

That field is what keeps the entire model honest. It stops a proportional guess from masquerading as measured causation. With it, a line can say "retrieval span 104 contributed an estimated $0.0021 of downstream context cost, allocated proportionally by hydrated token share," and every word in that sentence is defensible, because the method is stated. Without it, the same $0.0021 acquires a precision the evidence never earned.

Resist collapsing this into a confidence score. A number like confidence: 0.82 feels rigorous and gives you nothing, because now you have a second number whose provenance you have to go investigate. measured_delta, proportional, estimated, and unknown each tell you why you are entitled to believe the figure. The method is the provenance. A score would hide it.

Show the Method Where the Decision Is Made

A natural instinct is to keep the attribution method as drill-down metadata, out of the main view, so the report stays clean. That instinct is wrong, and it is wrong for the same reason aggregate dashboards are wrong: it makes two different claims look equivalent.

The method belongs inline, next to any attributed cost, with one sensible exception. A directly observed cost carries no ambiguity and needs no method tag:

retrieval-104   RETRIEVAL   $0.0040

There is nothing to disclose there; it was measured on the span. But the moment a number is attributed rather than observed, the method has to ride along:

retrieval-104 -> downstream CONTEXT   $0.0021   proportional

Drop the word proportional and that $0.0021 visually becomes as solid as the $0.0040 above it, which is a lie of formatting. A report that hides the distinction between what it measured and what it allocated has committed the same sin as the dashboard that only shows a total. If two numbers make materially different claims, the interface must not make them look the same.

So the main report shows amount, category, direct versus downstream, and method. The drill-down holds the evidence behind the method: hydrated token counts, comparison runs, parent-child span references, the assumptions the allocation rests on. The decision surface stays readable; the receipt is one click away, not dumped into the table.

"Unknown" Is Not a Gap in the Accounting

Every honest version of this schema has to allow unknown as a real value, not a placeholder you feel bad about. And once you sit with it, the unknown rows turn out to be the most useful rows in the report.

A high downstream cost with unknown attribution is not incomplete bookkeeping. It is the system telling you exactly where your observability boundary stops letting you explain its own behavior. It is pointing at the place where you cannot yet answer "what caused this," which is the place most worth instrumenting next. A tidy report with no unknown rows has usually not achieved understanding. It has hidden its ignorance behind confident allocation.

There is also a real reason unknown is sometimes the only honest answer: context is not additive. An extra 5,000 tokens of context does not simply add a proportional slice of cost. It can change caching behavior, alter the reasoning path the model takes, or change how much output the model generates downstream. When that happens, token share and cost share stop mapping to each other cleanly, and any proportional number you report is a polite fiction. In those cases the schema should say unknown and mean it, rather than allocate a figure it cannot defend.

Read that way, the report stops being a statement of where you paid and becomes a map of two things at once: what you can explain about your spending, and where your ability to explain it runs out. The second map is the one that tells you what to build.

What This Actually Costs to Build

The reason this is not a research project is that most of the structure already exists. If your traces are parent-child spans, the causal lineage is physically present already; a downstream cost sits under the decision that produced it. You are not inventing a new tracing mechanism. You are making the attribution semantics explicit on top of a trace you already record.

Concretely, that is a small number of additions. Stamp a primary category on each span. Add a contributes_to link and a cause on spans that produce downstream effects. Add the attribution_method on any attributed cost. Then roll the report up along two axes, category and direct-versus-downstream, and let unknown be a first-class row rather than a swept-under one. The intelligence is not in the plumbing. It is in having the honest method field and being willing to publish the unknown rows.

One warning from the same conversation that produced all this: how you record and how you attribute are coupled. Change the way spans are emitted and you can silently break the logic that reads them. The defense is the same one that makes the whole model trustworthy, a known-good baseline you compare against, so that when your instrumentation shifts under you, the numbers move and you notice.

The Point

We have spent a lot of effort making AI spend visible. Better token counts, per-agent breakdowns, nested traces. All of it answers "how much." Almost none of it answers "why," and "why" is the only version of the question you can act on.

The move from one to the other is not a bigger dashboard. It is a small, honest schema: separate where a cost was incurred from what caused it, state the method behind every attributed number, and treat the costs you cannot explain as signal rather than embarrassment. Do that, and the report stops telling you what you spent and starts telling you what to fix, including, in the unknown rows, where to look first.

Even the cost report, it turns out, needs provenance. Not just the amount and the category, but how sure you are about who to blame. That last column may be the most useful one on the page.

With thanks to Sarvar Nadaf, whose post and the conversation under it produced this schema, and to the commenters in that thread who pushed on the baseline and the propagation. The receipt is better for the argument.

A wine cellar that remembers what you used to believe

Ken W Alger — Wed, 30 Sep 2026 22:49:21 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

Cellar is a wine collection that remembers what you used to believe.

Most cellar apps answer one question: what do I have right now? Cellar answers a harder one. What did my cellar look like on 1 June 1999? What did I think that bottle's drinking window was in 2018, before a later tasting changed my mind? Which bottles were at peak last year while I wasn't paying attention, and are now past saving?

Those questions rule out the obvious data model. A status field on a bottle tells you what is true today and nothing about 2004. A drinkUntil field on a wine tells you what someone currently believes and destroys what they believed before.

So Cellar stores neither. It stores events and claims:

Acquisitions and consumptions are documents with dates, not fields on a bottle. A bottle is consumed as of date T if a consumption event exists on or before T.
Assessments are dated, attributed claims about when a wine should be drunk. Nothing overwrites a window. The current window is resolved from the claims that existed at T, by explicit rules: my own tasting note outranks the producer's, which outranks a critic's, and within a tier the most recent claim wins.

Everything else follows. Move a date control backward and acquisitions disappear, consumptions reverse, and drinking windows change as the controlling claim changes. Move it forward and unopened bottles age through their windows.

The design rule underneath: do not store what is true now when you may later need to know what was true then.

There are three surfaces, with different jobs:

Sanity Studio authors and governs the ledger. Six document types, a custom review queue, two document actions, and a read-only workflow field.
A Sanity App, built on the App SDK and running inside Sanity, interprets it. Three views, all computed live from the event log by a pure TypeScript package that knows nothing about Sanity.
A public page is that same App without an account. Read-only by construction rather than by convention, since there is no token in the bundle and the dataset's public ACL grants reads only.

What it deliberately does not have is a second CRUD interface. Studio already is one, so adding bottles and recording consumptions happens there. The App interprets; it does not manage.

Who it is for, honestly: me. But the argument generalizes past wine, which is the reason I built it.

Demo

Open it with no account: kenwalger.github.io/Cellar

Inside Sanity (organization members): The Cellar app

The same 542-bottle ledger, read at three moments:

Date	In cellar	Drinking	Past window	Not yet acquired
1 June 1999	4	4	0	536
23 September 2026	248	166	33	0
23 July 2035	248	62	182	0

In 1999 the whole cellar is four bottles of 1993 Château Mouton Rothschild, with two already opened. By 2026 it is 248 bottles. Projected to 2035, those same 248 bottles are still there, and 182 of them have gone past window.

The cellar never loses bottles. It loses opportunities.

Past:

Present:

Future:

Drink Soon lists what closes within twelve months, and every row names the claim that decided it: which tier, whose, and when.

Missed Opportunities asks a different question: which bottles were at peak during a period, were never opened, and are past window now.

And when nothing was lost, it says why rather than showing an empty panel.

Three views in the App, all computed live from the event log:

Cellar health, bottle counts by state at any date
Drink Soon, windows closing within twelve months, each row naming which claim decided it
Missed Opportunities, bottles that were at peak during a period, were never opened, and are past window today

And in Studio, the review queue, where a proposed claim waits for a person.

Code

github.com/kenwalger/Cellar

My Build Process

Tools: Claude Code in a terminal beside WebStorm, with Sanity's MCP server connected so the model could check current documentation rather than recall it. One thing worth stating plainly: the prompts themselves were drafted in a separate planning conversation with Claude in the chat app, where I also made the decisions at each fork before relaying them. Calling this one developer and one agent would be inaccurate.

The project entered implementation with fourteen planning documents: a content model, a temporal resolution specification, a build plan, a seed data plan, and eleven architecture decision records. None of it was code. That turned out to matter, though not in the way I expected.

The pattern that emerged

specification
     ↓
agent conflict pass, no code written
     ↓
human decision
     ↓
implementation
     ↓
independent oracle, measurement, or experiment
     ↓
gate only I can close

Every stage started with a prompt that said, roughly: read the specs, check them against the current platform, report where they disagree, and stop. Every stage found something. The count went up as the project went on, not down. Stage 1 found three spec errors. Stage 4 opened with ten conflicts, two of them spec errors.

Prompts that worked

"Report conflicts and stop before writing code." The single highest-value instruction in the project. In Stage 1 it found that I had specified underscore-prefixed projection fields, which Sanity reserves for system fields, and a validation rule requiring an assessment to have been created in a particular state, which Sanity cannot express because validation sees current state only. Implementing that rule literally would have made the accept transition permanently invalid, breaking the exact workflow the rule existed to protect.

Gates that name what does not count as proof. For the App SDK gate I wrote out the path being tested and then listed the ways it could be faked:

Do not satisfy this gate by calling @cellar/core separately from the App, querying the dataset through another tool, or relying only on the existing test suite. The purpose is to prove the complete path: Content Lake → App SDK → CELLAR_QUERY → toCellarSnapshot → bottleState() → rendered view.

You cannot see the rendered view, so do not report the gate as passed. Give me the command, the URL, and exactly what I should see.

That last paragraph matters more than the first. Claude Code has no browser, and a model asked to confirm something it cannot observe is under pressure to confirm it anyway.

"State the expected result before deploying." For the Functions experiment, the probe had to produce one predetermined log line, written down and approved before anything was deployed. A bundler can resolve an import and still ship a shimmed or stale module; a log line proves nothing on its own.

Oracles, with an explicit instruction not to repair them. Expected outputs were generated before implementation and the prompt said to treat them as an oracle rather than as output to be fixed. When a test disagrees, the cheapest move for a model is to adjust the fixture.

Prompts that didn't, and where I was wrong

I proposed a test that would have written to production. Setting up the Functions probe, I suggested scoping the trigger at the production dataset with a filter on a document type that doesn't exist, to avoid creating a scratch dataset. Claude Code declined, correctly: scoping is safe, invoking is not. A document Function can only be invoked by writing a matching document, so my plan would have put two mutations permanently in production's history to avoid a dataset that deletes whole.

I told it to give up on a test I assumed was impossible. After finding a test that passed while measuring nothing, I said that if the clause couldn't be isolated, it should fall back to a weaker assertion. It ran the experiment instead and found a fixture, on the realization that now in this system is a parameter rather than the clock. "As of June 2024, what had I missed that year?" is an ordinary question for a time machine, and it makes the case constructible.

I approved a feature without asking what it cost. An extra column showing "3 of 5 at peak, 1 opened in time" came back with a measurement I hadn't requested: it costs about four times what the rest of the view does, because it scans every other bottle of every listed wine. Still 5% of a frame, so nothing changed, but the earlier estimate had been for something narrower than what shipped and it said so.

Where the model got stuck

It confidently misread an API. It reported that Sanity previews cannot follow references and deferred a feature to a later stage. Asked to verify against the docs rather than assert, it found the section demonstrating exactly that, said plainly it had been wrong, and fixed it in one line.

It nearly filed a bug that didn't exist. It concluded that installed type definitions contradicted the reference docs about where perspective lives. They don't: the option is inherited through an interface chain that the reference flattens and the .d.ts doesn't. It caught this itself and logged the near-miss instead of the finding. That's the more useful record, because a developer who files bugs that turn out to be their own misreading loses credibility fast.

Right conclusion, wrong reasoning. It argued for inclusive date comparison on the grounds that strict comparison would reject ordinary windows in the seed data. It wouldn't, because same-year windows normalize to 1 January and 31 December, which are strictly ordered. The conclusion was right anyway. A model that is right for the wrong reason is right only until the case changes.

It asserted a gitignore rule instead of checking it. A stage list said the public build's output directory was already ignored. It wasn't: a bare dist pattern matches a directory named dist, and this one is dist-public. Six build files were committed, in the same commit whose accompanying document argued that build output does not belong in a repository. The cause is neat: dist-public was named that way specifically so it could not collide with dist/, and a name chosen to be distinct from dist is by construction one that dist does not match.

It broke an explicit rule twice, and disclosed both times. I told it not to run git commands that change the repository. Twice it ran git checkout -- to undo its own uncommitted edits, and twice it reported this unprompted before I found it. The rule now says explicitly that the file tools are the only way to revert anything, including its own work.

How I course-corrected

Mostly by making verification harder to fake rather than by writing better instructions. The gates got stricter as the project went on: name the path, exclude the proxies, state the expected numbers in advance, and put the confirmation in the hands of the one participant with eyes.

The other correction was measurement. Three of the four real bugs in this project were invisible to every check designed for the feature they lived in.

The App SDK

The gate was one view rendering live production data inside Sanity, with now frozen to a date an independent script had already computed. The numbers had to match exactly: hold 45, drinking 166, past window 33, unassessed 4, consumed 294, 542 total. They did, first try, and I confirmed them in a browser because the model couldn't.

useQuery subscribes, so publishing an assessment in Studio moves the counts in the App with no synchronization layer. Studio edits the graph, the App reads the graph, GROQ traverses it, Functions react to it, and a pure module decides what it all means.

Learning the current App SDK was harder than using it. In one session: Sanity's own bundled agent rule supplied a CLI command with a flag the installed CLI rejects; the quickstart named a template the CLI reference doesn't list; and that template installed the SDK a major version behind the docs I was being pointed at. All three are stale vendor guidance rather than product defects, which is a distinction worth making and also a pattern worth reporting.

The deeper issue was a recurring shape. The documented path is well covered for the common case of rendering and editing documents. Cellar computes an aggregate, and the guidance steered toward useDocuments and useDocumentProjection, which for six numbers would mean roughly 1,500 hook instances and round trips instead of one query. Similar story with useState: the rule correctly warns against holding Content Lake values there, and says nothing about ephemeral view state like a date control. Neither is wrong. But once you step outside the example app, it becomes difficult to tell not recommended from not documented from not supported.

Workflows

An assessment carries a review state: proposed, accepted, or rejected. Only accepted claims resolve windows. An agent proposes; a person decides; rejected claims stay in the dataset, because deleting them would destroy exactly the record this project exists to keep.

Two details I'd defend:

The review state is read-only in the form. A workflow you can bypass with a radio button is decoration. The two document actions are the only path.

An accepted proposal records that a model extracted it. Same tier and same author as a hand-written claim, because accepting it makes it yours, but with sourceMethod: extracted alongside. A system arguing that claims should carry their provenance cannot then be unable to say whether a person wrote this one.

The agent half. A document action on a consumption sends the tasting note, the date, and the wine to Sanity's Prompt API and writes back a proposed assessment. It abstains when the note carries no temporal signal, and abstention writes no document at all rather than a proposal with empty bounds, because a proposal nobody can accept is noise in a review queue.

I checked it against twelve real tasting notes from the dataset, asserting direction rather than exact years, since direction is checkable on a non-deterministic reply. Twelve for twelve, and the outputs were better than the pass rate suggests. Every non-abstaining reply quotes the phrase it relied on, which is what makes the claim auditable: you can see which five words produced a window. Confidence tracks how directly the note states the thing, high on "This is the peak" and low on "Fruit starting to dry out at the edges", which is a hedge in my own note. And on "Could have waited another two years" from a 2024 opening it returned 2026, which is arithmetic rather than classification.

The abstentions are the part I did not expect. They name what the note actually contains: "the note only describes the occasion for opening the bottle and gives no signal about whether the wine was too young, drinking well, or past its best."

One honest result. Hunting for a proposal that would visibly move the counts turned into a search, because the seed data carries an assessment on nearly every wine, so the cases where an agent's claim wins outright are the leftovers. The first candidate lost on recency within its own tier: a personal claim of mine from 2018 outranked a proposal dated 2017. The agent's proposals mostly did not change the cellar, because I had usually already assessed the wine myself. That is the authority rule working, and editing the seed data to get better footage was considered for about a line, then rejected. It is the dataset three oracles were built against.

I verified the workflow against a staging copy of production rather than in a unit test. Two claims written in, neither moving a single count while proposed. One rejected, still moving nothing, though accepting it would have moved five bottles and emptied a wine out of Missed Opportunities. One accepted, moving exactly the five bottles predicted a day earlier.

What I cut, and why

One planned piece did not get built: a Function maintaining derived fields on wines and bottles, so the current state of each would be stored rather than computed.

The reason is that a projection is a cache, and the thing it would cache costs 0.07 milliseconds for all 542 bottles. Measured, not assumed. The App reads the event log directly and recomputes on every date change, which is under half a percent of a frame budget.

The more interesting reason is that a projection cannot do the thing this application exists to do. A stored state is true as of one date, which ADR 0012 forced into the open: any clock-dependent projection has to store the date it was computed for, beside the value. Nothing precomputed answers "what was the cellar on 1 June 1999" unless you precompute every date, and that is not a cache, it is a different data structure.

What would change at scale, since "it is fast enough for 542 bottles" is not an architecture:

The arithmetic is not what breaks first, and the numbers say so. The ledger is 211.9 KB today, about 400 bytes per bottle:

	Today	x100	1.5M bottles
Query payload	211.9 KB	20.7 MB	572.6 MB
Full state tally	0.07 ms	~7 ms	~200 ms

The fetch becomes impractical somewhere around fifty thousand bottles, two orders of magnitude before the scan starts dropping frames. A projection would not have helped with the half that breaks first. The fix is scoping the query, by producer or vintage or a search, and a scoped query already existed in the codebase before the Function was proposed.

Where a Function would genuinely earn its place is a different job. A projection is not only a cache, it is also what makes state queryable. Expressing authority-then-recency resolution in GROQ is possible, and my own spec describes it as possible and unreadable, needing a rewrite the first time a tier is added. So "show me every bottle past its window" would mean a second implementation of the load-bearing rule, in a second language, in a place the tests do not reach. That is why two of the Studio polish items were blocked on this Function, and it is a reason that applies at 542 bottles, not only at a million.

I still cut it, because nothing in the demo reads those fields and the writing was not done. But "we did not need the cache" is the smaller half of the answer.

Getting it in front of someone without an account

This took four prompts to settle and produced the finding I'd most want Sanity to see.

A deployed App SDK app cannot be shown to anyone outside your organization. The Dashboard gates on membership, and a changelog entry lists cross-organization visibility as a bug that was fixed. Hosting the app statically doesn't help either: AuthBoundary redirects a logged-out visitor to a login page before a single query is issued. Asked whether any supported configuration satisfies that boundary without a user token, the model enumerated the entire typed auth surface rather than sampling it. Every route resolves to a user token. The SDK recognizes two environments, a Dashboard iframe and a Studio, and a static host is not one of them.

There is exactly one typed field that would make a static page render by asserting it is a Studio. It was recorded as a near-miss rather than recommended, on three documented grounds including that it asserts something false.

So the public page drops the App SDK and reads the public dataset with a plain client. That touches one file, because everything downstream takes a Cellar object and knows nothing about Sanity, and the views are shared rather than forked.

Then the last surprise. A public dataset is exempt from authentication, not from CORS. An unauthenticated read from a github.io origin returns 403 until the origin is allowlisted. Every anonymous read this project had done went through curl, and curl sends no Origin header, so no CORS check had ever applied. Three sessions had verified the dataset was readable using a tool that structurally cannot test the thing that mattered. The failure would have been invisible until the page went live, because localhost was already allowlisted.

Three distinct access-control mechanisms, then, to get one page working: dataset ACL, organization membership, and origin allowlisting. None of them is discoverable from the surface the other two are configured on.

The answer was in the installed code, repeatedly

A pattern worth naming on its own, because it decided four separate questions.

Two doc pages contradict each other about whether the Prompt action requires a schemaId. Session 8 concluded that one of them is wrong and that reading more carefully would not reveal which. The installed type file reveals which in about a minute: PromptRequestBase declares four members, schemaId is not among them, and it is required four times on the other action types in the same file. The troubleshooting page is not merely wrong, it is backwards. Omitting the field is correct; including it is the type error.

That finding deleted a step I was about to take. A schema deploy had sat on the plan for five days as a production write, purely as insurance against a contradiction the type file settles.

The same thing happened with authentication. The HTTP reference says every endpoint requires bearer auth and says nothing about which clients satisfy it. The answer turned out to be in the AI Assist custom field actions guide, which is not a page about authentication and which demonstrates the pattern twice in complete examples with no token anywhere. The authoritative page created the difficulty; the page that resolves it does so incidentally, by example, with no sentence anywhere stating the fact. That removed the second planned production write.

Add the App SDK auth enumeration and the Functions bundling probe and it is four times in two weeks that the shipped code answered a question the documentation could not. The documentation is not bad. It is describing a platform moving faster than it can.

Two more findings I'd hand to Sanity

Functions bundling is documented as a project-wide choice and isn't. The docs describe TypeScript Functions in pnpm workspaces and non-TypeScript npm projects. This repo is npm plus TypeScript, which is neither. Rather than read more, I deployed a throwaway probe with one predetermined expected result. It worked first try, and inspecting the bundle explained why: the CLI inlined and tree-shook the local workspace package while externalizing the registry dependency. It decides per dependency, not per project. A private workspace package never has to be installable, only resolvable at build time.

A Function that does nothing gets an editor token. The probe constructed no client, ran no queries and wrote nothing. Deployment still provisioned a robot token with editor role and no expiry.

What the AI actually contributed

Not mainly speed. Probably faster, but that's the least interesting result.

It found errors in my specifications. It introduced its own bugs and caught some of them. It used mutation testing twice, unprompted, to prove that tests fail when the code they cover is removed. It refused to fabricate data when the ledger had no column for a link it was asked to infer, and that refusal exposed that one of my own verification scripts was passing on a proxy.

The conclusion I'd draw is narrower than "specs make AI-generated code trustworthy":

Specifications make disagreement observable. Independent witnesses make that disagreement useful.

Sometimes the witness is a CSV generated before implementation. Sometimes a second algorithm, a property test over 17,167 inputs, a benchmark, or the contents of a deployed bundle. Sometimes it's me reading six numbers off a screen, because the model cannot see them.

Four examples of why that matters more than green tests:

A date bug in the time control got January 31 to March 1 wrong. All five of my verification dates passed under the buggy version. The application worked, the screenshots were right, and every date I planned to demo was fine. A property test across every slider position found it.

A test asserting that proposed claims change nothing passed while measuring nothing, because its fixture would have lost on recency whether it was proposed or accepted. What caught it was the companion assertion that accepting must change at least one state. Auditing the rest of the suite for that shape found two more.

Then the same idea from the other direction. A CI check grepping the built bundle for leaked credentials fired on every clean build, because its pattern matched a legitimate export name from @sanity/client. A check that always fails gets waved through and certifies exactly as little as a check that can never fail, and it's worse, because a false positive doesn't look broken. It looks diligent.

And spec-first has its own failure mode, which I ran into late. A polish list drafted from the build plan turned out to have three items already done. A plan describes work that was scheduled, not work that is left.

The finding I keep coming back to is a different shape. A normalization rule written on day one, for a reason that had nothing to do with the interface, turned every drinking window into whole years. Weeks later that rule made a horizon slider useless, because the count could only change once a year. A stage after that, it made the obvious period for Missed Opportunities structurally empty, all year, every year. No document connects those three facts, and no amount of reading would have found them. Measuring the data did, twice, in about fifteen minutes each.

Specifications don't only prevent errors. They reach forward and constrain decisions nobody anticipated making.

Beyond the cellar

Wine makes this a pleasantly low-stakes problem. The pattern applies anywhere "what was true then?" matters alongside "what is true now?"

A museum needs to know which attribution it accepted when an object was exhibited, not only which one it holds today. An HR system needs to evaluate an action against the policy in force when it happened, not the policy as amended since.

The model underneath is the same in both: events record what happened, dated claims record what was believed, provenance records where those claims came from, and resolution decides what was knowable at a given moment.

It is not free. You can never answer "what is the drinking window?" without also answering "as of when?", every read costs a resolution pass instead of a field lookup, and nobody can simply set a value. Most systems should store current state, because most systems are only ever asked about now. The decision worth making deliberately is whether historical truth is a requirement or an accident.

Sanity Project Details

Project ID: aos9nze5 · Dataset: production (public)

The dataset is world-readable, so the content model can be inspected directly. Six document types: producer, wine, bottle, acquisition, consumption, assessment, plus a registered varietal object type. 1,645 documents.

About the data. The cellar is loosely based on a real one. The producers, appellations, and club memberships are real, and some of the history is too, including the 1993 Mouton bought in 1996 and opened twice in the nineties. Everything evaluative is invented. Drinking windows, scores, critic notes, and most tasting notes exist for the demo, and critic assessments are attributed to publications that do not exist. Nothing here should be read as a factual claim about any wine, and nothing attributed to a named producer reflects anything they have actually said.

Agent Session

The curated session is here: Ten conflicts before a line of code. It is a link rather than an embed: the transcript contains 383 @ characters, in package names and file paths, and the editor counts each as a user mention against a limit of ten, so the post would not save.

The full record is in the repository either way: fifteen session logs under docs/friction-logs/, each with the prompts and outputs verbatim, plus what was found and what it cost. If you only read one, read session 3, where ten conflicts came back before a line of code was written.

Addendum: the post's own argument, pointed at the post

A reader noticed something after publication that I had not, and it is the best catch of the project, so it belongs here rather than in a footnote.

The two questions at the top of this piece are not the same kind of question. What did my cellar look like on 1 June 1999 asks when things happened. What did I think that bottle's window was in 2018 asks when the ledger learned it. One date control answers both only while a claim starts counting on the day it is dated.

In the seeded data, it always does. The import wrote all 161 assessments as accepted, with assessedAt as their only date, so every date the demo can be driven to gives the same answer either way. The demo is accurate. It is accurate by accident of the import, not by design.

The agent workflow is where the two come apart. A proposal is dated the day after the bottle was opened, often years ago, and acceptance happens now. On acceptance, the resolver treats the claim as having counted since that past date, so an acceptance today can change what the cellar says about 2018. The Accept dialog warns about precisely this. The resolver has no way to represent the alternative.

The reason is that reviewState is stored current state with no history, which is the exact shape this post spends two thousand words arguing against. A claim either counts or it does not, and nothing records when that became true. It survived twelve architecture decision records because the field reads as workflow rather than as domain data.

The fix is one field: write acceptedAt alongside the transition, backfill it to assessedAt for the imported claims, and resolve on assessedAt <= T && acceptedAt <= T. One slider still answers both questions, because T then means the state of knowledge at T rather than what today's knowledge says about T.

I am not shipping it mid-judging, and it is recorded as ADR 0013. A project whose thesis is to write down what you got wrong should not stop doing that the moment it ships.

Your Metric Is Not Your State

Ken W Alger — Tue, 29 Sep 2026 16:13:00 +0000

What a refractometer taught me about observability

In July, I wrote about a farmer walking a vineyard row at dawn, crushing a grape onto a refractometer prism, and typing "13.5 Brix" into a chat window. The agent on the other end didn't care how the number arrived. To the Digital Scribe, I wrote, a number is just a number.

In the vineyard, that's a defensible position. Fresh grape juice is exactly what a refractometer is built to read.

This fall, I've been pointing the same kind of instrument at juice that's fermenting. It turns out the agent should have cared.

Three batches and a prism

Over the last several weeks I've started three small batches: a blackberry wine that's now bulk aging, a pear wine that began fermenting on September 24, and a fireweed honey mead that got its yeast two days later. They're one-gallon batches, which matters for this story, because at that size every sample you pull is wine you don't get to drink and oxygen you've let in.

So I track them with a refractometer. A few drops of liquid on a glass prism, close the cover, hold it up to the light, read a number off the scale. The number is Brix, roughly the percentage of dissolved sugar. It's fast, cheap, and costs a few drops per reading. During the blackberry's primary fermentation I took readings twice a day, every time I punched down the cap of fruit.

And once fermentation starts, the refractometer is wrong.

The instrument isn't lying, exactly

A refractometer measures how much light bends as it passes through a liquid. Dissolved sugar bends light, so in fresh juice the amount of bending is a good proxy for the amount of sugar. The scale on the instrument is calibrated on that assumption.

Fermentation breaks the assumption. Yeast converts sugar into alcohol, and alcohol bends light too. A few days into primary, the refractometer is reporting the combined effect of the sugar that remains and the alcohol that's been produced, and presenting all of it as sugar. The reading comes out higher than the real sugar content. Taken at face value, it says the fermentation is further behind than it actually is.

To get something usable, you run each reading through a correction formula. Most home winemakers use calculators built on formulas originally developed for brewing, and every one of them needs the same extra input: the original reading, taken before the yeast went in.

Here's what that looked like on the blackberry:

Day	Raw refractometer (Brix)	Corrected value
08/29/2026	20.7	20.7
08/30/2026	18.4	16.5
08/30/2026	17.0	14.3
08/31/2026	13.2	8.1
08/31/2026	10.8	4.1
09/01/2026	8.7	0.7
09/01/2026	8.3	0.1

Nothing is malfunctioning. The instrument is doing exactly what it was built to do. What changed is the system it's pointed at, and a number that was a reliable proxy in one state became a misleading one in the next.

Neither instrument measures sugar

The traditional alternative is a hydrometer, a weighted glass float. The deeper it sinks, the less dense the liquid. Sugar makes liquid denser, so falling specific gravity means sugar is being consumed.

Except the hydrometer doesn't measure sugar either. It measures density, and alcohol is less dense than water, so as fermentation proceeds the alcohol pulls the reading down on its own. A finished dry wine routinely reads below 1.000, lower than plain water, which would be impossible if the hydrometer were really a sugar meter.

So the refractometer measures how light bends and the hydrometer measures how heavy the liquid is. Neither measures what I actually care about: how much sugar is left, whether the yeast is still working, whether this wine is done. I infer those. The instruments give me evidence.

Even a steady reading is ambiguous. The traditional sign that fermentation has finished is the same reading several days running. But a fermentation that has stalled also produces the same reading several days running. Mead is notorious for this: honey has very little natural buffering, the pH drifts down as fermentation proceeds, and the yeast can slow or stop well short of dry. A flat line can mean done or stuck, and the instrument can't tell you which. You tell them apart with other evidence: where the line flattened, what the pH is doing, what you expected to see.

That distinction between evidence and state sounds pedantic until you notice it's one we get wrong in software constantly.

Your dashboard has the same problem

CPU utilization isn't health. A service at 15% CPU can be deadlocked, and one at 90% can be doing exactly what you want. An HTTP 200 isn't correctness; it tells you the server returned a response, not that the response was right. A green health check tells you the health check endpoint answered. Model confidence isn't truth; it's a number the model produced about its own output.

Each of these started as a reasonable proxy under a particular set of conditions. Then the system changed, a new failure mode appeared, or someone started optimizing the number itself, and the proxy drifted away from the state it was meant to represent. The dashboard kept rendering it with exactly the same authority.

That's the refractometer problem. The metric was calibrated for one state of the system and is now being read in another, and nothing on the display tells you so. And like the flat fermentation line, a steady metric can mean two opposite things: a quiet error rate might mean a healthy service, or one that stopped receiving traffic an hour ago.

The failure isn't collecting the metric. It's treating the metric as the state instead of as evidence about the state.

A reading needs its history

Back to that correction formula. To interpret today's reading, you need the reading from before fermentation began. Without it, the current number is close to uninterpretable. The same Brix value could describe a fermentation that has barely started or one that's nearly finished, depending entirely on where it began.

The meaning of a measurement depends on its lineage.

This is where I think observability practice most often falls short. We store the value and the timestamp and call it a record. What we usually drop is everything needed to interpret it later: which instrument produced it, under what conditions, what calibration assumptions it carried, what baseline it should be read against, and what state the system was believed to be in at the time.

My fermentation log keeps the raw reading and the corrected value side by side. The corrected value is what I act on. The raw value is what I re-derive from if I later learn the correction was off, find a better formula, or discover I misread the original. A corrected value on its own is a conclusion with its evidence thrown away.

That's a pattern worth stealing. Store the observation separately from the interpretation. Keep the provenance that makes the observation meaningful. Let state be something you derive, with its evidence attached, rather than something you overwrite. It's the same idea behind the forensic receipt work I've been doing: a claim should carry what it was based on.

Watching isn't free

One more thing the one-gallon batches have taught me. I use a refractometer because a hydrometer needs a much larger sample, and in a small carboy that sample is a real fraction of the batch, and pulling it lets oxygen in. The act of measuring changes the system being measured.

It also means deciding how often to look. The blackberry had to be punched down twice a day anyway, so twice-daily readings were free. The pear and the mead don't need that kind of handling, so I've settled on a reading every couple of days: often enough to catch a stall, rare enough to leave the batch alone. That's a measurement policy, and it means my log has deliberate gaps in it. Those gaps are their own story, and I'll come back to them.

Software has the same trade-off: tracing overhead, probes that add latency, sampling that shifts timing. Usually the effect is small. Sometimes it isn't, and how often to look is a design decision with costs on both sides.

Evidence, then state

Here's what I've taken from a few weeks of squinting at a prism.

Separate what you observed from what you concluded. "The refractometer read 9 Brix" and "fermentation is about two-thirds done" are different kinds of statement. They belong in different places, and they should be allowed to disagree.

Keep the raw reading. Corrections, normalizations, and aggregations are interpretations. If you keep only the interpreted value, you can never revisit the interpretation.

Record the conditions that make a reading meaningful. Instrument, baseline, calibration assumptions, the believed state of the system. A metric without its context is a number waiting to be misread.

Treat state as a derived claim. "Fermentation is complete" isn't a reading. It's a conclusion drawn from several readings over time, plus whatever evidence rules out "stuck," and it should be traceable back to all of it.

Notice when your proxy stops being a proxy. Every metric was calibrated for some range of system behavior. When the system leaves that range, the metric keeps reporting with exactly the same confidence.

The agent in July was right about one thing: it shouldn't matter whether a number comes from a clipboard or a five-thousand-dollar probe. Where it was wrong was in believing the number could travel without its history.

The pear wine is still in primary as I write this. The raw refractometer reading says it has a long way to go. The corrected number says otherwise, and the corrected number is only trustworthy because I wrote down what the juice read before the yeast went in.

The number on the instrument isn't the system. It never was.

Code Review Is Not an Authority Boundary

Ken W Alger — Tue, 29 Sep 2026 14:28:19 +0000

AI can generate the implementation. Your architecture still has to decide what that implementation is allowed to do.

I was reading a good post about the walls JavaScript hits and how WebAssembly gets past them, and I got stuck on one of them: running code you did not write and do not trust.

The framing we normally reach for is "how do I stop this extension from misbehaving?" That question already concedes something. It assumes we have handed the extension access to things worth abusing, and that our remaining defense is its good conduct.

There is a different question underneath it. What is this extension actually entitled to have?

I wanted to know whether that distinction survives contact with running code, so I built a small capability-mediated tool host to find out. It is about 200 lines of Python rather than a Wasm runtime, because the thing worth testing is the host interface, and every environment that mediates untrusted code has one. Everything below that reports behaviour is output I actually got, including the part where my own preferred answer turned out to be wrong.

From Trust to Authority

For most of software's history we have put enormous weight on code review. Someone writes code, someone else reads it, tests run, static analysis checks it, and eventually we decide it is trustworthy enough to merge, deploy, or execute.

That model made sense when software was expensive to produce and the people writing it were known participants in the process. AI changes the economics. Code is cheap to generate now, and an agent can write a function, produce a plugin, or assemble an entire implementation in minutes. The question is less whether we can produce the code and more what that code is entitled to do once we run it.

Those are different problems. Code review, however good, only solves one of them.

This Has a Name, and It Is Older Than Most of Us

None of the architecture here is my invention. What I am describing is capability-based security, and it has a long, well-developed literature.

Dennis and Van Horn described capabilities in 1966. Mark Miller named the principle of least authority and built the E language around object capabilities. Capsicum brought a capability model to FreeBSD. seL4 has a machine-checked proof of its capability enforcement. Deno shipped a permission model where filesystem and network access are grants rather than defaults. WASI Preview 2 and the Component Model are capability-oriented by design, which is exactly why the Wasm conversation keeps circling this.

The core idea is consistent across all of them. Instead of giving code broad access and expecting it to behave, the execution environment grants specific capabilities: this directory, this socket, this operation and not that one. The implementation does not promise to stay inside its authority. It never receives the authority in the first place.

So the architecture is not new. What is new is that we are about to produce vastly more code whose author we cannot interview.

Sandboxing Constrains Execution, Not Authority

A sandbox sounds reassuring. Put untrusted code in an isolated environment and prevent it from reaching the rest of the system.

Suppose I have a perfectly sandboxed module. It cannot escape its runtime and cannot access anything the host does not explicitly expose. Excellent. Now suppose the host exposes:

read_customer_records()
write_customer_records()
delete_customer_records()
send_email()
issue_refund()
export_database()

The sandbox is working exactly as designed, and the module is wildly over-privileged. We have constrained where the code executes without constraining what it is authorized to affect. The host interface has quietly become the real trust boundary.

The Wasm people say as much themselves. All I/O in a module goes through its imports and exports, which means a module's view of the outside can be virtualized entirely by controlling what those imports are linked to. That is a precise description of the control surface, and also an admission that the surface is where the decisions live.

That is the eighth wall hiding inside the untrusted-code one. Not "can I run code I do not trust," but "can I make what that code is allowed to do explicit, minimal, enforceable, and inspectable?"

Sandboxing constrains execution. Capability grants constrain authority. You need both, and only one of them is commonly discussed.

Two Agents, One Test Suite

Here is the experiment. Two implementations reconcile invoices against payments and produce a report. agent_a reads invoices and reads payments. agent_b does the same reconciliation and also decides that a shortfall is worth refunding and that someone ought to be told.

Both produce the identical report. The test suite cannot tell them apart:

The test suite both implementations have to satisfy:

  PASS  agent_a produces the expected reconciliation report
  PASS  agent_b produces the expected reconciliation report

Nothing in agent_b is a bug. A reviewer reading it would find defensible code. The refund is small, the alert is reasonable, the logic is sound. It is simply reaching for a great deal more authority to achieve the same output, and no assertion about the output can detect that, because the difference is not in the output.

Now run both against a least-privilege manifest:

agent_a:
  completed
  ALLOW  invoices.read      read_invoices
  ALLOW  payments.read      read_payments

agent_b:
  stopped: issue_refund requires refunds.issue, which was not granted
  ALLOW  invoices.read      read_invoices
  ALLOW  payments.read      read_payments
  DENY   refunds.issue      issue_refund

The runtime caught it. No reviewer was involved, no test asserted anything about refunds, and that DENY line is a durable record of an authority boundary being enforced rather than a claim that somebody looked and did not see a problem.

One caveat on what that manifest actually bounds, before anyone reads the demo as stronger than it is. Miller and Shapiro distinguish permission from authority: permission is what the access graph grants you directly, while authority is what you can cause, including indirectly through other components you are permitted to talk to. My host controls permission. A component granted invoices.read that can also call something else holding payments.write has more authority than its manifest suggests. Real capability systems address this by making the reference graph itself the thing you reason about. Two hundred lines of Python do not.

That is the argument in fourteen lines of output. Why can an invoice-reconciliation program issue a refund? Perhaps today's implementation does not. Perhaps review confirms it never calls the refund API. Those are observations about one implementation, and the implementation is the part we just made disposable.

Disposable Implementation, Durable Authority

If implementation is cheap, the code becomes increasingly disposable. We can regenerate it, replace it, or ask a different model for an alternative.

Some things cannot be disposable. The contract describing correct behavior is one. The authority granted to the implementation is another. The manifest above survives every regeneration of the component beneath it, which is precisely why it is worth writing down and the code is not.

This is already live in the agent tooling most of us are wiring up. An MCP server hands an agent a set of tools. That tool list is a capability grant, whether or not anyone has written it down as one, and the people building these servers keep arriving at the same requirements independently: per-tool audit records, tenant isolation, dynamic registration. Those are capability-system features reached from the practical end.

"We Tried This. It Became Permission Fatigue."

Here is the objection I would raise if someone showed me a capability manifest, and it is a strong one.

We have deployed manifest-based capability declaration at planetary scale already. Android permissions. Browser extension manifests. iOS entitlements. The result was not security. It was users tapping Allow on everything, reviewers rubber-stamping manifests they did not read, and developers requesting broad permissions because narrow ones generated support tickets. Capability systems have a long history of being architecturally correct and operationally ignored.

Two things are different here, and neither is optimism about human diligence.

The grantor is not a person. In the consumer model a human decides at install time, under time pressure, with no context and every incentive to proceed. Here a policy decides. Policies do not get fatigued, do not want the app to work right now, and can be versioned, tested, and audited.

The requester is regenerable. This is the part earlier systems could not use. When a shipped application hits a too-narrow permission, the permission widens, because rewriting the app is expensive and the user is waiting. When a generated component hits a too-narrow capability, regenerating the component is cheap. The pressure that historically pushed grants wider now pushes implementations to fit the grant instead.

That inversion is the actual reason this might work now, and it is a consequence of implementation becoming disposable rather than of anyone becoming more disciplined.

The Model Should Not Grant Its Own Permissions

If the same model generates the implementation, proposes its tests, decides which tools it needs, and determines its own permissions, we have built a very cooperative security model. The agent says: here is the code I wrote, here are the tests demonstrating it works, and here are the permissions I determined I require. All three may be reasonable. All three come from the same information lineage.

I have made a version of this argument before about tests, which I described then as not letting the student grade the exam. Authority is the same problem one layer over, and it is the more consequential one. A wrong test produces a wrong belief. A wrong grant produces a wrong consequence.

A stronger system keeps some decisions outside that lineage. The model proposes that it needs read access to invoices. A policy determines that invoice reconciliation permits invoices.read. The runtime grants that capability while leaving payments.write and refunds.issue unavailable. An audit record shows what authority was actually granted at execution.

The model can participate without owning the boundary.

Where My Own Answer Broke

That leaves the hard part. Somebody has to write the policy, and I wanted to know whether the obvious shortcut works.

The shortcut is observation. Run the component, record which capabilities it actually reaches for, and derive a least-privilege manifest from what you saw. It is the standard move, it is roughly what audit-mode tooling does across the industry, and it is what I assumed I would end up recommending.

So I ran it. Discovery mode on agent_a produces exactly what you would hope:

Discovery mode: allow everything, record what was actually reached for.

  ALLOW  invoices.read      read_invoices
  ALLOW  payments.read      read_payments

Derived manifest:

component: invoice-reconciler
capabilities:
  invoices: {read: true, write: false}
  payments: {read: true, write: false}
  refunds: {issue: false}
  network: {external: false}

Tight, minimal, derived from real behaviour rather than a guess. Then I ran the same component against an input the discovery run never saw: a credit note, which legitimately requires writing an adjusting payment record.

  stopped: write_payment requires payments.write, which was not granted
  ALLOW  invoices.read      read_invoices
  ALLOW  payments.read      read_payments
  DENY   payments.write     write_payment

The component is correct. The manifest is wrong. It forbids a legitimate path because nothing exercised that path on the day we happened to be watching.

This is not a bug in my implementation, and tightening the derivation would not fix it. Observation tells you what a component did, not what it may need. A derived manifest is a lower bound on required authority presented as an upper bound on granted authority, and those are different claims. In production that failure arrives as an outage on the rare path, which is exactly how capability systems earn their reputation as obstacles and then get widened until they mean nothing.

I do not have a clean answer, and I am not the first to fail to have one. Miller, Tulloh and Shapiro named this in 2004: treating security as a separate concern has not bridged the gap between principle and practice, they argue, because it operates without knowledge of what constitutes least authority, and only when requests are made can we determine how much authority is adequate. My credit note is that sentence with a stack trace attached. Twenty years on the shortcut still does not work, which suggests the diagnosis was right rather than that I picked an unlucky example.

What I have is a demonstration that the answer I expected to give is wrong, which is worth more than the recommendation would have been.

The partial signals that survive: a declared interface implies a floor. Denied-capability telemetry tells you where a grant was too tight, if somebody is reading it. And the credit-note path suggests capability sets belong with the specification rather than the trace, because whoever knew credit notes existed knew it before any code ran.

That is the same conclusion I keep reaching from other directions. Once implementation is cheap and verification is automatable, the scarce work is discovering what the definition of correct should contain. Capability discovery is that problem wearing different clothes.

Correctness and Authority Are Orthogonal

The two-agent run makes this concrete. Code can be correct and over-privileged, as agent_b is. Code can be incorrect and tightly constrained. The authority boundary limits one class of consequence without establishing correctness.

A word about that heading, since the paper linked earlier is called "Why Security Is Not a Separable Concern" and appears to say the opposite. Miller's argument is that you cannot bolt security on afterwards as its own layer, because knowing what least authority means requires knowing what the program is for. Mine is narrower: evidence that an implementation is correct is silent about what that implementation may affect. He is describing where the work belongs in a design. I am describing what a passing test proves. Both land in the same place, which is that somebody who understands the task has to make the authority decision deliberately.

A perfectly implemented image-resizing plugin should not reach payroll records. A buggy image-resizing plugin with no filesystem, network, or unrelated API access may cause considerably less damage than a correct implementation carrying unnecessary privileges.

Verification asks whether an implementation satisfies its behavioral contract. Authority asks what consequences that implementation is permitted to create. Tests do not establish least privilege, and least privilege does not establish correctness. We need evidence for both, and I now have a fourteen-line proof that one kind of evidence is silent about the other.

Code Review Still Matters

None of this makes code review obsolete. Generated code contains logic errors, security vulnerabilities, bad dependency choices, race conditions, and plenty else worth finding.

But code review is evidence about implementation. It should not be mistaken for enforcement of authority. If a system's safety depends on a reviewer noticing every dangerous operation an implementation could perform, we have made human attention part of the security boundary.

A capability boundary gives us another layer. The reviewer can miss something, the model can misunderstand something, the implementation can contain behaviour nobody anticipated, and if the component was never granted the capability required to produce a particular consequence, that consequence remains unavailable.

That is a considerably stronger guarantee than "we reviewed the code and did not see it doing that."

What Survives Regeneration?

Suppose an agent writes a component today. Tomorrow we regenerate it with a different model. Next month we replace the implementation entirely. What should remain stable?

The code does not need to. The tests probably should. The behavioral contract certainly should. The authority boundary absolutely should.

Which suggests a future where the most important artifacts around software are not implementation artifacts at all. They are declarations of what correctness means and what consequences an implementation is entitled to create.

The model can write the code. It can even propose the capabilities it believes the code needs. But the system executing that code should have an independent answer to a much more important question: what is this implementation allowed to do?

The host is about 200 lines of Python with one dependency. Four scenarios: correctness, authority, discover, verify. The last one is the interesting one, because it is where the obvious answer breaks. Gist on GitHub.

I Pulled Nine Years of My Own Dev.to Data. The Numbers Were Not What I Expected.

Ken W Alger — Thu, 24 Sep 2026 13:38:00 +0000

There is an API. It will tell you things about your writing that the dashboard will not.

I have been publishing on Dev.to since April 2017. There is a four-year hole in the middle where I posted almost nothing, and then a return in March 2026 that has produced eighty-six posts in six months.

That shape turns out to be useful. Two distinct bodies of work, on the same account, separated by a gap long enough that the platform itself changed underneath them. A natural experiment I did not set out to run.

What I wanted was simple: a chart of follower growth with my article publication dates overlaid, to see whether particular posts moved the line. What I got instead was a fairly uncomfortable education in which of my numbers mean anything.

The API made all of it possible, and almost nobody seems to use it.

Yes, There Is an API

Base URL is https://dev.to/api. You generate a key at Settings → Extensions → DEV Community API Keys. Most read endpoints for your own data want that key in an api-key header.

There is one detail that will silently ruin your afternoon:

headers = {
    "api-key": key,
    # Omit this and you get v0 responses. No error. No warning.
    "accept": "application/vnd.forem.api-v1+json",
    "user-agent": "my-analytics-script/1.0",
}

Without the accept header you are served the older v0 serializer. Nothing fails. The shapes are just quietly different, and you will spend twenty minutes wondering why a documented field is missing.

Trick One: The Default Page Size Is Not the Maximum

The followers endpoint is documented as returning 80 per page. I have a little over eighteen thousand followers, which is 227 round trips.

The v1 pagination range actually runs to 1000. The 80 is a default, not a ceiling:

batch = client.get(
    f"{API_ROOT}/followers/users",
    params={"page": page, "per_page": 1000},
).json()

Nineteen requests instead of 227. Thirty-one seconds instead of however long 227 polite requests would have taken.

A Forem instance can cap per_page lower through an environment variable, so do not hardcode the assumption. Ask for the maximum, then learn the real stride from what comes back:

if page == 1 and len(batch) < requested:
    # Either the server capped us or that is the entire list.
    # Either way, this is the real page size.
    page_size = len(batch)

Rate limiting is real and it is not gentle. Back off on 429, sleep between pages, and checkpoint your merged results to disk every few pages. A long first pull that dies on page 190 should not discard the previous 189.

Trick Two: Follower Dates Reconstruct History You Never Recorded

This is the single most useful thing in the API and it is easy to miss.

/api/followers/users returns a created_at on every follower: the date that person started following you. You do not need to snapshot your follower count daily and wait six months to accumulate a time series. One pull reconstructs the entire curve retroactively, back to your first follower.

from collections import Counter
from datetime import date, timedelta

dates = sorted(
    date.fromisoformat(f["created_at"][:10]) for f in followers
)
cumulative = list(range(1, len(dates) + 1))  # the growth curve, free

weekly = Counter(d - timedelta(days=d.weekday()) for d in dates)

There is a catch worth stating plainly, because it took me a moment to see it. You only receive people who currently follow you. Anyone who followed and later unfollowed has vanished from the dataset. So the curve is "current followers by acquisition date," not your follower count as it stood on any given day. It increases monotonically by construction and can never show you a decline that actually happened.

For working out which posts drove acquisition, fine. For anything about retention, actively misleading.

Trick Three: The Analytics Endpoints Exist and Are Barely Documented

There is a whole analytics family that most third-party tooling ignores:

/api/analytics/totals               lifetime views, reactions, comments
/api/analytics/historical           daily series over a date range
/api/analytics/past_day             hourly, last 24 hours
/api/analytics/referrers            where the traffic came from
/api/analytics/follower_engagement  follower growth over time
/api/analytics/dashboard            totals + history + top posts, bundled

All accept article_id to scope to a single post. Two things to know.

The responses nest. They are not flat integers:

{"page_views": {"total": 246454, "average_read_time_in_seconds": 306}}

And the historical data degrades as you go back. For my 2017 posts the endpoint returns weekly buckets rather than daily rows, and in aggregate accounts for only about 15% of those posts' lifetime views. For 2019 it covers 95%. For 2026, 100%.

That matters more than it sounds. I computed a "half-life" for each post, meaning days from publication until it had earned half its views to date. My first attempt confidently reported that several 2017 posts had half-lives around 3,000 days. They do not. The endpoint simply does not remember most of what those posts earned, and dividing a remembered fraction produces a precise, authoritative, meaningless number.

The fix is a coverage gate:

lifetime = article["page_views_count"]
tracked = sum(daily_series.values())

# A series accounting for 15% of a post's views will still yield a
# confident half-life. It will be an artifact of what the endpoint
# retained, not of how the post aged.
if lifetime and tracked < lifetime * 0.8:
    continue

Eighty-two of my 130 posts survive that gate. The median half-life among them is four days.

Trick Four: Some Metadata Is in the Markdown, Not the JSON

I write multi-part series. None of my posts came back with a collection_id, which is the field you would reach for to group them.

The series are right there in the Dev.to UI. The article serializer just does not include the field.

But /api/articles/me/published returns body_markdown, front matter and all, and the series name is sitting in it:

FRONT_MATTER_SERIES = re.compile(r"^series:\s*(.+?)\s*$", re.M)

def series_name(article):
    body = article.get("body_markdown") or ""
    if not body.lstrip().startswith("---"):
        return None
    parts = body.split("---", 2)
    if len(parts) < 3:
        return None
    match = FRONT_MATTER_SERIES.search(parts[1])
    return match.group(1).strip().strip("\"'") if match else None

General lesson: when a field you expect is absent from the JSON, check whether the source document came back too. It often did.

Trick Five: Comments Arrive Pre-Threaded

/api/comments?a_id={id} returns comments as a tree, with each comment's replies nested in children. The structure is doing analytical work for free, and flattening it while preserving depth takes about eight lines:

def flatten(nodes, depth=0):
    out = []
    for node in nodes or []:
        out.append({
            "depth": depth,
            "username": (node.get("user") or {}).get("username"),
            "created_at": node.get("created_at"),
            "text": strip_html(node.get("body_html")),
        })
        out.extend(flatten(node.get("children") or [], depth + 1))
    return out

Depth is the metric that matters. Comment count cannot distinguish eight people each saying "great article" from two people arguing with you for four rounds. Maximum thread depth can. One of my posts has a thread 35 levels deep. That is not a comment section, it is a sustained argument, and no count-based metric would have told me it happened.

There is no endpoint for creating comments, incidentally. Replying still requires the browser. Probably deliberate.

What the Data Actually Said

Here is where the exercise stopped being a programming problem.

My follower count is not a readership number. I gained roughly 18,000 followers in 2026. My 2026 posts have 14,300 total views between them. You cannot acquire eighteen thousand followers from fourteen thousand views. The daily rate sits at a median of 136 with no meaningful response to whether I published anything, and about 37% of the usernames carry auto-generated-looking hex or numeric tails. That is reciprocal-follow farming, it is endemic, and it has nothing to do with me. It does mean the chart I originally set out to build could never have answered the question I was asking.

My most-viewed work is nine years old and no longer being read. My 2017 output was MicroPython, NodeMCU, and MongoDB tutorials. Forty-four posts from 2017 to 2019 pulled 32,474 views. Eighty-six posts in 2026 have pulled 14,300. But the daily series tells the other half: my 5,472-view NodeMCU post has had zero views in the last ninety days. Nineteen of my 130 posts are at zero for the quarter. Lifetime counters never decrease, which makes an archive look alive long after it has stopped breathing.

The engagement numbers invert completely. Those big old tutorials run about 2 reactions per thousand views. My 2026 essays run 56 to 72, with one at 71.6 reactions and 63.8 comments per thousand. Across the eras: 44 old posts drew 26 comments total. 86 new posts have drawn 606.

So one body of work got found and skimmed. The other gets read and argued with. They are different products, and I had been evaluating both with the same number.

Four percent of my traffic is Google. Direct or unknown is 74.5%. Internal Dev.to is 19%. For someone whose best-performing historical content is evergreen reference material, that is the number I find hardest to look at.

What I Would Tell Someone Starting This

Pull the followers once and cache them, because the dates reconstruct years of history you never thought to record. Gate every analytics computation on data coverage, because a partial series will hand you a confident wrong answer rather than an error. Read thread depth instead of comment count. And check body_markdown before concluding a field does not exist.

Mostly, though: separate the metrics that measure distribution from the metrics that measure whether anyone cared. Views, follower counts, and impressions are the first kind. Comment depth, reply rates, and the fact that the same four people keep showing up in your threads are the second.

I spent nine years assuming the first kind was the scoreboard. The API took an evening to tell me otherwise.

Memory Is a System, Not a Prompt: Putting the Stack to Work

Ken W Alger — Tue, 22 Sep 2026 13:54:00 +0000

Part 9 of the Building the AI Memory Stack series

This series began with a deceptively simple observation: a context window is not memory.

That idea evolved into an architectural model for building AI systems that remember, explain, verify, and restore information responsibly. Along the way we explored the purpose of the Context Window, the role of Active Working Memory, the permanence of Durable Memory, the accountability provided by the Reasoning Ledger, the trust established through Write-Side Custody, the cryptographic evidence supplied by Forensic Receipts, the restoration performed by Context Hydration, and the economic realities introduced by architectural taxes.

Those individual ideas are not isolated concepts. Together they form a coherent system.

Six Architectural Responsibilities

The AI Memory Stack is not six storage technologies layered on top of one another.

It is six architectural responsibilities every trustworthy AI system must answer.

Responsibility	Question	Sovereign Concept
Execution	What can I see right now?	Context Window
Assembly	What matters right now?	Active Working Memory
Preservation	What should survive?	Durable Memory
Explanation	Why did this happen?	Reasoning Ledger
Integrity	Should this become truth?	Write-Side Custody
Evidence	Can I prove it?	Forensic Receipt

Each responsibility exists because it solves a different problem. Durable Memory cannot explain why a decision was made. A Reasoning Ledger cannot prove its records have not been modified. A Context Window cannot preserve institutional knowledge. Together they create a system that is substantially more capable than any individual component.

Teaching Order Versus Runtime

Throughout this series we intentionally walked down through the stack, beginning with the familiar idea of prompts before gradually uncovering the deeper responsibilities beneath them.

A production system operates in the opposite direction.

flowchart LR
    WSC["Write-Side Custody"] --> RL["Reasoning Ledger"]
    RL --> DM["Durable Memory"]
    RL --> FR["Forensic Receipt"]
    DM --> HY["Context Hydration"]
    HY --> AWM["Active Working Memory"]
    AWM --> CW["Context Window"]
    CW --> MI["Model Inference"]

    style WSC fill:#1D9E75,stroke:#11644a,stroke-width:2px,color:#fff
    style RL fill:#1D9E75,stroke:#11644a,stroke-width:2px,color:#fff
    style FR fill:#1D9E75,stroke:#11644a,stroke-width:2px,color:#fff
    style DM fill:#BA7517,stroke:#834f0c,stroke-width:2px,color:#fff
    style HY fill:#6B7280,stroke:#374151,stroke-width:2px,color:#fff
    style AWM fill:#BA7517,stroke:#834f0c,stroke-width:2px,color:#fff
    style CW fill:#BA7517,stroke:#834f0c,stroke-width:2px,color:#fff
    style MI fill:#BA7517,stroke:#834f0c,stroke-width:2px,color:#fff

New information first passes through Write-Side Custody, where it is sieved and evaluated before becoming institutional knowledge. The reasoning behind the decision is recorded in the Reasoning Ledger, that record is sealed with a Forensic Receipt, and the verified knowledge is committed to Durable Memory. Later, Context Hydration reconstructs only the verified information required for the current task, placing it into Active Working Memory before it reaches the Context Window.

Teaching order optimizes understanding.

Runtime order optimizes execution.

From Architecture to Implementation

Throughout this series the discussion has intentionally remained architecture-first. None of these responsibilities require a particular programming language, framework, model provider, or database.

Architectures should outlive implementations.

Implementations are how architectures prove themselves.

The Sovereign SDK is intended to be a reference implementation of the Sovereign Systems Specification rather than a single monolithic AI framework. Instead of hiding every responsibility behind one package, it decomposes the architecture into focused components that mirror the boundaries defined by the specification.

That distinction matters.

The SDK is not the specification.

It is one implementation of it.

Responsibilities Become Components

The reference SDK organizes these responsibilities along the information lifecycle, from the moment an observation is captured to the moment it informs reasoning. Each package owns one boundary in that progression.

Stage	Package	Status	Purpose
Capture	`sovereign-sdk-sensor`	Active	Capture observations at the Point of Genesis
Classification	`sovereign-sdk-edge`	Active	Route, classify, and preserve locality
Optimization	`sovereign-sdk-sieve`	Active	Reduce Prose Tax while preserving meaning
Evidence	`sovereign-sdk-ledger`	Active	Generate immutable Forensic Receipts
Governance	`sovereign-sdk-airlock`	Active	Govern outbound boundary crossings
Memory	`sovereign-sdk-vault`	Planned	Long-term memory custody and retention

The responsibilities this series named map onto that lifecycle. The write boundary the series called Write-Side Custody runs across the capture, classification, and optimization stages, where observations are validated and stripped of Prose Tax before they are trusted. Forensic Receipts are minted by the ledger. Outbound governance runs through the airlock. Durable Memory is the vault, the single piece still on the roadmap. Assembly, explanation, and hydration compose these packages in the application layer above them.

You don't have to take the architecture on faith. The Sovereign Memory Demo, the flagship reference implementation, shows the stack running end to end: audited institutional memory retrieval with local, tamper-evident ledger custody. You can browse it and the demonstrations that follow it from the demos index.

As the SDK grows, packages may change names, implementations will evolve, and new capabilities will emerge. The architectural responsibilities, however, remain stable. A Rust implementation, a Go implementation, or a Java implementation could all faithfully implement the same architecture while looking completely different internally.

That is one of the primary goals of the Sovereign Systems Specification: separating enduring architectural ideas from temporary implementation details.

Earlier in this series we observed that a context window is not memory. The SDK is the architectural consequence of that observation. Rather than trying to solve every problem inside the prompt, it distributes responsibilities across specialized components that preserve, explain, verify, govern, and restore information throughout its lifecycle.

Memory Is Infrastructure

The central argument of this series has never been that prompts are unimportant.

Prompts matter.

Models matter.

Retrieval matters.

What this series argues is that they are only part of a larger system.

Thinking in terms of Memory as Infrastructure changes the design conversation. Instead of asking how to fit more information into a prompt, we begin asking how information should be accepted, preserved, verified, restored, governed, and ultimately communicated back to a model.

Those are architectural questions.

And architectural questions tend to outlive technology cycles.

Final Thoughts

Every generation of software eventually discovers that the difficult problem is not computation.

It is memory.

Databases changed how applications remembered.

Version control changed how teams remembered.

Observability changed how operators remembered.

Artificial intelligence is forcing us to rethink how intelligent systems remember.

Larger context windows are one answer.

Better memory architecture is another.

This series has argued that the second answer will ultimately matter more.

Prompts are temporary.

Memory endures.

The future of AI belongs to systems that remember well.

Frameworks Are Institutional Memory

Ken W Alger — Thu, 17 Sep 2026 17:07:00 +0000

I stored passwords in plaintext on a floppy disk in the 1980s. Recently, a coding agent made a version of the same mistake.

When I was running bulletin board systems in the 1980s, password management could be remarkably straightforward.

A user created an account. They chose a password. The BBS needed to determine whether the password they entered later was the same one they had chosen.

So you stored it.

In plaintext.

On a floppy disk.

Hard drives were expensive and hardly universal in the hobbyist computing world I inhabited, so there was nothing strange about application data living on floppies. The important thing was that the software could retrieve the password and compare it against whatever the user typed the next time they called in.

Something like this was perfectly understandable:

KEN|swordfish
SARAH|password123
MIKE|enterprise

There was, of course, a slight problem.

The person running the BBS could read everybody's passwords.

So people started solving that. Maybe the password should not be stored exactly as the user entered it. A substitution cipher or some other homegrown transformation could at least stop someone from casually opening the user file and reading every credential.

Problem solved.

Well. One problem solved.

The transformation might be reversible. Two users choosing the same password produced the same stored value. A compromised file exposed everyone at once. Users reused those passwords elsewhere. Password recovery introduced an entirely separate collection of problems.

Each solution exposed another question.

Over the following decades, "store a password" accumulated an extraordinary amount of engineering knowledge.

Today, saying an application needs authentication describes far more than comparing one string against another. It means hashing, salts, password reset, expiring tokens, single-use tokens, session invalidation, account enumeration, brute-force protection, cookie attributes, CSRF, rate limiting, and a long list of other concerns depending on the threat model.

A developer can still build all of that from scratch.

The more interesting question is whether they should.

The Code You Don't Know You Need

The first thing developers learn about frameworks is that they save us from writing code.

That is true, and it undersells them badly.

A mature framework does not merely contain code somebody else wrote. It contains decisions somebody else already had to make, edge cases somebody else already hit, vulnerabilities somebody else already discovered, and fixes somebody else already learned were necessary.

A mature framework is partly institutional memory encoded as software.

Take authentication. The happy path is not conceptually difficult:

User submits credentials
        ↓
Find account
        ↓
Check password
        ↓
Create session
        ↓
Return success

A relatively inexperienced developer can understand that flow and implement a version of it.

Production authentication is not hard because the happy path is hard. It is hard because of everything surrounding the happy path.

How should the password be stored? What happens after repeated failed attempts? Can an attacker determine whether a username exists by comparing error messages? What happens to existing sessions after a password change? How long should a reset token remain valid? What happens after it is used? Can it be replayed? What attributes belong on the session cookie?

The developer writing authentication for the first time does not necessarily know to ask any of that.

A mature framework often does.

That is a very different kind of value from saving keystrokes.

Abstractions Change Who Has to Think

Software has always progressed partly by taking things that required specialized knowledge and putting them behind abstractions.

Assembly gave me extraordinary control over what the processor did. It was also a tremendous pain. Higher-level languages let us express more sophisticated ideas without manually considering every instruction. C retained substantial control over memory and execution while being far more productive. Later languages and runtimes provided increasingly sophisticated abstractions for memory management, type safety, concurrency primitives, and networking. Libraries and frameworks moved the boundary again. Managed platforms moved it again.

None of those layers made the layer underneath disappear.

Your Python application still causes a processor to execute machine instructions. Your Django application still communicates over networks. Your application on a managed platform still runs on computers somewhere.

What the abstraction changes is who has to think about those things routinely.

Control and Responsibility Arrive Together

Developers sometimes discuss control as though it were an unqualified good.

C gives me more control over memory. Running directly on infrastructure gives me more control than a managed platform. Writing SQL gives me more control than an ORM. Building against browser automation primitives gives me more control than a higher-level testing abstraction.

All of those statements can be true.

But control has a twin that gets mentioned far less often: responsibility.

If you control memory allocation, you are responsible for memory allocation. If you control your infrastructure, you are responsible for configuring, securing, observing, updating, and troubleshooting it. If you control every selector in an end-to-end test suite, you own every selector when the application changes.

You could write your inventory API in C. Manage the networking, parse HTTP, handle allocation, implement routing, serialization, authentication, database connectivity, concurrency, and error handling yourself. You would have an enormous amount of control, and you would have volunteered for an enormous number of problems that Flask, FastAPI, Django, Rails, Spring, and others have spent years making uninteresting.

The trade is not:

abstraction versus control

It is closer to:

less control and less responsibility versus more control and more responsibility

Sometimes the additional control is worth the additional responsibility. Sometimes it is not.

flowchart LR
    A["Problem"] --> B{"Own the complexity?"}
    B -->|"Yes"| C["More Control"]
    C --> D["More Engineering Responsibility"]
    B -->|"No"| E["Use an Abstraction"]
    E --> F["Accept Its Opinions & Constraints"]
    D --> G["Build Your Differentiating Work"]
    F --> G

    classDef question fill:#FFFFFF,stroke:#166534,color:#14532D,stroke-width:2px;
    classDef control fill:#FEF2F2,stroke:#991B1B,color:#7F1D1D,stroke-width:2px;
    classDef abstract fill:#E8F3EE,stroke:#166534,color:#14532D,stroke-width:2px;
    classDef outcome fill:#F0FDF4,stroke:#5CA08A,color:#14532D,stroke-width:2px;

    class A,G outcome;
    class B question;
    class C,D control;
    class E,F abstract;

Using the abstraction does not make you less of an engineer. Building the lower layer yourself does not automatically make you a better one. The skill is recognizing which problems deserve your attention, while understanding what you surrendered to have the others solved for you.

Opinions Are Part of the Product

"Opinionated" sometimes gets used as a criticism.

It certainly can be one. If a framework's opinions conflict with your application's fundamental requirements, you will spend more time fighting it than benefiting from it.

But an opinion is also a decision you do not have to make. A framework with an established approach to authentication, migrations, forms, routing, validation, sessions, and project structure has removed that many questions from your team's agenda, and mature defaults usually carry years of accumulated experience with them.

The other side of the bargain is that somebody else has partially decided what your options look like.

Using MongoDB with Django was a long-running example. Django's data layer was built around assumptions that fit relational databases particularly well, and getting MongoDB underneath it was possible through various third-party approaches, though "interesting" would be a charitable description of that experience. You were making one architectural choice while using a framework whose opinions had been designed around another.

What happened next supports the argument better than the complaint did. MongoDB shipped an official Django backend in public preview in early 2025, and it now handles embedded models, queryable encryption, geospatial lookups, and most of what the third-party packages struggled with. The framework's opinions were not overturned. They were extended, by people willing to do the work of reconciling the document model with Django's assumptions.

That took years, and it is exactly the process this whole post is about. The accumulated knowledge is the product. It just accumulates slowly.

So before adopting any framework, do not look only at the complexity it removes. Ask what decisions it makes on your behalf, what assumptions are embedded in those decisions, and how painful things become when your application needs something outside them.

You can dislike the choices. You can replace some of them. You can decide the framework is wrong for you. What matters is understanding the bargain.

Every Platform Sells You Both

Managed platforms made this visible in a way frameworks alone did not.

Before them, deploying an application meant owning a considerable amount of infrastructure knowledge: somewhere to run it, a way to deploy it, process management, configuration, networking, logging, databases, scaling, and monitoring. Managed platforms did not make any of that cease to exist. They changed who had to own it.

What is easy to miss is that this was never a choice between vendors. It is a choice available inside every vendor. AWS will happily sell you App Runner, Elastic Beanstalk, Lambda, or Amplify, and it will just as happily sell you EC2 instances, a VPC, load balancers, autoscaling groups, and a pile of IAM policies to assemble yourself. Google Cloud offers Cloud Run and App Engine alongside Compute Engine and GKE. Azure has App Service and Container Apps on one side, virtual machines and AKS on the other.

Same provider. Same workload. Radically different amounts of responsibility.

The opinionated paths get you running quickly and constrain what you can do. The assembled paths let you build nearly anything and hand you an operational surface that keeps expanding for as long as the system exists. Most real architectures contain both, which is usually the right answer.

The constraint is real in either direction. If you need behavior outside the managed model, the abstraction becomes limiting, and there are plenty of workloads where owning the pieces makes more sense. That is not a failure of the abstraction. It is the trade the abstraction offered.

One asymmetry is worth pricing in advance: the managed path is cheap to enter and expensive to leave. Moving off it means rebuilding the machinery the platform was quietly providing, usually under time pressure, usually at the exact moment the constraint became intolerable. That is not an argument against starting there. It is an argument for knowing which constraint would force the move before you have to make it.

For most teams the question was never whether their engineers could build and operate infrastructure. It was whether infrastructure was what their customers were paying them to be good at.

Spend Your Complexity Budget Wisely

I think of this as a complexity budget.

Every team has finite attention. There are only so many engineers, so many hours, and so many systems a group can deeply understand and maintain. Complexity spends that budget.

Build your own authentication and you have spent some of it on authentication. Operate your own infrastructure and you have spent some of it on infrastructure. Build a custom persistence layer and you have spent some of it on persistence.

Any of those can be excellent investments when the capability differentiates your product or your requirements genuinely demand the control. Dan McKinley's "Choose Boring Technology" makes a neighboring argument with innovation tokens: you get about three, so spend them where they matter. The complexity budget is the same instinct pointed at what you build rather than what you adopt.

"We could build it ourselves" does not establish anything. Engineers can build lots of things.

The better question is:

Is this where we want to spend our complexity budget?

Learn What's Underneath Anyway

None of this argues against learning fundamentals. Quite the opposite.

Understanding HTTP makes you better at using a web framework. Understanding SQL makes you better at using an ORM. Understanding memory makes you better at diagnosing what a runtime is doing.

Every abstraction eventually leaks. When it does, knowing what is underneath tells you whether you are looking at a bug, a limitation, a bad assumption, or the consequence of a trade you made a year ago.

But there is a difference between understanding a layer and taking responsibility for operating it.

I do not need to fabricate a processor to understand how one works. I do not need to write an HTTP server in C to understand HTTP. I do not need to implement my own password hashing to understand why plaintext was a bad idea.

Sometimes understanding a problem thoroughly is precisely why you decide not to implement it yourself.

The Password Problem Never Really Went Away

Recently I had a coding agent implement password reset for a small application.

It built the feature in about five minutes. The email arrived. The link opened. The password changed. The user logged in with the new one.

Everything worked.

Except the reset link worked a second time.

The implementation satisfied the obvious behavior while missing the invariant underneath it: once the reset succeeds, the token has to become useless.

That felt familiar.

Forty years ago the question was:

Does the password let the right person log into the BBS?

Yes.

Then somebody asked:

Can the sysop read everyone's password?

Oh.

Years later:

Is the stored password protected?

Yes.

Can the stored representation be reversed or cheaply cracked?

Oh.

And now:

Does the password reset feature work?

Yes.

Can I reuse the token?

Oh.

The technologies change. The pattern does not. We implement the requirements we know about, and experience introduces us to the ones we did not.

That is why mature abstractions matter. They carry some of that experience forward so the next developer inherits the lesson without personally reliving it. Somebody already hit the edge case. Somebody already found the vulnerability. Somebody already spent three days on the concurrency bug that only appears on Tuesdays.

Which leaves an open question I do not think we have answered yet.

A mature framework carries its institutional memory in its decisions. Sometimes the reasons stay attached through issues, commits, documentation, and design discussions. Often they do not, and only the resulting constraint survives. Either way, somebody encountered the problem and changed the system because of it.

That is the part worth noticing. The single-use token check runs whether or not anyone remembers why it was added. The lesson is enforced rather than remembered.

A model trained on a very large corpus of code has absorbed something that resembles institutional memory. But it learned from artifacts produced after those decisions were made, rather than from the decisions themselves. It can reproduce what surviving code looks like without inheriting anything that enforces why one implementation survived and another did not.

Which might explain why my agent wrote a flawless happy path and dropped the invariant.

Happy paths are abundant. Invariants live in the decisions.

The Hidden Taxes of Prompt-Only AI

Ken W Alger — Tue, 15 Sep 2026 14:03:00 +0000

Part 8 of the Building the AI Memory Stack series

Over the past seven articles we've built an architecture that treats memory as infrastructure rather than as an oversized prompt. We've separated execution from assembly, preservation from explanation, trust from proof, and finally showed how verified knowledge returns to active reasoning through Context Hydration.

Now it's time to ask a different question.

What does all of that cost?

Every AI system pays for memory. The only question is where.

Many systems choose to pay almost every cost inside the prompt itself. As context windows grow larger, it becomes tempting to treat them as an infinitely expandable memory system. If the model forgets something, add more documents. If retrieval misses context, increase the top-k value. If the answer is incomplete, make the prompt longer.

That approach works surprisingly well, until it doesn't.

The cost isn't limited to API pricing. Large prompts consume attention, increase latency, complicate orchestration, and force the model to separate important information from noise. The result is an architectural bill that grows long before the invoice from your model provider does.

Capacity Is Not Communication

One of the recurring themes throughout this series has been that storage and communication are different problems.

A library may contain every book ever written, but that doesn't mean every book belongs on your desk while solving today's problem. Likewise, Durable Memory can preserve years of organizational knowledge without requiring every byte of it to enter today's Context Window.

The purpose of architecture is deciding what should move, when it should move, and what it costs to move it.

Introducing the Tax Model

The Sovereign Systems Specification describes these recurring costs as architectural taxes. They are not bugs. They are the predictable costs of moving, storing, validating, retrieving, and communicating information through an AI system.

Some taxes are unavoidable.

Others are self-inflicted.

Good architecture minimizes the second category.

The taxes that bear most directly on memory are these.

Prose Tax

Every explanation has a cost.

Humans naturally communicate in paragraphs. Models consume tokens. The more words required to express an idea, the more attention the model must allocate before it can begin reasoning.

High-information-density representations, such as structured records, schemas, identifiers, and references, often communicate the same meaning with a fraction of the prompt budget.

Context Tax

Every additional token competes for attention.

Context windows have grown dramatically, but attention remains finite. As more information enters the prompt, genuinely important information must compete with increasingly irrelevant material.

Bigger windows increase capacity.

They do not guarantee better focus.

Retrieval Tax

Searching for information is not free.

Embedding generation, vector searches, re-ranking, filtering, serialization, and prompt assembly all consume compute and latency before the model has produced a single token of useful work.

As argued earlier in this series, retrieval should support memory, not replace it.

Observer's Tax

Every measurement has a cost.

Telemetry, debugging information, traces, evaluation artifacts, and compliance records are essential for production systems. Left unchecked, however, they begin competing with operational workloads for compute, storage, and engineering attention.

Observability is infrastructure.

It should not become interference.

Ingestion Tax

The cheapest place to improve information quality is before information enters the system.

Poorly structured data generates downstream costs forever. Duplicate records, inconsistent schemas, missing provenance, and unverifiable observations all create future work for retrieval pipelines, prompt assembly, and reasoning itself.

Every bad write compounds.

Every good write pays dividends.

Fiscal Architecture

Viewed individually, these taxes seem manageable.

Viewed together, they become an architectural discipline.

None of these taxes exist in isolation. Attempts to reduce one often increase another. Expanding a prompt may reduce retrieval work while increasing Context Tax. Adding more telemetry may improve observability while increasing Observer's Tax. The goal isn't minimizing a single tax; it's balancing the entire system.

Tax	What it charges for	Lowered by
Prose Tax	Meaning expressed in more tokens than it needs	Structured records over paragraphs
Context Tax	Irrelevant tokens competing for finite attention	Hydrating only what the task needs
Retrieval Tax	Search, embedding, and re-ranking before any output	Higher memory quality, less searching
Observer's Tax	Telemetry and traces competing with real work	Bounded, purposeful observability
Ingestion Tax	Poor structure and missing provenance at the write	Verified, structured writes

Organizations often spend months optimizing prompts while ignoring the systems that create those prompts. Yet the largest savings usually come from improving memory quality, reducing unnecessary movement, and preserving information in forms that are inexpensive to hydrate later.

Traditional software architecture optimizes CPU, memory, network bandwidth, and storage.

AI architecture adds another economic dimension: attention.

Every architectural decision ultimately affects how much attention the system spends producing useful reasoning.

In other words, the cheapest token is often the one that never needed to exist.

The Goal Isn't Zero Tax

Every system pays taxes.

A trustworthy system willingly pays some of them.

Hashes must be computed. Receipts must be signed. Memory must be verified before it is restored. Good engineering accepts these costs because they purchase integrity, explainability, and confidence.

The goal is not eliminating cost.

The goal is paying the right costs in the right places.

Looking Ahead

The final article brings everything together.

We'll revisit the AI Memory Stack from the perspective of runtime execution rather than teaching order, showing how data actually flows through the architecture and mapping each responsibility to the Sovereign SDK. By the end, the stack should feel less like a collection of concepts and more like a blueprint that can be implemented today.

Living a Colorful Life in a Black-and-White ATS World

Ken W Alger — Mon, 14 Sep 2026 13:48:00 +0000

A career has edges. The schema only stores nodes.

I spent years in commercial kitchens and over a decade running a one-man construction business before I ever shipped software professionally. Here is what those years look like inside an applicant tracking system:

Sous Chef, Illahe Hills Country Club, 1996-1997
Owner, Alger Construction, 2006-2018

Two rows. Six fields. Everything that made those years worth putting on a resume in the first place lives in the space between them, and there is no field for the space between them.

That is not a bug in any particular vendor's product. It is what happens when a career gets stored.

Compression Is the Point, and Compression Has a Cost

A resume is already a lossy representation of a working life. An applicant tracking system compresses it again into titles, employers, dates, skills, and years of experience. Recruiter searches narrow it further. Screening criteria narrow it again. By the time a hiring manager sees a candidate, a great deal of what made that person worth meeting has been discarded by systems doing exactly what they were built to do.

Hiring at scale requires structure. Nobody sensible is arguing otherwise.

But compression is only lossless when the thing being compressed matches the schema. Software engineer becomes senior software engineer becomes staff software engineer. The titles line up. The keywords line up. The progression survives the trip through the pipeline nearly intact.

For a career that moved sideways, the same pipeline behaves very differently. It preserves the least interesting facts and drops the reason those facts belong on the same page.

The Resume Contains the Nodes. Something Has to Explain the Edges.

Running a construction business teaches you schedules, budgets, vendors, dependencies, unhappy customers, and what it costs to discover a problem after the wall is closed. Working a station on a busy line teaches you sequencing, preparation, and how to communicate when six things are failing at once and none of them are your fault. Managing a distributed technical team a decade later draws on both, whether or not the job description has a checkbox for it.

Systems fail. Priorities collide. Resources are finite. People misunderstand each other. Plans meet reality. Learning to operate under those conditions is transferable, and it is the actual content of a nonlinear career.

A person reading a resume can sometimes reconstruct those connections. A parser has a harder problem, because almost everything it has been given is categorical. It is very good at representing what fits in a field. It has nowhere to put "running a small business taught me something about operational risk that later made me better at managing engineers."

The information exists. The schema has no column for it.

This is why the quiet disappearance of the cover letter is more consequential than it looks. I understand why nobody misses them. Most were three paragraphs about being passionate about synergizing solutions in a fast-paced environment, and they earned their reputation. But the format was carrying a load that nothing replaced. The more nonlinear the candidate, the more of their value lives in relational information, and the application form keeps getting narrower precisely where that information needs to go.

We tell people to bring their whole selves to work while steadily reducing the bandwidth available to transmit one through the front door.

The Strongest Objection Is Not Efficiency

The honest counterargument to everything above is not that narrative is slow to read. It is that narrative is where bias lives.

Structured screening was partly a correction. Unstructured hiring, the kind that runs on interesting backgrounds and good conversations and a hiring manager's instinct about fit, has a well documented tendency to favor candidates who resemble the person doing the evaluating. "This person's unusual path is fascinating" has historically meant "this person reminds me of me." Fields, rubrics, and consistent criteria were a response to a real failure, not an accident of software convenience.

So the argument cannot be that we should bring back the cover letter and read it with an open heart. That is a request to reopen a door that was closed for a reason.

The argument is narrower, and I think it survives the objection: the correction discarded a category of information instead of evaluating it consistently. Those are different problems with different fixes. Consistency is achievable for prose. Ask every candidate the same question. Score the answers against the same rubric. Read them at the same stage. That is structured data that happens to arrive as sentences.

What we built instead was a process that solved the bias problem by deleting the input.

The Keyword Arms Race Is a Symptom of the Deletion

The predictable response has been optimization on both sides. Candidates tailor resumes to postings. Tools score keyword alignment. Generative models rewrite bullets in the vocabulary of the job description, while recruiters deploy increasingly sophisticated matching and ranking on the other end.

None of that is unreasonable in isolation. If a company says "developer enablement" and my resume says "developer education," making that equivalence explicit helps humans and machines alike.

Taken far enough, though, the process gets strange. One model rewrites a person's career into the vocabulary most likely to satisfy another model deciding whether a human being should ever see it. We have built a translation layer between two parties who could have had a conversation.

And the translation runs in one direction only. Optimizing for machine legibility strips out exactly the information companies claim to be looking for. Adaptability is messy. Cross-disciplinary experience is messy. Pivots are messy. That messiness is usually where the signal is.

A Hiring Process Is a Statement of What an Organization Preserves

It is easy to blame the ATS, because it is the visible machinery. It is also the least interesting part of the story.

Someone decides which fields matter. Someone writes the screening questions. Someone marks a qualification as required rather than preferred. Someone chooses how recruiters query the pool, and whether a hiring manager sees fifty candidates, ten, or only the five that most closely resemble the profile used to write the posting. And someone decides you will never be told which of those things happened to you.

The resulting process is not neutral. It is a record of what an organization decided was worth keeping.

A process that preserves titles, years, and exact skills while discarding explanation will reliably favor careers legible through titles, years, and exact skills. A process that rewards similarity to a predefined profile will filter out candidates whose value comes from unusual combinations, because unusual combinations are by definition dissimilar.

For plenty of roles that is fine. Nobody wants an airline hiring pilots because the career story was compelling.

It is harder to defend when the same organization says it is looking for adaptable leaders, systems thinkers, creative problem solvers, and people who challenge established assumptions. Those are all contextual qualities. Context is the first thing lossy compression throws away.

We Do Not Need Better Resume Optimizers

I have not solved hiring, and candidates still have to operate inside the system that exists. Make transferable skills explicit. Describe outcomes in the language of the role. Find a human being when you can. A nonlinear career does not become legible because we insist it deserves to be.

But another generation of tools that help candidates compress themselves more efficiently is not a fix. It is better compliance with the thing causing the problem.

The smaller fix is available today and costs almost nothing. One field, asked of every applicant, scored the same way: what connects these experiences, and what did you carry from one to the next? Two hundred words. Read before the rejection, not after the offer. It is consistent, it is auditable, and it gives relational information somewhere to exist inside a structured process rather than outside it.

If an organization genuinely believes that unconventional backgrounds and adaptable thinkers create value, its hiring process needs a place to put them. Not in the culture page. In the schema, where decisions actually get made.

Otherwise, "bring your whole self to work" carries an undocumented prerequisite:

First, make sure your whole self fits in the fields.

P.S. I have also prepared my curriculum vitae in Latin. Thirty-five years of experience, zero recoverable keywords, and one very specific classics-major-turned-recruiter out there who will open it and say: hic est candidatus quem exspectabam.

The Contract Discovery Bottleneck

Ken W Alger — Thu, 10 Sep 2026 16:44:00 +0000

AI can generate the code. We can verify the behavior. But who decides
what correct means?

I wrote recently about a coding agent that built me a password reset
flow with a reset link that worked more than once.

The bug survived because nobody had written down that a reset link
should be single use. It was obvious right up until it wasn't.

My argument was that as AI makes implementation cheaper, verification
becomes the bottleneck. The feature request said "build password reset."
The agent built password reset. The happy path worked. The tests passed.
The implementation looked finished.

What nobody had asked was whether the same reset link should work twice.

So I added an independently written behavioral specification. The agent
implemented against it. The verifier rejected the reusable token. The
agent fixed the implementation. The verifier passed it.

That seemed like a useful pattern:

Then I published the article, and the comments started finding things my
specification didn't say. That exposed a harder problem.

The specification wasn't finished either

One reader asked what would happen if two password reset requests using
the same token arrived at the same time.

I hadn't tested that. My test covered sequential reuse:

But concurrent reuse is different:

Both requests check the token while it is still unused. Both proceed.
If validation and consumption are not a single atomic operation, "single
use" can still produce two successful resets.

The original invariant was incomplete.

That doesn't make the specification useless. It makes the specification
provisional.

The interesting part is where the new knowledge goes.

Once somebody discovers that "single use" also means competing attempts
cannot both succeed, that should stop being knowledge held by the person
who noticed it. It belongs in the durable definition of correct
behavior.

The specification changes.

Which means the loop is really closer to this:

That is messier than the first diagram.

It is also much closer to engineering.

Separate tests can share the same mistake

Another reader described an integration builder where an agent wrote
both a connector and the tests for that connector.

Everything passed.

Both were wrong.

The connector and its tests encoded the same incorrect assumption about
OAuth token refresh. The mistake only surfaced when a customer's token
expired during a live session.

The implementation and test suite were separate artifacts. They were not
independent in the way that mattered.

They shared an assumption.

That distinction matters because "independent verification" can sound
like an organizational property:

different file
different test suite
different agent
different step in the pipeline

None of those necessarily provides independence.

If the implementation and verifier derive their definition of correct
behavior from the same incomplete prompt, they can agree perfectly and
still be wrong.

The student is no longer literally grading the same exam.

Two students have simply studied from the same incorrect answer key.

Generating more tests doesn't discover the missing rule

Another commenter asked whether property-based testing or giving an
agent an adversarial security persona might do a better job uncovering
these unstated constraints.

I think both are interesting, but they expose the same boundary.
Property-based testing can explore a stated invariant extremely well.

If I tell a framework:

A successfully consumed reset token must never produce another successful reset.

it can generate combinations and sequences I would never think to
hand-author.

But it cannot tell me that single use was a requirement if nobody
expressed it.

An adversarial agent has a similar problem. Asking a model to "try to
break this" may produce better tests than asking it to "write tests for
this feature." But if the adversary shares the same context, model
assumptions, and incomplete understanding of the requirement, how
independent is it really?

The question starts shifting from who writes the tests? to a more
difficult one: where does the definition of correct behavior come
from?

The verifier can be wrong too

One of the most interesting examples in the discussion came from a
verification harness rather than generated application code.

A capability test timed out.

The harness recorded the result as a failure.

But a timeout did not establish that the capability failed. It
established that the harness did not obtain a result within the allotted
time.

Those are different claims.

FAILED

and

NOT TESTED

are not interchangeable.

The verifier had turned an observation failure into an assertion about
capability.

That's a useful warning for any architecture built around deterministic
verification: deterministic does not mean correct.

A verifier can enforce the wrong invariant with absolute consistency.

So can a specification.

The goal isn't to replace an unreliable agent with an infallible
verifier. There is no infallible verifier.

The goal is to make the definition of correctness explicit enough that
it can be inspected, challenged, tested, and revised independently of
the implementation.

So who writes the contract?

This was the question that pushed the argument furthest for me.

If humans have to write complete behavioral specifications before agents
can implement anything, haven't we simply moved the bottleneck back to
humans?

Probably.

And worse, the concurrency example demonstrates that humans don't
necessarily know the complete specification beforehand either.

So "humans write the contract" isn't much of an answer.

An agent could propose it.

That sounds circular at first. If the agent proposes the implementation
and proposes the contract, aren't we back to the student grading the
exam?

Only if proposing the contract and accepting the contract are the same
operation.

They don't have to be.

An agent might generate a candidate operating contract:

reset token:
  may be used once
  competing attempts cannot both succeed
  expires after N minutes
  cannot authorize a different account

A human, another system, or some combination can then challenge that
much smaller artifact.

The question being reviewed becomes:

Is this an adequate definition of correct behavior?

rather than:

Is this entire implementation correct?

That doesn't solve the trust problem, but it reduces its surface area.
Reviewing four lines is a different activity than reviewing four hundred.
One is a conversation about intent. The other is an audit.

But this runs straight back into the answer key problem.

If the same model that will implement the feature also proposes the
contract, they share assumptions. An agent that doesn't know single use
matters won't propose single use as an invariant. It will produce a
confident, well-formatted contract with the same hole in it, and now the
hole has been written down and approved.

So accepting a contract has to do more than approve it. It has to
introduce something the proposing agent didn't have.

That might be a person who has debugged this class of bug before. It
might be a genuinely different model, though I'm unsure how much
independence that buys. It might be a checklist derived from past
incidents, which is really institutional memory in a form an agent can
read. For a reset token, somebody's list somewhere already says: single
use, expiry, no account substitution, no concurrent success, session
invalidation.

The value comes from the independence of the source, not from the
ceremony of the review.

That may be a more tractable thing to build tooling around than
verification itself.

Maybe verification isn't the deepest bottleneck

This is where the comments changed my framing.

I started with:

I'm less sure that's where it stops.

Once implementation is cheap and verification is increasingly
automatable, the harder problem may become discovering the invariants
worth verifying.

Call it contract discovery.

The requirement says:

Reset my password.

Somebody has to discover:

The link works once.

Then:

Two concurrent attempts cannot both succeed.

Then perhaps:

The token cannot authorize a different account. A token issued before another successful reset may no longer be valid. A reset invalidates existing sessions.

Some of those are product decisions. Some are security properties. Some
are implementation-independent behavioral invariants. Some may not apply
at all.

The difficult work is deciding which ones belong to the definition of
correct.

AI can help propose them.

Property-based testing can explore them.

Deterministic systems can enforce them.

Production incidents will unfortunately discover some of them for us.

But none of those eliminates the need to decide which claims actually
define correctness.

This gets harder when agents start acting

There is another reason I think this matters beyond generated code:
agents don't just write things anymore. They call things.

An agent calls an API. The response is 200. The agent moves on.

But a 200 says the request was processed. It doesn't say the
constraint the agent's plan depended on was enforced. Maybe the call
timed out after the write succeeded, so the retry performed the effect
twice. Maybe the operation was legitimate the first time and should have
been rejected the second.

That second one should look familiar. It's the reset link, one layer
out.

A bad implementation leaves an artifact somebody can inspect later.

A bad tool call already happened.

It sent the email. Charged the card. Revoked the access. Posted the
message.

There is no diff to read.

This is where the contract-discovery problem becomes more consequential.
The system needs some definition of what the agent is permitted to cause
and what evidence would establish that the intended effect actually
happened.

I don't think I have the architecture for that yet, but one boundary is
becoming clearer:

The specification can be agent-readable without being agent-owned.

The agent should be able to see the invariant. Withholding the
requirement only makes the work guesswork.

But the agent shouldn't be able to quietly redefine the invariant when
satisfying it becomes inconvenient.

Whatever accepts, stores, and evaluates the contract needs some
independence from the reasoning that produced the implementation or
action.

Where that boundary belongs remains a harder question.

The specification is durable because it can change

Calling the specification a durable artifact can sound like calling it
an immutable one.

I don't mean that.

A durable specification should change when we learn something about what
correct behavior actually requires.

What makes it durable is that the knowledge survives the implementation
that taught us the lesson.

The reset implementation may be rewritten next month.

The framework may change.

The agent may change.

The database may change.

But once we've established that two competing reset attempts cannot both
succeed, that invariant should survive all of them.

The same applies to an integration. Once a production failure teaches us
what token refresh must guarantee, that knowledge should not remain
attached to the incident report or the engineer who debugged it.

It should become part of what "correct connector" means.

The implementation may be disposable. The accumulated definition of
correctness is not.

I still don't think this is solved

There are plenty of uncomfortable questions left.

How independent does a verifier have to be?

Can two agents using different prompts but the same underlying model
provide meaningful independence?

Who accepts an agent-proposed contract?

How do you distinguish a genuine product invariant from an
implementation detail that shouldn't survive the current code?

What happens when two valid invariants conflict?

How do contracts evolve without quietly weakening previous guarantees?

And how do we verify effects in external systems where state is delayed,
partially observable, or distributed?

I don't have good answers to all of those. That's partly why I don't
think the answer is simply "write better tests." The tests are
downstream of the harder question.

Write down what you mean by correct

The original password-reset bug happened because a rule existed in
someone's head and nowhere else.

The comments on that experiment showed the next problem: writing down
one rule doesn't mean you've found all the others.

That's fine. The specification doesn't have to arrive complete. It has
to provide somewhere for discovered invariants to go, and that somewhere
has to be a place with a history: versioned, reviewable, and attached to
the behavior rather than to the incident that revealed it.

Maybe an agent proposes them. Maybe a human notices them. Maybe
property-based testing exposes them. Maybe an independent reviewer asks
the annoying question nobody else asked. And sometimes production will
teach us the expensive way.

The important part is that each discovery makes the durable definition
of correct behavior better.

AI is making it remarkably cheap to turn an instruction into working
code.

Verification asks whether the code did what we said. Contract discovery
asks whether we said enough. I'm starting to think that's the harder
problem.

Why User Provisioning Matters for Enterprise AI

Ken W Alger — Thu, 10 Sep 2026 12:44:00 +0000

Offboarding a user is not enough when the credentials they leave behind can still spend money and invoke tools.

An orphaned SSO account is inert. Nobody logs in, nobody clicks anything, and eventually someone notices it during an access review.

An orphaned AI credential is different.

A virtual key can still have a budget, provider and model access, and perhaps permission to invoke MCP tools against other systems. The person it belonged to may have left six months ago while the credential continues doing exactly what it was authorized to do, with nobody attached to it and nobody wondering why its usage still appears on the bill.

That is why user provisioning for enterprise AI is not simply another implementation of the joiner, mover, leaver problem IAM teams have managed for decades. The identity lifecycle is familiar. The consequences of getting it wrong are not.

How Should Enterprise AI Provision New Users?

The joiner case is the easy one, which is precisely why it should not get much attention.

The previous post looked at how roles and access profiles connect human authorization to runtime policy. With Bifrost user provisioning, an identity-provider group can map a user to a role, the role supplies its default access profile, and that profile issues governed access when the user arrives. Providers, models, budgets, rate limits, and tool access have already been decided. The new employee inherits policy instead of inventing it.

That is the ideal state: nobody files a ticket for an API key or remembers which model Marketing may use. Organizational intent was encoded before the employee arrived, so provisioning mechanically applies a decision already made.

Joiners are the flattering part of lifecycle management. Movers are where exceptions accumulate.

Why Are Role Changes Dangerous for Enterprise AI Access?

Imagine the acquisition from the first post six months later. One engineer initially joins the migration team, later moves to the platform group, and eventually transfers into an internal agent project.

Each move is legitimate. Each requires new access. The dangerous question is what happened to the old access.

Role-based provisioning can replace assignments that originated from a role default. But a profile assigned directly to a user represents an explicit exception, so it survives the role change. The system can distinguish a role-derived assignment from a direct assignment; it cannot determine whether the reason behind that exception still exists.

Combine that with the role behavior from the previous post: when someone holds multiple roles, permissions resolve upward rather than to their intersection. The result is a familiar enterprise failure with an AI-specific blast radius. People gain access at every transition and shed it at none.

Three teams into someone's tenure, their effective authorization may resemble the union of all three jobs they have held. That can mean access to models approved for a previous team, a larger budget, different logs, or tools their current role has no reason to invoke.

Movers therefore need more than synchronization. They need reconciliation. Bifrost's user provisioning model reflects role and team changes when users are reconciled against the identity provider, but lifecycle management still has to account for exceptions outside those inherited defaults. Automation is good at applying known rules and poor at deciding whether an exception created fourteen months ago still has a business justification.

The question is not simply, "What access should this person's new role add?" It is also, "What access no longer has a reason to exist?" Who owns this key, why does this direct assignment still stand, and would the organization grant the same access today if asked fresh? Those are governance questions rather than provisioning mechanics, and no synchronization job will answer them.

In practice, reconciliation is a scheduled comparison rather than an event handler. Once a quarter, list every access profile assignment that did not come from a role default, along with who created it, when, and against which stated justification. Anything without a justification on record is the finding. Anything with one is a question for the person who owns that team, and the question is not whether the access is being used but whether it would be granted again today.

That distinction matters because usage is a misleading signal here. An unused grant is not evidence of safety; it is a capability sitting idle until an incident or an automation reaches for it. A budget that has never been spent still authorizes the spending.

What Should Happen to AI Access When a User Leaves?

Leavers expose the difference between identity management and AI lifecycle management most clearly.

The obvious response to a departing employee is deletion: remove the account, revoke credentials, clean up the objects, and leave the system tidy. The second post in this series discussed why an expired virtual key should instead fail closed without disappearing. During offboarding, that distinction becomes critical.

By the time someone leaves, the system may hold an identity, roles, access-profile assignments, a virtual key, budget counters, model permissions, rate limits, tool grants, and a record of requests made under that authority. Some must stop working immediately. Some must survive.

Event	Identity	Role	Access profile	Virtual key	MCP credentials	Record
Joins	Created on first login	From IdP group	Role default applies	Issued automatically	Authorized per user	Created
Moves	Unchanged	Replaced	Role defaults swap; direct assignments persist	Reissued	Persist separately	Retained
Leaves	Deactivated	Removed	Copy retained	Fails closed	Revoked separately	Preserved

The last row is the architecture: fails closed, record preserved.

Suppose Security investigates an event six months later. The useful questions are historical: which models could this person reach, what budget applied, did they have MCP tool access, and was that access inherited or directly assigned?

Deleting lifecycle objects because the employee left makes those questions harder precisely when their answers matter most. This is a write-side custody problem as much as an identity problem. The system should preserve enough state to explain what happened rather than reconstructing it later from an IdP, billing export, deleted credential, and today's configuration.

Offboarding therefore has two obligations that pull against each other: end the authority, and preserve the evidence. A leaver should become incapable of causing new actions without becoming invisible to the historical record.

That distinction matters most with tools, and there is a second object hiding here. Where an MCP server uses per-user OAuth, the departing employee holds credentials that are separate from their virtual key and have to be revoked separately. Bifrost exposes a sessions view for inspecting and revoking those per-user MCP credentials, which is easy to miss in an offboarding checklist designed before agentic AI entered the enterprise stack.

It is worth being precise about why that is three operations rather than one, because they fail independently.

Deactivating the identity stops someone logging in. It does not reach anything already issued under that identity. An offboarding process that ends here has closed the front door and left every key that was cut from it in circulation.

Invalidating the virtual key stops the requests. This is the operation most teams think of as revocation, and it is the one that actually severs runtime authority. It should fail closed while remaining inspectable, for the reasons above.

Revoking per-user MCP credentials is the one most likely to be missed, because the credential is not entirely yours. Per-user OAuth means the employee authorized an external service directly, and the resulting grant lives at that service. Invalidating their virtual key stops requests flowing through the gateway. It does not, on its own, tell the external provider that the authorization behind those requests should end. That grant has to be revoked where it lives, which is why a sessions view exists as a separate surface rather than as a checkbox on the user record.

The practical consequence is that "we deactivated their account" answers only the first of three questions, and the third one is the one nobody thinks to ask.

The exposure is conditional rather than automatic, and the condition is the interesting part. By default Bifrost does not execute tool calls on its own; a model returns suggestions and the application has to call the execution endpoint explicitly. But a workload running in agent mode with auto-approval configured has no such pause. A forgotten SaaS login is dormant until somebody uses it. An orphaned key attached to an autonomous workload is already being used, and the human whose authority justified those tool grants left two quarters ago.

An orphaned SSO account is inert.

An orphaned virtual key is an actor.

And there is a question sitting underneath all of this that the series has not answered. The record survives the person, but six months later, what does that record actually prove, and who should be allowed to read it? Removing access is only half of offboarding. The other half is being able to explain what happened while that access still existed.

One practical distinction before designing around any of this. Bifrost itself is open source, including the gateway and the core governance around virtual keys, budgets, routing, and MCP tool filtering. The user provisioning and identity lifecycle discussed here are Enterprise capabilities, and the documentation is the better place to check that boundary than a blog post.

What Happens to AI Credentials That Never Had a User?

There is one uncomfortable limit to this model: lifecycle management assumes a lifecycle.

None of it helps with an identity the system never knew about. A contractor handed a key directly. A shared service account nobody quite owns. A credential minted for a pipeline in 2024 by someone who has since left. These may be the most consequential actors in the environment, because they run continuously, spend consistently, and often hold broad permissions on the theory that automation is inconvenient when it fails. Unlike a person, they never transfer teams and never trigger an offboarding workflow. You cannot deprovision an identity that never existed.

The only workable answer is to give them the lifecycle events they will never generate on their own. Every non-human credential needs a named human owner, not a team alias, and a review date on the calendar. The owner is who gets asked when the credential appears in an incident. The review date is the substitute for the HR event that will never arrive. Expiry helps here more than it does for people: a workload credential that has to be renewed annually forces someone to state, once a year, that the thing still needs to exist. Most of the credentials that worry security teams would not survive that question.

That leaves enterprise AI with a harder question than joiners, movers, and leavers: how do you govern actors that were never people in the first place? An agent does not join a team, does not sit in a reorganization, and does not have a last day. It has an owner who may or may not remember creating it, a budget nobody reviews, and a set of tool grants that made sense on the afternoon they were issued.

That is where the lifecycle problem stops being about users and starts being about workloads.

This article was commissioned by the Bifrost team. The link to the Sovereign Systems Specification points to my own work. The architectural perspective and conclusions expressed here are my own.