What CAOS is
CAOS — Cloud Atlantis OS — is an application platform, not an application. It is not a CRM. It is the layer beneath a CRM: a metadata-driven engine that becomes a CRM, an ERP, a CMS, an e-commerce back office, a project-management tool, or a marketing system, depending entirely on the metadata installed into an org.
A fresh org is close to empty. It has an engine, a way to sign in, and nothing to show but a landing that says so. What turns that empty org into a working system is metadata — objects, fields, apps, pages, permissions, automation, a shell, a design system — deployed through the platform’s own tools. Two orgs running the identical engine can look and behave like completely different products, because the difference between them is entirely metadata.
The one idea to hold on to
Section titled “The one idea to hold on to”The engine and the UI are completely separate. The engine — the kernel — interprets metadata and enforces the rules. It ships no application screens of its own beyond a sign-in page and an empty-workspace landing. Everything else a user sees — the header, the navigation, every app, every record page, every setup screen — is metadata the engine renders, delivered by installable packages.
That single separation is what makes the platform general. Because no application is compiled into the engine, any application can be authored on top of it. Building on CAOS means writing metadata, not forking a product.
If you have used Salesforce, the vocabulary will feel familiar — objects, fields, record types, page layouts, list views, permission sets, apps — and that is deliberate. CAOS takes the parts of that model that developers rely on and rebuilds them on an open, engine/UI-separated core.
What you can build
Section titled “What you can build”- A data model — objects and typed fields, relationships, record types, validation, and computed fields (formulas and roll-ups), with a describe layer that lets an org be queried about its own shape.
- Logic — validation rules, record-triggered automation, and registered code for anything a formula cannot express, all running in one predictable save order.
- User interfaces — apps, tabs, page templates, pages, and components, assembled as metadata and delivered by packages. The shell itself (header, navigation, search, the app switcher) is a package that claims the shell capability.
- Security — additive permission sets and groups, field-level security, and sharing, all enforced by the engine on every read and write.
- Packages — versioned distributions that carry metadata and register platform capabilities, so an app, a shell, or a whole “org shape” can be installed into an org.
Two ways to build
Section titled “Two ways to build”You do not have to use the platform’s UI. There are two paths, and they use the same engine:
- With the platform UI — install the standard packages (a shell, setup, apps) and configure through screens that are themselves metadata. This is the fastest way to a working system.
- Headless — ignore the platform’s UI entirely and drive everything through the APIs from your own front end and infrastructure. Records, metadata, and configuration are all reachable over the API; the platform never requires you to render its screens.
Most real builds mix the two: the standard UI for administration, custom surfaces or headless integrations where a product needs them.
Where to go next
Section titled “Where to go next”- How the platform works — the engine/UI separation, packages and capabilities, and the single write path, in one page.
- Getting started — provision an org, sign in, and make your first change with the CLI or the API.
- The developer surface — the full map of what you author, and where each part is documented.
For the deep architecture of the engine itself — its services, the boot order, the caching model, the instance topology — see the separate architecture site. This guide is about building on the platform; that one is about how the platform is built.