libops · libops-agent · Jul 19, 2026 · Jul 19, 2026
diff --git a/infrastructure/cloud-compose.mdx b/infrastructure/cloud-compose.mdx
@@ -164,7 +164,7 @@ release-specific IAM instructions. Do not copy an unpublished foundation
 module from a development branch into an otherwise pinned production stack.
 
 <Info>
-The [July 17, 2026 release-status snapshot](/infrastructure/current-release-status) records cloud-compose `1.5.0` and the signed PPB `0.5.1` image as released self-hosted dependencies. That does not make the separate managed shared-router/private-PPB integration generally available; its API, edge, and end-to-end promotion gates remain independent.
+The [July 19, 2026 release-status snapshot](/infrastructure/current-release-status) records cloud-compose `1.5.0` and the signed PPB `0.5.1` image as released self-hosted dependencies. That does not make the separate managed shared-router/private-PPB integration generally available; its API, edge, and end-to-end promotion gates remain independent.
 </Info>
 
 The optional Cloud Run power-management ingress reaches the VM's private

diff --git a/infrastructure/current-release-status.mdx b/infrastructure/current-release-status.mdx
@@ -7,7 +7,7 @@ description: "A dated availability record for the independently released artifac
 There is not yet a published, platform-wide known-good release set for the managed shared-router and private-PPB request path. The architecture pages describe the target contract, but they are not evidence that this integration is generally available. Do not change production DNS or infrastructure for that path until a later status record identifies every immutable artifact and its green end-to-end release gate.
 </Warning>
 
-This snapshot was reviewed on **July 17, 2026 at 02:44 UTC**. It is a release record, not a moving "latest" lookup. A later tag does not silently update the compatibility claims on this page.
+This snapshot was reviewed on **July 19, 2026 at 01:15 UTC**. It is a release record, not a moving "latest" lookup. A later tag does not silently update the compatibility claims on this page.
 
 ## Status meanings
 
@@ -24,10 +24,10 @@ This snapshot was reviewed on **July 17, 2026 at 02:44 UTC**. It is a release re
 
 | Surface | Dated reference | Status | What this record proves |
 | --- | --- | --- | --- |
