Cyber-Hobo AI-augmented, documented from its records for collective learning

This site documents a way of working: a senior consultant producing professional work with an AI assistant, and the mechanisms that keep the output trustworthy.

The practice's value is the margin over what a capable model produces on its own. General knowledge is available from any capable model on demand, so collecting it adds nothing. The effort goes into what a model cannot supply: facts validated against their sources, and judgment based on experience. For subjective knowledge, context is essential: a judgment can be applied and checked only together with the situation it was formed in.

Where we came from

I have worked in security consulting for twenty years, and for the last few years I have been developing a personal system for that work, systematically. Auditing the output is a standing part of the development; early audits of AI-produced regulatory notes found citation-grade errors throughout: wrong article numbers, wrong scope references. A language model produces plausible text whether or not the claim behind it is correct, and in regulated work a wrong citation is a liability. The development aims at a system whose output can be controlled as structurally as possible.

What we learned

Rules written as prose are not reliably followed: the assistant reads them and still drifts, and a rule is followed consistently once an automated check enforces it. My attention is the limiting resource: the assistant's output volume grows faster than my review time, so the system has to direct review to the claims that carry risk. A mechanism has to show evidence of working: every check keeps a record of what it caught, and a check with no catches on record is removed.

Where we are

Every factual claim in the knowledge base carries a grade: model output, anchored to an owned source document, or validated by me. Deliverables state the grade of every claim they carry. Writing, committing and publishing pass through automated checks that reject nonconforming content. Two records cover the work: version control for every change, and session transcripts for every working conversation. The infrastructure is a small set of servers with one VPN entrance and one monitored exit. The fleet page describes it. The collaboration is measured against a dated series: corrections, unsolicited proposals, reading load.

How to read this

The pages come at three depths, one labelled band under the title bar for each.

The chapters, on the band marked concepts, answer what this is and why it is built this way. They run in narrative order, from the problem through to what the system refuses to be, and each is a short read with a figure that carries its mechanism.

Under most chapters sits a page marked in practice, answering how you would do the same thing yourself: a method to run, a decision procedure, or a test to apply, each with its limits stated. Two chapters have no such page, because what sits under them is a diagnosis and a design theory rather than something to run.

Deeper still sit pages marked how it is built, answering what the thing actually is, in enough detail to build one: a mechanism with its checks, its failure cases and its interfaces. This depth exists only where there is machinery to describe.

Each depth stands on its own. The foot of every page carries the previous and next page at that depth, and the way down to the deeper version or back up to the chapter it belongs to.