Genome turns a company's experience into processes it can reuse and improve. It assembles the best known way to run a project, tests that against the real outcome, and — with a person's approval — improves it before the next time.
The next decision arrives and the organization solves a problem it has already solved, because nothing connected the two. We think this happens more often than teams notice — how often, and where it costs something, is what we're testing.
Note the direction: evidence went up and confidence went down. More evidence lowers confidence when the new evidence contradicts the block. A count that only ever grows is a library, not a learning system.
The first half — context, selection, process — is where the organization stops starting from zero. The second half is where it stops repeating itself.
The point is not the record. It is that the next similar project should be faster, better, and less dependent on who happens to remember.
Two halves of one question. Project context defines the assignment: the goal, the reasons, who it's for, the constraints, the definition of done. Genome defines the organization's response: which blocks apply, what risks are already known, what to check, and what similar projects taught us.
Genome never silently rewrites how a company works. It proposes a change, shows the evidence behind it and what it would cost, and asks an accountable person to approve. Nothing enters the knowledge base any other way.
A block is a piece of real work, not a document: a decision rule, a workflow, a gate, a template, a definition of done. Genome picks the blocks that apply to a project and then tracks how each one performed.
The signal in a brief or a conversation that makes this block the right one here.
The conditions under which it makes things worse — stated as explicitly as the trigger.
The inputs required before it can run at all.
The artifact or decision that comes out the other side.
The observable result that separates "we did it" from "it worked".
The projects and evidence behind it, with a confidence level and a date.
A real block, unedited
confidence: value: emerging evidence_strength: n: 23 projects: 16 independent_sources: 17 last_confirmed: 2026-08-08 recommendation: use-with-care
A real engagement, not an illustration. Every line below is recorded in the system and can be traced back to the file it came from.
The correction was concrete. One block said a URL inventory was complete once the site had been crawled. This project passed that gate — and still needed 125 more redirects afterwards. The block now requires four sources instead of one: crawl, CMS sitemap, Search Console and archived pages.
The blind spot mattered more. The organization spent a large part of the project building something no block had predicted, even though the signal was present on day one. That gap became a new block — recorded as a hypothesis, not as knowledge.
A block doesn't become trusted because someone wrote it down. The scale runs hypothesis → emerging → validated, and reaching the top costs three independent pieces of evidence from two or more projects, one of them a measurement or a settled outcome. There is deliberately no status called "proven" — proof suggests a closed truth, and confidence here decays unless something keeps confirming it. A block can, however, end up disproven: the only kind of certainty on offer.
A block reaches validated only with three independent pieces of evidence from at least two projects, one of them a measurement or a settled outcome. Narrative alone never counts.
Answers: what do we know?
Answers: how should we run the next one?
One column per mechanism, one layer per version of its card. The top layer is what we hold now. Everything under it was replaced — and kept.
A knowledge base can be out of date. It cannot tell you it was wrong, because it overwrites. Here the previous version stays, which is the only reason this number can exist at all.
And the ways it turned out to be wrong
Not "incomplete". Specific: a card that claimed too much, one that fired on the wrong signal, one that missed a way the mechanism breaks.
23 mechanisms down the side, 33 projects across. A square exists only where a project produced evidence about a mechanism — 137 of 759 possible pairs.
A knowledge base would show this as a full grid, because everything is "known". Here a square has to be earned by a project, and the emptiness is information: it is the map of what we have not established yet.
It also explains the zero. The widest row has been tested across sixteen projects and still isn't validated — narrative evidence alone doesn't get a mechanism there.
It runs inside r352 on real client projects across 50 recorded engagements, before we decide how much of it should exist outside. Of 25 mechanisms, 23 are still emerging and 2 are hypothesis. None has reached validated.
That's not a gap in the system. That's the threshold doing its job.
Designed to, not measured. We have no numbers on any of these yet, and we would rather say so than publish one.
I'm especially interested in people working on organizational memory, agent context and decision systems — and in teams that learn well without any of it.