The Veil
A request arrives with Host, path, method, headers, and claims about its origin. The edge must
reject, canonicalize, or map those values before they reach an application. Veil is the optional
hostile-ingress Extension Domain outside the Vessel: it terminates TLS, handles protocols, admits
routes, and sends canonical metadata to an independently guarded backend.
Veil is Designed; State of Work owns its delivery boundary. Until the local browser boundary changes, keep the Vessel and Altar on the same host—without an ad hoc reverse proxy, tunnel, or port-forward.
Admit the edge
ADR 40 selects Caddy as the default managed engine. An external edge remains possible, but no compatibility profile ships.
Remote exposure is opt-in per route. Typed Runes name the host or route, backend, protocols, limits, application-authentication preconditions, and exposure tier: public, through Tether, or local. Everything else stays closed. The design rejects ambiguous or overlapping ownership, unknown backends, non-admitted ports, and raw directives. Contributions cannot shadow Core, remove authentication, expose a database or model API, select an arbitrary upstream, or create a forward proxy. The complete configuration retains attribution and passes Caddy validation in staging before transactional inscription.
Caller-supplied forwarding, identity, and client-certificate claims are discarded. Canonical scheme, host, origin, and peer metadata may cross only an authenticated backend path the Vessel explicitly trusts. That is designed behavior, not today's loopback service.
Gateway
Veil may share the Core host or run on an optional separate Gateway Host. The reference placements Home and Remote move the same typed ingress boundary onto operator-controlled local iron or an off-site host respectively. They do not create another Extension Domain or application authority. Home uses an exact local backend road; Remote may add one Tether peer and route. In both, the Core accepts only the declared Gateway identity and port. Policy outside the Gateway host—a router/firewall, L3-switch ACL, or cloud-network rule—plus the receiving Core firewall enforces that narrow zone; local Gateway rules are defense in depth. The Gateway receives no general LAN route, database, Context, Sigil, provider credential, or host-control path.
Reach route profiles
The Reach deployment matrix uses no Veil for
home-only or standalone outbound VPS. The split
reach.edge-home.public@1 profile
binds a private home Veil only to its Tether address. Later profiles expose a closed set rather
than a catch-all:
| Surface | Backend and admission |
|---|---|
| Reach edge relay | private Tether-only event-admission, delivery-claim, delivery-settlement, and health routes to an isolated adapter; current edge Principal, epochs, bounds, replay fence, and Ward policy |
| public-safe Agent Card | GET on the adapter-pinned well-known path; public metadata only; no implied trust or enrollment |
| callback-only client | exact authenticated route to isolated Intercom ingress; existing outbound task/token correlation, replay fence, current authorization, and durable admission |
| full A2A server | separate Intercom server ingress with Ward, inbox/outbox, Workers, quotas, and result path |
| unauthoritative health | local or Tether-only until remote Ward IAM ships; no generic control route |
| Altar, database, model API, corpus writer, Reach core, Discord edge, egress gate, container or host control | closed; no Veil contribution is admissible |
Each admitted route pins methods, media, compressed and expanded size, JSON work, authentication, stream/time limits, exposure tier, backend, and adapter revision. Veil holds certificate and route material only. It never receives bot/provider/A2A application credentials or a path from hostile bytes to Discord delivery.
Keep authority behind the route
TLS authenticates an endpoint and protects bytes; routing selects a destination. The Ward
and Vessel still authenticate the caller and authorize the exact object and effect. mTLS, arrival
through Tether, or forwarded metadata may supply evidence, but cannot mint a Sigil, create an
administrator, or make the fixed bootstrap magus:* identity valid remotely.
An A2A Agent Card, Scroll, or teaching bundle remains application material after crossing Veil. Veil may expose the admitted Intercom route locally, through Tether, or eventually publicly; it cannot validate Spell compatibility, approve teaching, admit a casting, or settle its Run.
Before a browser-facing listener opens, Host and Origin admission, DNS-rebinding defenses, secure sessions, local assets, request bounds, and protected diagnostics must pass hostile tests. State of Work records the present failures; Security owns the deeper boundary. Proxying and TLS leave those duties intact.
Veil may impose coarse traffic limits; egress, application validation, and complete DDoS defense remain elsewhere. The edge receives only a narrow path to registered HTTP backends, never database, model, Reactor, systemd, container, application-secret, or arbitrary-egress authority.
Fail without opening another path
The design detects listener and route collisions before change. Certificate state and account keys stay within declared durable and secret boundaries. Each transition validates before activation and retains the prior projection for restoration. Renewal failure preserves the last valid configuration while readiness degrades before expiry. If ACME prerequisites fail, the public Veil stays unavailable while the local Vessel continues. Reconciliation closes removed routes.