# August 6, 2026 Addendum: Then the Provider Failed

This addendum is intentionally additive. It does not rewrite the historical checkpoint captured in **The Mesh Held, but Not Because Nothing Failed**. The earlier manuscript remains evidence of what was known at that time. This section records what happened next, as of **August 6, 2026**.

## The failure moved outside the mesh

The original field report was mostly about pressure we created ourselves: overlapping lanes, stale state, provider assumptions, withdrawn receipts, an unauthorized Production deployment, and an operating model moving faster than it could safely observe itself.

On August 6, the failure moved underneath us.

GitHub reported a multi-service incident affecting Actions and Pages. Workflows failed or remained queued. Hosted-runner capacity was constrained. Webhook delivery could be delayed. Coding-agent functions were also affected.

The mesh did not route around GitHub and continue as if nothing had happened.

That exposed a useful distinction:

> Provider-neutral architecture is not provider-independent operation.

GhostMesh treats workers as temporary and providers as replaceable in principle. The August 6 incident proved that the implementation still concentrated meaningful execution capability in GitHub. Actions, Pages, repository events, hosted runners, and parts of the coding-agent surface shared one provider boundary.

The doctrine survived. The implementation remained dependent on its implementation provider.

That is a better finding than pretending abstraction had already become failover.

## Holding did not mean continuing to run

One scheduled Tony Brain archive interval failed before a runner ever started.

The important part was what happened next.

The system did not declare the archive code broken. It did not rewrite the importer. It did not create a retry storm while hosted capacity was constrained. It did not call the missed interval fresh because the schedule had fired.

The interruption was classified as an external provider-capacity wait. The last successful archive identity remained authoritative. One bounded catch-up obligation was preserved.

When provider execution returned, that obligation resumed through the same canonical workflow. Historical scheduled run `31122859669` retained its cancelled-before-execution attempt as outage evidence. At unchanged Tony Brain `main` commit `5247b8cbe312426f44fe9f9fafca3f549c1d8956`, the exact `ingest` job reran once as replacement job `92750528093`.

The replacement succeeded.

Build passed. Evidence-schema validation passed 37 of 37 tests. Archive-importer validation passed 17 of 17 tests. Scheduled campaign reconciliation completed. Sanitized receipt artifact `8979773034` was uploaded with SHA-256 `8aaf4dc3cd38d3d16bd6532092ffdafcfd0e899d753011a1ba7a0be561b1f1c4`.

No competing archive run was created. The original failure stayed in the record.

That proves the operating rule the outage forced us to make explicit:

> One missed obligation creates one bounded recovery obligation. When the dependency returns, recover the obligation without duplicating the history.

Holding did not mean uninterrupted execution.

Holding meant the system still knew what happened, what did not happen, which state remained authoritative, and what the next valid action became when the dependency returned.

## Owner-ready also became a harder claim

The outage collided with another weakness already visible in the publication and execution lanes.

Mechanically green work did not always produce the human outcome it claimed to have produced. A protected route could hang. An article route could fall back to the library. A candidate could be complete but unable to acquire execution. An owner command could exist without a durable task, claim, runner, heartbeat, blocker, or terminal state.

That exposes a control boundary between **mechanical completion** and **human consequence**.

For owner-facing work, deployment or HTTP success is not enough. The intended content and interaction must actually exist at the review surface.

The lifecycle is better stated as:

`INTENT -> EXECUTION -> MECHANICAL VALIDATION -> DEPLOYED STATE -> EXPECTED OWNER-VISIBLE CONTENT -> TERMINAL RECEIPT`

If the route hangs, serves stale content, substitutes the wrong product, or omits the expected interaction, earlier green states remain evidence. They do not become completion by accumulation.

## Safety and operability are different planes

As of August 6, the safety plane was ahead of the operability plane.

The safety plane had become increasingly strong around bounded claims and leases, exact revision identity, path ownership, temporary credentials, duplicate refusal, replay safety, mutation accounting, rollback, cleanup, and fail-closed authority.

The operability plane still had material gaps:

