ops-warden/docs/adr
tegwick 8c58f8bfa1
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
Hand the zone model to zone-engine; keep WP-0032 as the consumer side
zone-engine is seeded and owns the security zone model as ZONE-WP-0001. Under
ADR-0005 ops-warden implements one lane narrowly and routes the rest, and an
estate-wide enforcement model is not a lane to absorb — it was ops-warden's
deferred flip that exposed the gap, not ops-warden's model to define.

WARDEN-WP-0032 is rewritten as the consumer side: hand the estate inputs to
ZONE-WP-0001-T02 (27 catalog lanes, the actor inventory, the three posture axes,
the three controls the model must express, and the compiled-registry path),
then replace policy.enabled with a zone-aware control and amend ADR-0006 to say
ops-warden follows the model rather than owning it.

ADR-0006 and SCOPE updated to point at zone-engine, which joins the related
repositories table.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 21:20:34 +02:00
..
ADR-0001-catalog-is-a-pointer-layer.md Lift ops-warden's binding rules into owned ADRs 2026-08-18 13:35:13 +02:00
ADR-0002-conduit-not-broker.md Lift ops-warden's binding rules into owned ADRs 2026-08-18 13:35:13 +02:00
ADR-0003-cover-gaps-never-silently-own-them.md Lift ops-warden's binding rules into owned ADRs 2026-08-18 13:35:13 +02:00
ADR-0004-agent-read-boundary-on-high-risk-lanes.md Lift ops-warden's binding rules into owned ADRs 2026-08-18 13:35:13 +02:00
ADR-0005-implement-narrowly-route-broadly.md Lift ops-warden's binding rules into owned ADRs 2026-08-18 13:35:13 +02:00
ADR-0006-enforcement-is-zone-scoped.md Hand the zone model to zone-engine; keep WP-0032 as the consumer side 2026-08-19 21:20:34 +02:00
README.md ADR-0006: enforcement is zone-scoped; defer the policy.enabled flip 2026-08-19 20:31:28 +02:00

ops-warden architecture decision records

This directory holds the rules ops-warden owns — the decisions this repo made, is bound by, and is responsible for changing.

Why these exist as ADRs rather than wiki prose

Until 2026-08-18 every rule in this list lived in wiki prose, a workplan, or a comment at the top of registry/routing/catalog.yaml. All of them were being followed. None of them was addressable: a reader outside ops-warden could not cite one, could not tell whether it was current, and could not tell whether it was ours to change or someone else's that we merely obey.

That distinction is the point of this directory. It matters in both directions:

  • A rule we own, mistaken for inherited canon, never gets fixed. We wait for an owner who does not exist.
  • Inherited canon, mistaken for ours, gets quietly bent. We change something we had no authority over, and the drift is invisible until it breaks a repo that trusted the canonical version.

Owned versus inherited

Every ADR here carries owner: in its frontmatter. It is the load-bearing field.

owner: Meaning How it changes
ops-warden Ours. We decided it, we are bound by it, and we may change it A new ADR that supersedes this one. Never an edit-in-place that rewrites a decision
anything else Inherited. We follow it; we do not own it Through that owner's process. We may dispute it — we may not amend it

Everything currently in this directory is owner: ops-warden. Rules we follow but do not own — NetKingdom canon, the IAM profile, the credential-management standard — are not copied here. They are cited. Copying inherited canon into our own ADR directory would recreate exactly the second-source-of-truth failure that ADR-0001 exists to prevent.

Superseding one of these

A decision here changed the behaviour of other repos, so retracting it silently is not available. Write a new ADR, set the old one's status: superseded and successor:, and leave it in place. Superseded is a lifecycle state; deletion is not. policy-nexus publishes the history, and a reader asking "what did this say when we made that decision" must be able to find out.

Relationship to .claude/rules/

.claude/rules/*.md are agent-facing operational instructions. They tell an agent what to do in a session. They are derived from these ADRs and should cite them rather than restate the reasoning. If the two disagree, the ADR is right and the rule file is a defect.

Publication

These are publishable through policy-nexus at policy.coulomb.social, which requires title, status and owner on every document and renders Owner as a column in its index. The ownership knowledge therefore survives publication rather than being a local convention that evaporates at the repo boundary.

policy-nexus publishes; it never writes back. The file in this directory is the source of truth. If the site and this directory disagree, this directory is right and the publication is a defect.

ADR Rule Binds
ADR-0001 The routing catalog is a pointer layer, never a second copy of an owner's procedure ops-warden, and every repo contributing a catalog entry
ADR-0002 ops-warden is a transparent conduit, never a secret broker ops-warden
ADR-0003 Cover gaps, but never silently own them ops-warden
ADR-0004 High-risk lanes refuse raw value streaming to agent sessions ops-warden, and any agent runtime calling warden access
ADR-0005 Implement one lane narrowly, route everything else ops-warden
ADR-0006 Enforcement is zone-scoped, never a global flag ops-warden