Define
Identify what remains in the existing system, which Aerellus service is required, and the operational result the call must produce.
Aerellus / Command-1 Developer Documentation
Call the capability. Keep the environment.
Command-1 is the service-command architecture beneath OVRSYT. OVRSYT uses it to compose Aerellus services into a complete operating environment. Approved developers use the same architecture to introduce a specific Aerellus capability into systems that already exist.
Controlled access
Architecture / public
Services / entitled
Contracts / authenticated
Access Model
Access is defined around an integration boundary: the calling system, required service, identity model, data posture, event behavior, and deployment environment. Approval grants access to that boundary—not to Command-1 as an unrestricted utility layer.
Review
Aerellus evaluates the organization, environment, data movement, identity posture, technical fit, and requested service scope.
Provision
Approved developers receive environment-specific credentials, service entitlements, exact contracts, and integration materials.
A review request does not create access, partnership, license, approval,
or developer credentials. Provisioning occurs only after Aerellus approves
the organization, use case, service boundary, and deployment environment.
System Architecture
Command-1 sits between the calling surface and the Aerellus service being executed. OVRSYT is its complete native implementation. External systems enter through the same command architecture but receive only the services and operations entitled to their environment.
OVRSYT consumes Command-1.
Identity, work objects, communications, scheduling, transfers, live sessions, events, and audit operate together through Command-1 as one deployment-ready environment.
External systems consume services.
An established platform can call one Aerellus capability—or a coordinated set—without replacing its application, workflow, data model, or user surface.
Command-1 is the architecture. The API defines its service interfaces.
The SDK provides supported client tooling. Events return service movement,
and the authenticated developer workspace governs credentials,
environments, entitlements, contracts, and integration logs.
Authentication
Authentication is a service boundary, not merely a login screen. A client surface can use Command-1 Identity to authenticate a user, establish deployment context, issue a session, return authorization state, and place the client backend behind that decision.
Client sign-in surface
→ Command-1 Identity
→ verify approved application and environment
→ authenticate principal
→ establish session and authorization context
→ record security and audit events
→ return approved state to client backend
Exact protocols, token handling, scopes, and environment
values are issued inside the authenticated developer workspace.Service Catalog
Aerellus services are independently callable but share a common command model. Availability is determined by deployment and entitlement. Exact operations, schemas, limits, and versioned routes appear in the authenticated reference for each approved service.
Identity
Access boundary
Authentication, session issuance, authorization context, deployment validation, and security events for OVRSYT or an external backend.
Scope
Operational objects
Structured work objects, relationships, ownership, status, and the operational context organizing activity around the work.
Blackline
Controlled transfer
Document transfer, recipient challenge, release, custody events, expiration, and removal inside an existing workflow.
KADENCE
Scheduling and events
Availability, scheduling, deadlines, and operational events that can be coordinated inside OVRSYT or another application.
Threshold
Controlled live sessions
Live-session capability governed by approved participant, authorization, and deployment boundaries.
Relay
Operational communication
Communication tied to the records, people, permissions, and deployment context surrounding the exchange.
Event Delivery
Command-1 returns meaningful service movement to the system around it. Events allow an external application to react to approved state changes without polling broadly or receiving visibility outside its entitlement.
Every entitled event identifies:
delivery unique event and delivery references
service the Aerellus service that produced the event
environment the deployment boundary in which it occurred
resource the entitled object or operation affected
action the meaningful state change
time when the service recorded the change
context actor, source, and authorized metadata when applicable
Exact event names, payload schemas, signing requirements,
retry behavior, and delivery endpoints are service-specific.
Event subscriptions follow the same boundary as service access. An
integration can receive only the event families, environments, resources,
and visibility approved for its credentials.
Provisioning
Provisioning converts an approved operating boundary into a technical one. Aerellus defines the organization, environment, services, operations, event families, credentials, and documentation available to the integration.
Boundary
Confirm the calling system, deployment environment, users, data posture, and the architecture that must remain in place.
Entitlement
Assign the approved services, operations, scopes, event families, and environment-specific visibility available to the integration.
Credentials
Issue the appropriate credentials, exact API or SDK references, event requirements, configuration values, and operating limits.
Define the capability and the boundary.
Begin with the existing system, the Aerellus service it needs, and what should happen when the service returns. Do not include classified, privileged, regulated, or sensitive client information in the initial request.