- generic model-backed cloud pickup was not yet durably proven;
- owner commands could exist without an admitted execution adapter;
- external provider waits were not uniformly projected across every surface;
- owner-handoff integrity had required another explicit contract;
- automatic provider failover was not operationally proven;
- fragmented execution state could still turn owner attention into the integration layer.

That is not evidence that the architecture failed.

It is what happens when an architecture becomes real enough for the next weaknesses to stop hiding behind diagrams.

## The next resilience boundary

The progression is now clearer.

First, temporary workers became replaceable.

Then execution state became durable enough to recover after worker failure.

Then cross-repository and higher-trust execution worked without broad standing credentials.

The next boundary is larger:

> Make provider loss a governed state without losing continuity.

That does not require pretending every provider can be swapped in real time. It requires the system to distinguish what remains authoritative, what is unavailable, what can move to another admitted execution surface, what must stop, what requires owner action, and what exact obligation must resume later.

A serious provider-loss contract should distinguish at least:

- authority still available;
- durable state still available;
- reads available or unavailable;
- mutations available or unavailable;
- hosted execution unavailable;
- publication unavailable;
- model-backed execution unavailable;
- alternate adapter available;
- catch-up required;
- owner action required;
- recovery complete.

Collapsing all of that into `failed` destroys useful truth.

## Invariants earned on August 6

The incident added several durable rules:

1. **Provider-neutral is not provider-independent.** Operational substitutability must be proven.
2. **External provider failure is a first-class state.** Unavailable execution capacity is not automatically an application defect.
3. **One missed obligation creates one bounded recovery obligation.** Recovery must not create duplicate execution.
4. **Last-known-good stays visible without pretending to be current.** Staleness is evidence.
5. **Every accepted command needs durable execution state or an exact no-adapter/external-wait terminal.** A comment is not a running worker.
6. **Owner-ready means owner-usable.** The intended content and interaction must be present at the review surface.
7. **Provider loss must preserve truth even when it cannot preserve throughput.**
8. **Recovery preserves the failed history.** A later catch-up does not convert the original failed attempt into success.

## The definition changed

The original field report concluded that the mesh did not make chaos efficient. It made chaos bounded, visible, recoverable, and capable of teaching the system what control it was missing.

The August 6 outage adds a harder definition:

> Resilience is not the ability to keep everything running. It is the ability to lose a component without losing the truth about what happened, what remains authoritative, and what may happen next.

GitHub Actions could stop. Pages could degrade. A runner could never arrive. A scheduled interval could be missed.

The mesh would not be fully operational.

But if authority, exact state, unfinished obligations, recovery identity, and the next legal action remain intact, continuity remains.

The Tony Brain catch-up supplied the corresponding recovery proof: when execution returned, one preserved obligation completed exactly once without erasing the failure or creating competing state.

That is a harder standard than uptime and a more useful one.

## Evidence anchors

This addendum is bound to the August 6 checkpoint evidence including:

- `pinklon/shareplane-control-tower#348` for execution-to-UAT convergence and owner-handoff integrity;
- `pinklon/shareplane-control-tower#344` / PR `#345` for direct connector and deterministic adapter proof plus the generic model-backed boundary;
- `pinklon/shareplane-control-tower#347` for canonical execution-class routing and explicit no-adapter state;
- `pinklon/tony-brain#84` for the missed archive interval and bounded recovery under run `31122859669`, replacement job `92750528093`, and receipt artifact `8979773034`;
- the GitHub Status incident dated August 6, 2026 for the provider degradation itself.

## Nonclaims

This addendum does not claim automatic failover away from GitHub, general provider independence, complete generic model-backed cloud pickup, uninterrupted execution during the outage, recovery of every affected workflow, terminal repair of owner-handoff integrity, or completion of every GhostMesh resilience objective.

It records a narrower sequence of facts.

The provider failed in ways that mattered. The mesh did not keep everything running. It preserved the truth required to recover. When execution returned, one missed obligation recovered exactly once through the canonical path without rewriting the failed history.