-| Last published generated `sitectl` documentation set | [Generated documentation dependency manifest](https://github.com/libops/sitectl-docs/blob/214049330081000a57f3179f9bcf3d151af03fb6/scripts/snippet-dependencies.json) | Released docs set | The documentation was generated from the exact commits in that manifest: core `sitectl` `v1.0.1`, `sitectl-isle` `v1.0.1`, the other self-hosted application plugins at `v1.0.0` including `sitectl-drupal`, and managed-platform `sitectl-libops` at `v1.3.0`. The core and ISLE patches canonicalize the displayed spelling of `superseded` while retaining legacy input and RPC compatibility; exact-main documentation CI passed. |
+| Last published generated `sitectl` documentation set | [Generated documentation dependency manifest](https://github.com/libops/sitectl-docs/blob/bb890d50726a036938bcae0c451040472343d65d/scripts/snippet-dependencies.json) | Released docs set | The documentation was generated from the exact commits in that manifest: core `sitectl` `v1.0.2`, `sitectl-isle` `v1.0.1`, the other self-hosted application plugins at `v1.0.0` including `sitectl-drupal`, and managed-platform `sitectl-libops` at `v1.4.0`. Core emits the canonical `superseded` RPC spelling while retaining legacy input compatibility; the ISLE patch canonicalizes its displayed spelling. The Google domain lifecycle commands and recovery-safe shared publisher contract are included, and exact-main documentation CI passed. |
 | cloud-compose | [`1.5.0`](https://github.com/libops/cloud-compose/releases/tag/1.5.0) | Released dependency | Provider isolation, the GCP-only compatibility root, compiled CI helper, exact per-run smoke ownership, rollback-preserving Docker cleanup, and coordinated sitectl v1 presets passed Terraform/configuration lint plus hosted GCP, DigitalOcean, Linode, Ansible, Salt, and fresh-install gates. Its rootfs and checksum release assets were also published successfully. |
 | Self-hosted application baseline | [cloud-compose `1.5.0` template presets and released matrix](/templates/compose-projects#released-compatibility-baseline) | Published compatibility baseline | Every preset pins core `sitectl` and its independently released application plugin at `v1.0.0`. Application templates are `v1.0.0`, except ISLE `v1.1.0`; direct image identities are immutable where the template owns them, while explicitly component-controlled Islandora images use the catalog's reviewed `ISLANDORA_TAG=6.3.19` default. The matrix does not claim that all seven applications ran on all five infrastructure adapters in one aggregate test. |
-| ISLE v1 releases | [`libops/isle` `v1.1.0`](https://github.com/libops/isle/tree/v1.1.0), core [`sitectl` `v1.0.1`](https://github.com/libops/sitectl/releases/tag/v1.0.1), [`sitectl-drupal` `v1.0.0`](https://github.com/libops/sitectl-drupal/releases/tag/v1.0.0), [`sitectl-isle` `v1.0.1`](https://github.com/libops/sitectl-isle/releases/tag/v1.0.1), and [cloud-compose `1.5.0`](https://github.com/libops/cloud-compose/releases/tag/1.5.0) | Released dependency | The template and DigitalOcean catalog smoke prove the cloud-compose preset recorded with core, Drupal, and ISLE plugins at `v1.0.0`. Core and ISLE subsequently published `v1.0.1` spelling-only compatibility patches with binary and package release gates; those patches do not rewrite the cloud-compose `1.5.0` compatibility baseline. The cloud catalog supplies the minimum supported Islandora image tag without overriding an explicit downstream value. |
+| ISLE v1 releases | [`libops/isle` `v1.1.0`](https://github.com/libops/isle/tree/v1.1.0), core [`sitectl` `v1.0.2`](https://github.com/libops/sitectl/releases/tag/v1.0.2), [`sitectl-drupal` `v1.0.0`](https://github.com/libops/sitectl-drupal/releases/tag/v1.0.0), [`sitectl-isle` `v1.0.1`](https://github.com/libops/sitectl-isle/releases/tag/v1.0.1), and [cloud-compose `1.5.0`](https://github.com/libops/cloud-compose/releases/tag/1.5.0) | Released dependency | The template and DigitalOcean catalog smoke prove the cloud-compose preset recorded with core, Drupal, and ISLE plugins at `v1.0.0`. Core `v1.0.2` and ISLE `v1.0.1` subsequently published canonical-spelling compatibility patches with binary and package release gates; those patches do not rewrite the cloud-compose `1.5.0` compatibility baseline. The cloud catalog supplies the minimum supported Islandora image tag without overriding an explicit downstream value. |
 | Terraform Cloud Run v2 module | [`0.8.0`](https://github.com/libops/terraform-cloudrun-v2/releases/tag/0.8.0) | Released dependency | The reusable module release exists. That does not prove that cloud-compose or the managed control plane has promoted every module capability. |
 | PPB support image | [`0.5.1`](https://github.com/libops/ppb/releases/tag/0.5.1) at `sha256:249697fe2ce7e007053af270be2d5cb064ffa545572a035e405e2763298149bc` | Released dependency | GHCR and public GAR expose the same multi-platform manifest. Its keyless signature verified against the pinned shared publisher workflow identity. This proves the support image release, not the unreleased managed router integration. |
 | Buildkit images and Compose templates | The exact template checkout and each `tag@sha256:digest` it records | Unrecorded | Templates record immutable direct-image identities, but this snapshot does not contain a generated aggregate of every template commit, Buildkit digest, and hosted smoke-test result. |
@@ -38,8 +38,8 @@ The table deliberately does not invent an image digest, template commit, signatu
 
 | Integration | Status | Gate that remains |
 | --- | --- | --- |
-| Cloud DNS and Certificate Manager through the global load balancer, Cloud Armor, shared Cloud Run router, and private per-site PPB | Blocked / preview | PPB `0.5.1` is available, but the exact edge-controller and router images, DNS delegation, certificate-map lifecycle, API/router integration, managed Terraform pins, private-origin, client-IP, authorization-preservation, split timeout, Direct VPC, and hosted canaries still need promotion as one managed set. Cloud CDN remains disabled. |
-| Organization Vault three-image runtime | Blocked / preview | The verified-publisher desired state is merged, but the public GAR writer migration has not passed a successful central Terraform apply and protected-workflow publication canary; the Vault Init GAR upload still fails closed. Apply and verify that central state, publish and verify the independently versioned `vault-server`, `vault-init`, and `vault-proxy` manifests, release the sitectl-admin digest resolver and exact tag-commit/signature gate, pin all three immutable GAR manifests, and pass the API, Terraform, initialization, recovery, and rollback gates. A source release, local candidate, or reserved version is not an aggregate runtime release. |
+| Cloud DNS and Certificate Manager through the global load balancer, Cloud Armor, shared Cloud Run router, and private per-site PPB | Blocked / preview | PPB `0.5.1` is available, but the exact independently built site-router, edge-controller, and edge-provider-mutator image digests, ordered Pub/Sub mutation delivery, static Certificate Manager deny boundary, child-zone delegation lifecycle, two-phase organization DNS teardown with persisted TTL high-water and recursive-plus-parent-authority absence proof, exact-service-account state-gateway authentication, transactional observed-state outbox, managed Terraform pins, private-origin, client-IP, authorization-preservation, split timeout, Direct VPC, and hosted canaries still need promotion as one managed set. Cloud CDN remains disabled. |
+| Organization Vault three-image runtime | Blocked / preview | The shared publisher and verified WIF selector have passed protected-main publication for `vault-server`, released `vault-init` `1.0.6`, and released `vault-proxy` `2.0.3` through the cleanup-safe shared workflow. The aggregate runtime is still blocked until sitectl-admin's digest resolver and exact tag-commit/signature gate are released, all three independently built GAR manifests are pinned by digest, and the hosted API, Terraform, initialization, recovery, and rollback gates pass. Independently green image publications are not an aggregate runtime release. |
 | Canonical API image set and production VM resolver | Blocked / preview | Merge the hosted post-CI publisher and `sitectl admin terraform api-compose-images`; publish the exact protected-main run to GHCR plus the appropriate private or public GAR repository; verify every digest's reusable-workflow identity, caller repository/ref/SHA, and caller-workflow annotation; and prove fresh VM bootstrap plus in-place refresh with the four verified private-GAR Compose images, the checkout detached at the publication commit, and legacy boot-disk discovery that fails on ambiguity. |
 | Separate request-serving API and `api-worker` Cloud Run services | Preview | Release the managed worker deployment and prove identity bootstrap, database connectivity, readiness, rollout, rollback, and removal of any temporary migration privilege. A process boundary in source or Compose is not proof of this Cloud Run topology. |
 | Platform-wide image, template, CLI, plugin, and infrastructure compatibility manifest | Blocked | Generate the aggregate record from release automation and attach hosted CI evidence for the exact references. Until then, each operator owns a deployment-specific record. |
@@ -53,7 +53,11 @@ A future status entry can change a managed integration to released only when it
 - every template release or full commit;
 - core `sitectl` and each plugin's independent package version;
 - the cloud-compose release or full commit, reusable Terraform-module releases, and provider lockfiles;
-- the API, worker, router, and PPB release identities;
+- the API, worker, site-router, edge-controller, edge-provider-mutator, and PPB
+  release identities;
+- hosted proof that organization DNS teardown removes provider resources,
+  child records, parent delegation, drained child zone, and foundation IAM in
+  that order without bypassing the full published TTL; and
 - the exact hosted smoke, upgrade, migration, canary, and rollback evidence.
 
 <Card title="Release compatibility and upgrades" icon="arrows-rotate" href="/infrastructure/release-compatibility">

diff --git a/platform/adoption-model.mdx b/platform/adoption-model.mdx
@@ -141,28 +141,45 @@ Managed Terraform keeps long-lived ownership narrow:
 
 | State | Owner |
 | --- | --- |
-| Foundation | Customer folder, organization project, protected state bucket, and Terraform runner identity/job |
+| Foundation | Customer folder, organization project, protected state bucket, Terraform runner identity/job, and exact conditional IAM for that runner's NS record in the existing `libops.site` parent zone |
 | Organization | Shared organization network and services, Vault runtime, events, and model integrations |
 | Vault configuration | Mounts, policies, and workload-auth configuration |
 | Project | One customer project plus its complete runtime and site infrastructure inventory |
-| Edge | Public hostname and edge-routing resources |
+| Edge | Organization child Cloud DNS zone, parent NS delegation, child records, restricted controller IAM, and public hostname routing inputs |
 
 Creation follows foundation, organization, Vault configuration, project, then
-edge; deletion reverses that order. Deletion is staged and terminal: children
-must be retired before their parent, externally billed project capacity must be
-removed idempotently before the local tombstone commits, and a project is not
-marked decommissioned until its final infrastructure apply succeeds. An
-organization delete does not silently cascade through projects; every retained
-project must already be terminal and decommissioned, with billing in a terminal
-`canceled` or `incomplete_expired` state (or no subscription). A site does not
-receive an independent Terraform state, and one state
-must not manage a resource owned by another root.
+edge; deletion reverses that order. Foundation does not create the child DNS
+zone or its delegation: it creates only the project, runner, and exact
+conditional permission to change that organization's NS record in the
+existing parent zone. The edge state is the sole Terraform owner of the child
+zone, parent delegation, child records, and child-zone controller IAM.
+
+Deletion is staged and terminal. Edge provider resources are removed first.
+The first destructive edge apply removes child records and then the parent NS
+while retaining the empty child zone and controller IAM. The control plane
+persists the successful removal time and highest published delegation TTL,
+waits that full interval, and then requires the exact NS record to be absent
+from both a trusted recursive view and every current parent authoritative
+server. Only a later edge apply may delete the empty `force_destroy = false`
+zone and controller IAM. Vault, organization, and foundation state remain
+blocked until that final edge apply succeeds; foundation's parent-zone IAM is
+removed last.
+
+Externally billed project capacity must likewise be removed idempotently before
+the local tombstone commits, and a project is not marked decommissioned until
+its final infrastructure apply succeeds. An organization delete does not
+silently cascade through projects; every retained project must already be
+terminal and decommissioned, with billing in a terminal `canceled` or
+`incomplete_expired` state (or no subscription). A site does not receive an
+independent Terraform state, and one state must not manage a resource owned by
+another root. Downstream operators must not bypass a managed phase by manually
+deleting the delegation, child zone, or foundation IAM.
 
 <Warning>
 The shared-router/private-PPB integration is a target architecture and is not generally released in the [current status snapshot](/infrastructure/current-release-status). The ownership boundary remains valid, but the linked router identity, canonical client-IP, and timeout details must not be treated as the current production topology until their release gate is complete.
 </Warning>
 
-In that target path, controller and site delivery use private network traffic but remain authenticated. Shared project state owns the Cloud Run service identity, network-use permissions, and regional network capacity; runtime state owns instance-scoped power grants and VM firewall rules. The public site path still enters through Cloud DNS, the global external Application Load Balancer, Cloud Armor, and the shared router because Direct VPC provides Cloud Run **egress**, not service ingress. See [Security and Operations](/platform/security-operations) for the target router-to-PPB identity, canonical client-IP, subnet, startup, and timeout contracts.
+In that target path, deployment `controller-ingress` and site PPB delivery are the only services that use Direct VPC egress to private VM addresses; both remain authenticated. Shared project state owns the Cloud Run service identity, network-use permissions, and regional network capacity; runtime state owns instance-scoped power grants and VM firewall rules. The Google edge-controller is not on this private path: it observes Certificate Manager read-only, publishes ordered mutation commands, calls the authenticated API state gateway over HTTPS, and has no database credential or VPC attachment. An internal IAM-authenticated edge-provider-mutator is the sole dynamic Certificate Manager writer and likewise has no DNS, database, or VPC access. The public site path still enters through Cloud DNS, the global external Application Load Balancer, Cloud Armor, and the shared router because Direct VPC provides Cloud Run **egress**, not service ingress. See [Security and Operations](/platform/security-operations) for the controller/mutator trust split and the target router-to-PPB identity, canonical client-IP, subnet, startup, and timeout contracts.
 
 ## Responsibility changes by adoption layer
 

diff --git a/platform/automation-backplane.mdx b/platform/automation-backplane.mdx
@@ -8,7 +8,7 @@ LibOps uses GitHub as an important collaboration surface, but the platform shoul
 LibOps is building a webhook-driven automation backplane for events that need to trigger work inside the platform: dependency scanning, CI runner orchestration, deployment follow-up, and repository maintenance.
 
 <Warning>
-The separate request-serving API and `api-worker` Cloud Run deployment described below is a **preview target**, not a released managed topology in the [July 17, 2026 status snapshot](/infrastructure/current-release-status). Process separation in source code or a Compose development stack does not prove that the worker service, identity migration, database path, rollout, and rollback have been promoted in production.
+The separate request-serving API and `api-worker` Cloud Run deployment described below is a **preview target**, not a released managed topology in the [July 19, 2026 status snapshot](/infrastructure/current-release-status). Process separation in source code or a Compose development stack does not prove that the worker service, identity migration, database path, rollout, and rollback have been promoted in production.
 </Warning>
 
 ## GitHub events in LibOps