Work with a name.
A capability is a reusable kind of work software can ask The Lyre to perform. An application names the work it needs; a provider supplies an implementation.
A contract describes the exchange.
Capability contracts publish a version, request and response schemas, and execution metadata. Callers can inspect these declarations and choose a version without embedding a particular provider into their application.
The public catalogue exposes those declarations. A schema describes the expected exchange; it is not a promise that every possible constraint is enforced at runtime.
Providers do the work.
A provider publishes an implementation of a capability and declares which contract versions it supports. The Lyre routes requests to a matching provider service and returns the result to the caller.
How a request is resolved
The current resolver considers stable contracts and enabled providers whose services are connected and support the requested version. A caller can pin a provider or contract version.
Among eligible candidates, resolution prefers the highest contract version, then the highest provider priority. Equal candidates are selected randomly. If no provider qualifies, resolution returns an error.
A published or enabled provider is not necessarily connected. The public catalogue shows publication state, not live connection health.
Identity belongs to The Lyre.
Human accounts, sessions, MFA state, organizations, services, and provider records belong to the underlying system. Lyre Web displays and mediates access to them.
A Lyrinox Account is a human identity. Trusted services can request a sign-in handoff through The Lyre without receiving the user’s password. Organizations group membership and publishing authority; access is enforced by The Lyre.
Agents have their own identities.
Agents register as non-human principals and authenticate with API keys. They can discover and invoke capabilities, but cannot use human-only identity, MFA, or administrative operations.
Different interfaces. The same system.
LyreSDK and RDGProto
RDGProto is The Lyre’s native protocol. LyreSDK provides application-facing primitives over it, so native applications can work with the system through a library.
Lyre Web
This website is the human interface. It depends on The Lyre for account access and system data; The Lyre exists independently of it.
The HTTPS adapter
Generic clients and agents can send HTTP/JSON to the gateway. It translates requests into RDGProto and translates responses back. It is an access path to the same capabilities and identity system.
Software using The Lyre.
Lyrinox products are examples of connected software. Market handles listings, licensing, and purchases. Forge assembles project-specific SDK artifacts. Both can use The Lyre’s identity and capability infrastructure.
The underlying idea applies beyond those products: software asks for work through a shared capability rather than being built around one implementation.
Explore published capabilities →