Async Digital / executive
Enforce

The executive

The executive is the live configuration the agent runs under: the settings, agents, rules, skills, and hooks that put the charter into practice on a real machine. Where the charter is the prose we hold, the executive is the state that enforces it. It is one of the four parts of Ordova.


I
Live state
Article I · The canonical config

The slow-moving config, versioned

The executive is the per-machine canonical state for the agent: the configuration that should follow us across machines, kept under version control.

It is the part of the working environment that moves slowly and matters: how the agent is permitted to act, which rules it loads, which skills and agents it can reach. None of it is left to a given machine's memory.

The standard is rebuildable from the repository alone. A fresh machine becomes a working one by restoring this state, not by reconstructing it from habit.

executive README: "per-machine canonical state for Claude Code, the slow-moving config that should follow me across machines, versioned, and rebuildable from this repo alone".

II
Tracked
Article II · What is held

The configuration is tracked in full

The global instructions, the permissions and hooks, the rules, the skills, the agents, and the installed-tooling manifests are all versioned together.

The global instruction file carries the rules every session loads. The settings template carries permissions, hook wiring, model choices, and environment, installed by templating one placeholder into a real settings file. Topical rule modules, authored skills, authored agents, and hook scripts each have their place.

Alongside them sit the manifests that make a machine reproducible: the list of installed marketplace plugins, the canonical server block, and the machine-wide ignore patterns. The repository, not the machine, is the record.

executive README, "What's tracked": global instructions, settings template, rules, skills, agents, hooks, plugins manifest, the canonical MCP block, global gitignore patterns.

III
Not tracked
Article III · What is left out

Session-pace state stays out

Everything the harness writes at the pace of a session is deliberately not versioned.

Caches, session logs, plans, tasks, history, telemetry, and usage data are the running exhaust of work, not the configuration that shapes it. They change too fast and carry no portable value, so they stay out of the record.

Machine-local overrides stay out for the same reason: a single machine may differ, but the difference is local and is never allowed to become the shared standard.

executive README, "What's not tracked": session-pace state (caches, sessions, plans, tasks, history, telemetry, usage) plus machine-local override files.

IV
Layered
Article IV · Two layers

A generic core, then the operator overlay

The live config is installed in two layers: a shareable core, and the operator's own overlay on top.

The executive is the generic core: the hook wiring, the rules, the portable skills, the shareable settings. It installs first. On top of it the operator's creed layer installs second, and wins where the two name the same file.

A core-only install, with no overlay at all, is fully supported: every overlay-dependent step self-skips. The shareable part stands on its own, which is the test of whether the line between shared and private was drawn honestly.

executive README, "Install model, layered": generic core installs first, the personal overlay installs second and wins on filename collisions; a generic-only install is fully supported.

V
Generated
Article V · No merge layer

The live settings are generated, not merged

The running settings file is produced from a template in this repository, with no merge step layered underneath.

Installation templates one placeholder into a real settings file. There is no second source quietly combined at install time, so what the repository says is what the machine gets. Anything that must appear in the live settings belongs in the template, not in the overlay.

The consequence is legibility: a change to the template does not alter a machine until it is reinstalled, and there is never a hidden layer to reconcile against.

executive README + the doc-site "Settings generation, no merge step" note: the live settings file is generated by templating a single placeholder; there is no merge layer.

A derived view

Kept in step with the source

This page is a derived view: a plain-voice adaptation of the executive's own README, not the configuration itself. Keeping the two in step as the source is revised is the job of the source anchor.

See how the layers fit together: executive and creed