← The Machine
The measurement · surfaces.yml

Surfaces

Can a stranger actually read what this estate says it publishes.

.github/workflows/surfaces.ymlruns @flashyos/frontdoor

What it does

The workflow points the estate’s own verifier at the estate’s own live domains and fetches every mesh surface each says it serves — the AAO charter, the directory fragment, the front door, the record projections.

Every other check in the estate compares a file to another file in the same checkout, which proves a file is committed — not the property anyone cares about. Four times in one week a mesh file was committed, passed its check, and 404’d in production; not one was caught by a repository.

It fails on a 404 — a property not serving what it says it does — but not on unreachable, because that is a statement about the network between the runner and the host, and failing on it would train everyone to ignore the job.

When it runs
Daily at 07:41 UTC, on demand, and when the surface list changes. On a schedule rather than on push because the thing it detects is a deploy that did not happen — which by definition no push can observe.
What it emits
A pass or a fail, per property, per surface — the record of whether each mesh file the estate advertises is actually reachable at the domain that promises it.

What a stranger can verify

That the served bytes exist, not just the committed ones. Fetch any advertised well-known surface from the domain yourself; the job asks the network exactly as a stranger would, and a 404 fails it while a committed-only file passes nothing.

Questions

What does the Surfaces workflow verify?
That every mesh surface the estate advertises — charter, directory fragment, front door, record projections — is actually served at the live domain, by fetching each over the network the way a stranger would.
Why does Surfaces run on a schedule rather than on push?
Because it detects a deploy that did not happen, and no push can observe a deploy that never occurred. A committed file passes every in-repository check while returning 404 in production; only fetching the domain finds it.
Why does it fail on 404 but not on unreachable?
A 404 means a property is not serving what it claims. Unreachable is a statement about the network between the runner and the host; failing on it would train everyone to ignore the job, which is how the original bug survived.
The concept

Served, not merely committed is the property a mesh file has only when a stranger can actually fetch it from the domain that promises it — not when it passed an in-repository check. A file can be committed, validate against its format, and still return 404 in production, which no push-triggered check can observe.

served, not merely committed →

Keep reading

Read the workflow — it hides nothing ↗The format it keeps current: @flashyos/frontdoorHow the estate stays honest — all of it
Also in the measurement
RegistryEstate graphAdoption signalHygieneScoreboardShipOS gateFlashyOS branch mesh sync