A note, in almost every knowledge system ever built, records what was true when someone wrote it. Then it sits there. If the world changes, the note stays wrong until a human happens to reread it. We spent the last two weeks closing that gap in a signed-off design and a working pilot: a note can now carry its own rules in six frontmatter fields, and a pilot evaluator has already walked those rules against real signals, writing a receipt for every check while executing nothing. The production loop, second on the build order behind the compiler, will run the same rules nightly: when a brand's composite score drops below the threshold its owner set, it will post a flag to Slack by morning and write a receipt. Nobody rereads anything.
The idea is old. Vannevar Bush sketched associative trails in 1945. Doug Engelbart's Dynamic Knowledge Repository was a store that improves the group using it, and Gordon Pask's entailment meshes defined concepts by what they entail about other concepts. The active-database community worked out event-condition-action rules in the late 1980s and 1990s. Even the parts are published standards: RDF for the statements, statement-level annotation so a condition attaches to the relationship itself, SHACL for validating shapes, PROV-O for who-asserted-what-when, W3C Web Annotation for highlights. We invented nothing at the logic layer. What we built is the packaging and the safety model, because those are the parts the standards leave open.
The packaging is small on purpose. A rule is six plain fields in a note's frontmatter: which signal to watch, a comparison against it, what to do when the comparison holds, how often to check, whether the rule is switched on, and the rule's own stable address in the graph store. A deterministic compiler, the first item on the build order, turns that block into graph statements. Humans and agents write the six fields; nobody hand-authors triples. An agent that reads the note learns what its owner wants watched and why, in one place, without consulting a separate rule system.
The safety model is where the real design work went, because a note that causes actions when an agent reads it is structurally a prompt injection. So reading and firing are handled by two separate components. Reading a note triggers nothing, ever. One evaluator, with its own identity and schedule, checks conditions each night and fires what should fire. Switched-on rules may send notifications only. Any action that writes or cannot be undone stays parked, and each firing becomes a proposal a human approves. A condition is a bounded comparison against a named signal, never an open query, which closes the injection route through the condition itself. No rule may write a signal that any rule watches, so chains cannot feed themselves. And every check writes a hash-chained receipt whether it fired or stayed quiet, so months from now we can reconstruct exactly what the system did and why.
The export boundary makes this a business rather than a science project. A client bundle carries the rule's address and a plain-language statement of intent; the logic itself stays in the store behind a gate we control. The exchange format helps by being weak: its links carry no relationship types, so the rule logic we hold back has no way to ride along. That split is what turns a report into standing coverage. The deliverable used to be a document that was accurate on its publication date. With rules attached, the same knowledge keeps watching its own signals after it ships, and the client pays for the watching.
Two honest constraints from the intake side, learned the hard way. A prompt is not a constraint: language models drift on property names no matter how firmly you ask, so a deterministic pass reasserts the locked ontology after every extraction and rejects anything outside it. And a text string is not an entity: without a stable ID registry, the same company becomes a different node on every run, and the graph quietly stops being cumulative.
The next loop to close is human annotation. A reader highlight should become a rule proposal through a small form whose vocabulary simply cannot express anything unsafe: pick a signal from the allowed list, pick a comparison, pick a notification, write a free-text rationale that never touches the graph. Proposals enter the store switched off, and only a human switches one on. The open question is how far that proposal loop can go before review itself becomes the bottleneck. The receipt log will answer it: as proposal volume grows, we'll see exactly where review starts to lag.