Core, shell, and the three surfaces
How Auditmark's one codebase adapts to your industry, and the three apps that make up the platform.
Auditmark runs on one codebase for every industry vertical. Two layers (the Core Engine and the shell) combine to give any organization a platform that fits its terminology and workflow without requiring a separate product or a code fork.
The Core Engine
The Core Engine is the capability set every Auditmark organization shares: form definition and rendering, multi-participant real-time inspection completion, configurable report layouts, scoring, photo and GPS capture, offline sync, multi-tenant client account management, a white-labeled client portal, webhooks, and role-based access control. This code does not change between industries.
The shell
The shell is a configuration layer on top of the Core Engine. It is not a code fork or a separate product. One codebase runs all shells simultaneously.
A shell sets:
- the terminology used throughout the UI
- navigation defaults and which capabilities are visible by default
- default templates and integration presets
- portal defaults for what end clients see out of the box
Auditmark ships with two initial shells. You pick a shell during onboarding, and you can change it later in Settings. Changing the shell relabels the entire app for everyone in your organization.
| Shell | Typical terms |
|---|---|
| Compliance and food safety | Clients, locations, audits, inspectors |
| Site and energy inspection | Sites, inspections, engineers |
Shell is not a pricing tier
The shell controls terminology and onboarding defaults. The pricing tier controls which capabilities your organization can access. They are independent. Changing your shell does not change your plan, and upgrading your plan does not change your shell.
Configurable terminology
Because the shell controls terminology, the same concept can carry different names depending on which shell your organization uses. The table below shows every configurable term, its default, and how it appears in each initial shell.
| Concept | Default term | Compliance and food safety | Site and energy inspection |
|---|---|---|---|
| client_account | Client | Client | — |
| location | Location | Location | Site |
| inspection | Inspection | Audit | Inspection |
| inspector | Inspector | Inspector | Engineer |
| template | Template | Template | Template |
| finding | Finding | Finding | Finding |
These guides use the default terms: inspection, inspector, template, client, location, and finding. Where your shell uses a different word, substitute yours.
The three surfaces
Every Auditmark organization has three distinct apps, each with a different audience and purpose.
Admin
The admin app at app.auditmark.io is where the inspection company runs the platform. Admins build templates, schedule inspections, manage the team, configure client accounts, set up integrations, and review analytics across all clients. See the admin overview for details on each area.
Inspector
The inspector app is a mobile-first, offline-capable app that field workers use to complete inspections. Inspectors see only the work assigned to them. Multiple inspectors can complete different sections of the same form at the same time, with no merge step required. Changes sync automatically when connectivity is restored.
These guides are admin-focused and do not cover the inspector app.
Client portal
The portal is the view your clients use to track inspection results. It is read-only (with limited write access for corrective-action acknowledgment and sign-off where your workflow requires it). The portal is white-labeled to your organization's brand: clients see your name and logo, not Auditmark's. Portal users are never charged. The portal is in active development.
What to read next
- Admin overview: the sections of the admin app and the roles that use it.
- Developer reference: public API, authentication, and webhooks.