Membership and admission as scoped authority.
VEIL is the YuraMesh policy and credential layer. A Candidate has requested admission; a Member holds a signed, scoped and expiring membership certificate. Invitations are single-use and expiring, device proof is required, and delegated scope cannot escalate.
YuraMesh v0.4 is a coordination specification. Native v1 remains operational and authoritative. YuraMesh production implementation is not authorized.
VEIL — Verified Encrypted Identity & Layered Admission belongs to a larger control plane.
The v0.4 design separates YuraMesh membership from Native transport. A Native session without a signed association is not YuraMesh-authorized; a membership certificate without active Native transport is not transport-authorized.
Its authority is intentionally bounded: identity, transport, naming, discovery, ownership and data protection are related without becoming interchangeable.
Input state
Explicit identity, record or transport context enters the component.
VEIL — Verified Encrypted Identity & Layered Admission
Invite → device proof → scoped membership
Scoped next state
Only the authority and lifecycle signal defined by the design may continue.
Invite → device proof → scoped membership
VEIL models admission as an explicit state transition. A candidate receives an expiring invitation, proves control of an eligible device, and receives bounded membership authority. Revocation and expiry remove authority without implying that the underlying transport disappeared.
That boundary is the reason this component is named separately: it can evolve, be reviewed and be revoked without silently granting unrelated powers to the rest of the ecosystem.
Evidence status
Grounded in YuraMesh protocol specifications and phase-one audit material found in the authorized workspace. This page describes a specified or proposed architecture, not a claim of production deployment.
Trust boundary
Implementations must verify signatures, scope, expiry, replay, sequence and revocation according to the applicable specification. Reachability, DNS, TLS or Native success alone cannot establish the authority described here.
Relationship to current YuraNetwork
Native v1 remains unchanged and authoritative. Any future adapter must preserve its transcript and be separately reviewed. YuraCore may eventually expose lifecycle and readiness context through defined interfaces; that interface is not yet a public production API.