Runners are the operational logic layer around the OpsDB. Each runner reads from the OpsDB, acts in the world, and writes back to the OpsDB. The OpsDB is the runner's only stable interface — the persistent inputs and outputs of every runner are exclusively OpsDB rows. Side effects happen in the world; the trail of those side effects lives in the OpsDB. This paper specifies the runner pattern, the runner kinds (puller, reconciler, verifier, scheduler, reactor, drift detector, change-set executor, reaper, bootstrapper, failover handler), the shared-library layer that keeps runners small, and the disciplines that govern runner design: idempotency, level-triggering over edge-triggering, bound everything, and per-runner change-management gating. The paper threads a worked example of the GitOps deployment pattern through several sections to show how runners coordinate through shared data without directing each other. The paper compares OpsDB-coordinated operational practice with standard practice in modern Kubernetes shops, showing where the same work produces a complete queryable trail rather than scattered evidence across many tools. What this paper does not specify: implementation language for runners, deployment platform for runner processes, specific runner code, framework code for shared libraries, Kubernetes tutorials, or GitOps tutorials. Those are organization-specific choices. The runner pattern transfers across all of them.
Geoffrey Howland (Wed,) studied this question.