Atlas is a business modeling platform built from two engines that share one data model. Enginuity models your business and runs its operations; Uniform turns that model into forms people fill in and documents you can hand out.
Knowing which engine does what makes the rest of Atlas easier to understand.
Enginuity: data and operations
Enginuity is where you shape your data model and put it to work. It covers:
- Classification modules that model your business, nested the way it actually works.
- Reusable schemas — data schemas and record schemas — that define what you keep on file.
- The File System that organizes modules, topics and records.
- Samples and aggregations for measurements captured over time.
- Pipelines — checklist-gated workflows that move records through named stages.
- Work queues — role-scoped work that anyone on the right team can claim.
- Notification rules that tell the right roles when something happens.
Uniform: forms and documents
Uniform is how people put data into Atlas and get documents out. It builds on the same schemas you define in Enginuity, so a form and the record it creates always agree. It covers:
- Declarations — Uniform’s name for a form definition, bound to a record schema.
- Field controls such as text, checkbox groups, references to other records, file uploads and repeatable entries.
- Public intake forms — guided, multi-step forms for people outside your organization.
- Review of submissions before they become records.
- Document templates, designed in a Layout Editor with placeholders bound to schema fields.
- Document generation, filling a template from a record’s live values.
Why one shared model matters
The key design choice is that both engines use the same schemas. A schema defined in Enginuity is the same schema Uniform builds forms and documents from. That’s what makes Atlas’s core promises possible:
- Forms and records can’t disagree, because the form is generated from the record’s schema.
- Documents stay in sync, because templates bind to a schema version rather than to a copy of the data.
- Validation is consistent, because the rules live in one place.
- APIs see the same model, so applications built on Atlas read and write the same records the interface does.
You don’t have to use both at once
Atlas’s documentation notes that many teams start with just schemas and forms and add pipelines once their process stabilizes. The tiers reflect that: Basic and Advanced center on schemas and forms, and Enterprise opens up classifications, security policies and the operational side of the platform.
Which engine am I using right now?
A quick way to orient yourself:
| If you’re… | You’re in |
|---|---|
| Defining fields that belong together | Enginuity (data schemas) |
| Composing a record type | Enginuity (record schemas) |
| Browsing modules, topics and records | Enginuity (the File System) |
| Building a form and laying it out | Uniform (declarations) |
| Publishing a public intake link | Uniform |
| Reviewing submissions | Uniform |
| Designing a document template | Uniform |
| Moving records through stages | Enginuity (pipelines) |
| Claiming work from a queue | Enginuity (work queues) |
The dividing line is roughly: Enginuity is about what your data is and how it moves; Uniform is about how people put data in and get documents out.
How a single piece of information travels
Following one field shows how the engines cooperate:
- Enginuity: you define Service Address as a data schema and publish a version.
- Enginuity: you compose a Property Profile record schema from it.
- Uniform: you build a form (a declaration) that collects the same schema, and publish it as a public form.
- Uniform: a customer submits; the answers are validated against the same schema.
- Enginuity: the record lives inside the topic it belongs to, and a pipeline routes it through review.
- Uniform: a document template bound to that record schema version generates a work order.
At no point was the address defined twice.
Why the split exists
Separating the two engines keeps each one focused, while the shared model keeps them consistent:
- Data modeling doesn’t have to think about layout. Schemas describe information; forms and templates decide presentation.
- Presentation can change freely. You can redesign a form or a document without touching the data model.
- Operations sit with the data. Pipelines, queues and notifications work on records, where the structure and permissions already are.
Frequently asked questions
Do I need both engines? No. Many teams start with schemas and forms and add pipelines once their process stabilizes.
Which tiers include which engine? Basic and Advanced center on schemas and forms; Enterprise adds classifications, security policies, and the operational and API-driven parts of the platform. See pricing.
Is “declaration” the same as “form”? A declaration is Uniform’s name for a form definition bound to a record schema.
What is a namespace? A permission-scoped workspace, so declarations, templates and documents are visible only to the teams that should see them.
Learning the platform in the right order
If you’re new to Atlas, learning the two engines in this order tends to work best:
- Data schemas (Enginuity) — the vocabulary everything else uses.
- Forms (Uniform) — see your schemas collect real information.
- Public forms and submissions (Uniform) — governance and identity capture.
- Classifications, topics and records (Enginuity) — organize what you collect.
- Security policies and ownership (Enginuity) — decide who reaches what.
- Pipelines, queues and notifications (Enginuity) — automate the process.
- Templates and documents (Uniform) — produce what you hand out.
- APIs — build your own interfaces on the model.
Each step is useful on its own, and each builds on the one before it.