The door this repository opens to strangers, re-emitted and validated on every push.
The workflow re-emits this repository’s `frontdoor/1` door from its config, validates the result against the format, and fails if emitting changed the committed file — because a stale committed copy means the door a machine reads is not the door the config describes.
The checker and the emitter are vendored byte-identical across every repository that publishes a door and are dependency-free, so the same job runs on a Next.js app and on a static generator with no install.
It also proves the charter is served, not merely committed: the AAO charter once returned 404 on nine of the estate’s ten live properties while the standard told everyone else to publish exactly that path, so the served copy is diffed against the root here.
That the door is well-formed, carries the notAuthority paragraph, and is actually served. Fetch it from the domain itself with `npx @flashyos/frontdoor-verify <domain>` — over https, with a timeout and a size cap — so a door cannot be proved by a redirect.
An organizational front door is a published file declaring which lanes an organisation opens to strangers, what it asks at each, and what it owes in return — verified from the applicant’s own domain over https, and normative that a rung buys a reply and never authority.
organizational front door →