Purpose
This page exists to define the shape of the future Registry interface without inventing a fake live API. It should make the integration boundary legible, not simulate product completeness.
Current truth
Increment 1 does not expose a live public Registry API.
That is intentional. The docs should stay ahead of confusion, not ahead of truth.
What future interfaces should cover
Future interfaces may include registration, identity updates, capability declarations, version references, lifecycle actions, owned-record management, and participation linkage.
Those surfaces should only be documented in detail once the underlying behavior is implemented and stable.
How this relates to SDK-first adoption
Over time, Registry should support an SDK-first developer motion: integrate from code, create durable records, then manage those records through the hosted Builder Area.
That is different from pretending the product is already a fully public, broadly documented API platform today.
What must be avoided
No fake endpoint lists. No invented schemas. No pretend auth flows. No example payload theater.
This page should remain useful precisely because it stays honest.
Implementation rule
Do not document endpoints, schemas, authentication flows, or request examples until the underlying product behavior is real and testable.