Operator Control Plane

Operator is a local, domain-neutral ledger for agent work. It does not make an agent’s claim true merely by recording it. It gives the claim a place in a workflow where evidence and verification can be examined.

task → claim → evidence → verification → session and usage record

The everyday path

Initialize a ledger in the project you intend to track, then use the CLI to create a task, make specific claims, attach evidence, and record a verifier’s assessment.

pip install -r requirements.txt
/path/to/operator-control-plane/operator init
/path/to/operator-control-plane/operator doctor

init creates a gitignored .operator/ ledger in the current directory. The command sequence is only a starting point; use ./operator --help for current command syntax and examples/verified-work/run.sh for a runnable walkthrough.

The identity boundary

In default single_user mode, verification is advisory: a reviewer name is not proof of an independent reviewer. In enforced mode, independent verification requires a registered verifier operating under an OS UID different from the claim author’s UID. Two agents or harnesses under the same OS user are not distinct identities. Operator does not provision that OS-level separation.

A stored verification command is not proof it ran. The verifier must run the check and record the result; doctor never executes stored commands.

Evidence and integrity checks

Local evidence is retained and fingerprinted. Trust-relevant writes are recorded in local SQLite history, with YAML projections. doctor checks ledger consistency, evidence, and applicable verification requirements. It is read-only: it does not repair records or run checks.

This is local auditability, not an off-machine backup or a tamper-proof boundary against someone who controls the host. Protect and back up the data your workflow depends on. Pay attention to the severity of findings: draft warnings and errors on verified records have different meanings.

Everything else supports the ledger

Broker administration, delegation, harness studies, sessions, usage reports, and local comparisons can support particular deployments or workflows. They do not replace the task → claim → evidence → verification path. Harness names route work or describe accounting; they do not grant verification authority. Configured harnesses are not automatically proof of compatibility across providers or environments.

When something goes wrong

• If the host, permissions, socket, or enrollment is wrong, stop and restore the documented prerequisites before retrying privileged work.
• If authority state changed, use the documented reconciliation process; do not silently adopt a replacement store.
• Resume checkpointed work only when its workflow supports resume and the saved plan still matches.
• If an integrity check fails, preserve the state for diagnosis. doctor is a checker, not a repair tool.

Some later verification changes can reopen work that appeared complete. Treat completion as dependent on the current trusted records.

The short version of the limits

Operator records and checks workflow state. It is not a fleet scheduler, does not create OS identity isolation, does not replace backups, and cannot promise that every external harness works everywhere. The strength of a conclusion depends on the evidence, verifier identity, and host controls available.

Read more

• Detailed manual — broader operational coverage
• Original manual
• Project README and current command reference

Scope: this is an essence-first overview, not release-specific proof of live deployment behavior. Check command names, authority integration, and recovery procedures against the release and host you use.