Domain experts
Make industry knowledge, operating experience, and decision criteria explicit. Define workflows, rules, and exceptions, and validate the method.
HomeRUNLUME / PLATFORM
Platform
Explore methodology productization, integration, provisioning, and ongoing operations through shared identity, lifecycle, entitlements, and authorized capabilities.
INDEPENDENT APPS. SHARED FOUNDATIONS.
Independent apps. A consistent foundation.
Runlume connects the use and operation of business SaaS. Teams get clearer access to apps; developers retain their products, code, and data. It is neither a business-code hosting service nor a database that absorbs every app.
Official apps
Ready-made business capabilities
Your own systems
Keep your code, data, and deployment
Third-party systems
Connect through contracts and permissions
Runlume.
IdentityEntitlementsConnectionsAgent coordination
Connect capabilities, not databases. Calls respect tenant, app-instance, and data permissions.
Explore platform capabilities and app responsibilities. Features, integration scope, and commercial rules follow the selected plan, configuration, and service agreement.
Explore communication and data standardsTHE SHARED FOUNDATION
The platform capabilities behind your business
Turning methods into lasting systems takes a shared foundation. Runlume brings together identity, app lifecycle, subscriptions, system connections, shared services, and security governance so business systems can evolve independently and work together.
01
Identity & workspaces
One sign-in. A clear view of the apps you can access.
Shared identity gives accounts, team membership, and app access a common starting point—not identical permissions. First-time users create their account by completing sign-in, without a separate registration page.
- Authenticate through one entry point, then enter the business apps you are authorized to use.
- Distinguish user identity, account membership, and app instances. One identity does not grant access to every workspace.
- The platform governs app access; each app still checks who can view or change its customers, orders, and other business data.
In a business scenario
A team member uses the same identity for CRM and Orders, while each app determines access to specific customers and transactions.
The boundarySigning in does not provision every app or grant access to all business data.
02
Application lifecycle
A clear application state, from provisioning to offboarding.
The platform manages ongoing use through app instances, not just launch links. Provisioning, suspension, recovery, and offboarding are requested through defined interfaces and tracked as operations.
- Map the app instance provisioned for an account to the business system’s own workspace.
- Use instance state to distinguish available apps, operations in progress, and suspended access.
- Track long-running and failed operations instead of treating a submitted request as completed work.
In a business scenario
When CRM is provisioned, the platform creates an app instance and CRM prepares its workspace. Availability follows the agreed completion result.
The boundaryProvisioning is not code hosting or server deployment. Offboarding data handling follows the app’s implementation and service terms.
03
Subscriptions & entitlements
Connect what you subscribe to with what you can use.
Plans, subscription state, features, and resource allowances need to agree. The platform associates commercial entitlements with app instances so apps can respect what is currently available.
- Organize purchases around products, plans, and subscriptions without assuming a mandatory five-app bundle.
- Separate access to a feature from the amount of a consumable resource available.
- Connect effective entitlements, reported usage, and billing records to support renewals and usage review.
In a business scenario
A subscription may include app features and resource allowances. The app performs the work; the platform manages the granted scope and usage records. Published plans determine prices and limits.
The boundaryCreating an account does not make every app free. Published terms determine plans, allowances, billing, and refunds.
04
Authorized connections
Let business workflows connect without merging databases.
Systems exchange capabilities and data directly through platform-authorized connections without routing every interaction through Agent. Agent uses the same capability contracts to coordinate systems. The platform governs callers, capabilities, tenant context, and permission scope.
- Providers declare interfaces or events; consumers use only the capabilities they have been granted.
- Create explicit bindings within an account. New interfaces or broader permissions do not automatically expand an existing grant.
- Trace collaboration through controlled calls and event delivery. Each app remains responsible for its own data and duplicate requests.
In a business scenario
CRM and Orders can collaborate through published, authorized capabilities. CRM provides customer references; Orders retains its transaction rules and fulfilment data. Actual workflows depend on available interfaces.
The boundaryNo shared business database, automatic cross-account access, or promise of cross-system transactions and instant synchronization.
05
AI & shared capabilities
Give shared technical capabilities a common foundation.
Apps also need AI, notifications, files, and other shared services. The platform provides common access and usage rules; each app decides how to apply them to its own business context.
- Platform-managed AI brings model access, permitted scope, allowances, and call records together without exposing platform model keys to apps.
- Notifications organize recipients and delivery status; business apps determine the trigger and intended audience.
- Access shared resources such as files within instance and authorization boundaries, according to the published capability catalog.
In a business scenario
A content app can use authorized platform AI for drafting, then apply its own review and publishing workflow. AI assistance does not replace editorial responsibility or publishing permissions.
The boundaryPlatform-managed AI and app-managed AI do not share the same billing path. Shared capabilities do not grant AI unrestricted access to business data.
06
Security & operations
Keep access, authorization, and changes within clear boundaries.
More apps make consistent governance more important. The platform connects accounts, instances, permissions, states, and operation records without replacing each app’s responsibility for its own data.
- Use accounts and app instances as isolation boundaries, with identity and calling context derived from verified authentication.
- Permission scope, entitlements, and instance state jointly determine access. A signed-in identity is not a pass to every interface.
- Record important operations and capability calls for review, without treating secrets and sensitive payloads as ordinary log content.
- Private business-system delivery uses a License to define permitted product versions, deployment environments, counts, and validity periods. Deployment licensing is managed separately from subscription entitlements and business access grants.
In a business scenario
After an app is suspended or a connection is revoked, subsequent access must satisfy the platform’s constraints. Operation and call records support investigation.
The boundaryShared governance is not a zero-risk guarantee or a certification claim. Apps still implement local authorization, isolation, and retention rules.
SHARED CONTRACTS. CLEAR DATA.
Independent systems. Shared communication and data standards.
The foundation covers more than app entry points: it standardizes authentication, API calls, data descriptions, and events. Contracts based on open standards help systems built with different technologies collaborate with less repeated interpretation and conversion work.
Standardized communication and event contracts
HTTP/JSON carries API calls, OpenAPI describes requests and responses, OIDC/OAuth 2.0 supports authentication and service authorization, and CloudEvents provides a consistent event envelope. Shared standards do not require apps to use the same programming language.
- Versioned interfaces define inputs, outputs, errors, and compatibility requirements.
- Event identifiers, sources, types, and payloads describe changes; delivery records and idempotency support traceable collaboration.
- Calls and event subscriptions remain subject to account, app-instance, and capability authorization checks.
The boundaryIntegration still requires adaptation, version checks, and authorization configuration. Standard protocols do not guarantee plug-and-play compatibility, exactly-once delivery, or real-time arrival.
Consistent data structures for analysis
JSON Schema describes exchanged fields, types, and validation rules, while API and event contracts identify versions, sources, and context. More consistent inputs can reduce format conversion and field preparation, supporting authorized aggregation, large-scale analytics, and cross-system metric comparisons.
- Exchange formats and description rules are shared; apps retain their domain models and independent databases.
- Align field meanings, time ranges, units, and metric definitions before analysis; structural consistency alone does not ensure semantic consistency.
- Select fields for authorized purposes and apply data-quality, retention, and appropriate de-identification controls.
The boundaryThis does not mean customer data is collected by default, tenants are merged, or a data warehouse is created automatically. Analysis tools, data scope, and metric calculations require configuration; results depend on data quality and methods.
RUNLUME AGENT
One assistant across your business systems.
Runlume Agent is the platform’s official unified assistant. Within tenant authorization, it uses the capabilities and data of systems you own to understand business context, proactively handle tasks, and follow through on results.
Meet your unified assistantOfficial unified assistant
SiteCMSGEOCRMOrders
Connect the systems you own—not just these five apps.
- Understand business across systems
- Act proactively and follow through
- Connect capabilities and data
CLEAR RESPONSIBILITIES
Shared operations. Independent expertise.
The goal is not identical business logic. It is a consistent foundation for collaboration.
| Area | Runlume handles | The app handles |
|---|---|---|
| Identity and access | Authentication, membership, and app access | Local user mapping, business roles, and data permissions |
| Provisioning and operations | Entitlements, instance states, and operation tracking | Workspace creation, business features, and service delivery |
| Data and collaboration | Capability contracts, explicit grants, and exchange records | Independent databases, domain rules, and data quality |
The five official apps put this foundation into practice. They do not define its limits.
COMMON QUESTIONS
Platform connections and data, explained.
Does a shared login grant access to every app and its data?
No. Shared identity provides a common sign-in entry. App access depends on the account, provisioned instances, and permissions. Each app still checks access to its business data, including customers and orders.
Do shared communication protocols require the same technology stack?
No. Runlume uses contracts such as HTTP, OIDC, OpenAPI, JSON Schema, and CloudEvents for identity, APIs, and events. Business systems retain their languages, frameworks, databases, and deployments, adapting the interfaces within their integration scope.
How do consistent data formats support cross-system analysis?
Consistent field descriptions, types, and validation rules help reduce conversion and preparation work. Analysis still requires aligned meanings, units, time ranges, and metrics, plus authorization for its purpose. A shared format neither automatically aggregates data nor guarantees conclusions.
Do consistent exchange formats require a shared database?
No. The shared rules concern interface exchange and descriptions. Business systems retain their domain models and independent databases, exchanging the required information through authorized APIs rather than replacing integration contracts with shared or cross-database access.
How does a private-delivery License differ from subscription entitlements?
A License validates private software deployment rights and can constrain product, version, environment, deployment identifier, count, and validity. Subscription entitlements define purchased features and resources. Neither replaces identity, app-instance permissions, or authorized connections; a License does not grant access to all business data.
What happens when privately deployed software is upgraded or its License expires?
Before an upgrade, check that the target version, environment, and deployment scale remain licensed, renewing or updating the License when needed. Define expiry effects, renewal, and maintenance in the delivery agreement. The SDK supports local public-key verification; this does not make external services available offline or instantly deliver revocation to disconnected environments.