Agent-written docs need a paper trail, not a confidence score

The Open Knowledge Format moved to v0.2, and the release is entirely about a bookkeeping problem: recording who wrote a document and whether anyone ever checked it ^[6]. That matters because a growing share of the markdown in working repos, CLAUDE.md files, memory directories, runbooks, notes on what an agent learned about a codebase, was written by something other than a person ^[1].

The failure described in the post is not agents writing wrong things. It is that six weeks later the file does not say who wrote it, whether anyone verified it, or whether it is still supposed to be true ^[2]. An agent then reads its own unverified guess as ground truth and builds on top of it, so the next session inherits the error with more confidence than the first one had ^[3].

The obvious fix is the wrong one. A stored field such as confidence: 0.87 is an opinion that does not say whose, is not portable between readers, and stays put when the content underneath it is edited ^[4]. The author's description is fair: a cache with no invalidation strategy ^[4].

The v0.2 alternative is to put only observable events in frontmatter and let every consumer compute the judgment at read time ^[6]. A concept records that it was generated by doc_agent/1.0 at a timestamp, verified by human:dana at a later timestamp, a stale_after date, and the sources it came from ^[7]. Writer and checker are deliberately separate fields, because an agent generating and a human confirming is the normal case rather than the exception ^[9]. Actor strings carry a machine-parseable prefix: human: for people, process:finance-nightly for automation, doc_agent/1.0 for agents and tools ^[8].

The derivation is four rules applied on read: no verified key means unverified; verification by non-human actors only means machine-confirmed; any human: verifier means human-reviewed; and today past stale_after means stale whatever the tier ^[10]. Because generated.at and the latest verified.at are both plain timestamps, a reader can also see the case a stored score hides, content edited after its last review ^[11]. The precedent cited is Git, which does not store the fact that a branch is merged and derives it from the commit graph instead ^[12].

The sharp operational edge is spelling. humans:dana is not a human: actor, so one stray letter silently downgrades a real human review to machine-confirmed, which the author argues belongs to a linter rather than a code reviewer ^[13]. Their toolchain, okf-skills, is Claude Code-native: skills to produce, maintain, validate and visualise bundles, a GitHub Action that gates them in CI with no agent involved, a renderer that computes trust tier and staleness badges at render time and stores neither, and a validator that warns on actor near-misses ^[14][15].

Two caveats sit on the claim. This is a single post from the people who maintain the tooling, and OKF is described there as a vendor-neutral spec announced by Google Cloud in June 2026 ^[5][14]. The same authors decline to claim bundles make agents cheaper: their benchmark found 8 points more claim coverage on "why" questions and no token savings, and they then deleted the benchmark ^[17].

In the sample frontmatter, human verification lands 5 days and 23 hours after generation, and stale_after sits 95 days after that check ^[1][2]. That is the part teams will actually have to run: the tier is free to compute, but somebody has to keep signing the reviews. Watch whether anything outside okf-skills implements the four rules, whether stale_after gets set from a real review cadence or picked to be comfortably distant, and whether actor-prefix linting moves into the spec's own validation rather than one vendor's action ^[10][15].