Every tool I have published.

The first wall I hit in a long project was memory. Every new session opened by re-explaining settled choices, established preferences, and the history of the project. Over a single conversation that cost is invisible; over weeks and months, rebuilding the same context takes more time than the work itself.

mneme stores that context between sessions, recalls it when it is needed, and lets several clients share one memory. The history of a project then sits outside the conversation, and no longer waits to be rebuilt at the start of each one.

Agents write good code now. Writing code and showing that the code works are not the same job. In the loop I was running, an agent would make a change, then the same agent would review that change and report the work complete. One question was left unanswered: was this verified, or did the agent hand its own output a passing grade?

mergen makes that distinction visible. It collects the evidence behind a change, halts the process until the required checks have run, and records who performed the verification. An agent approving its own output cannot do so quietly underneath mergen.

Social scientists have powerful tools today, and very little written guidance on using them in research that touches human data. In this field, a tool's capabilities are not the whole question. Where the data is kept, which information leaves the machine, how the research process is recorded and at which stages AI was involved all belong to the same question.

This guide and toolkit were written for that gap. The aim is not to turn social scientists into programmers, but to let them use powerful technical tools in their own research without losing data security or research integrity along the way.

Knowing which model you selected is easy. Seeing which model actually answered is not always. Once several models or a routing layer are involved, the name in the configuration and the model serving the request can drift apart without anyone noticing.

routeledger reads that difference out of the session transcript itself and records which model ran on each turn. It works read-only, never goes online, and sends nothing it inspects off the machine. If I am evaluating a system, I want the measurement to come from the session that happened rather than the settings file.

In career decisions, measuring how good a model's suggestions are is easier than asking who holds the decision. The second question settles more. A career decision does not rest on information alone; a person's values, living conditions, available options and the uncertainty they carry are part of it. Handing a process like that entirely to a model does not sit right with me.

vocation-os therefore keeps the decision with the person. It records the information used and the claims that come out of it, separates a reversible step from an irreversible one, and asks for explicit approval before the second kind. The record can be opened and read later, so why a suggestion was followed, or was not, is still visible six months on.