Automation Process is the machinery that lets XOM do work without an operator in the loop: named workflows an administrator can enable or run on demand, server-side functions that fire on events, and a synchronisation layer for keeping external systems in step. In the current codebase it is an admin control surface plus the backend jobs it dispatches.
01Where automation is controlled
XOM's admin panel is a slide-out overlay rendered inside the platform's layouts rather than a separate page route. Automation is one of its control modules, sitting alongside AI Moderation, Algorithm Control, Aware Settings, Content Moderation and Security.
The Automation Control panel lists workflows as { id, name, enabled } records and gives an operator three actions: fetch the current workflow list, toggle a workflow on or off, and execute a named process manually. Those actions map to a small client (automationAPI) with getWorkflows, toggleWorkflow and executeWorkflow, plus a separate AI client used to enable or run AI-driven processes. Errors surface in-panel rather than failing silently.
02What actually runs the work
XOM is built on Next.js 14 with output: 'export', so there is no server-side rendering and no middleware layer. All route protection is client-side through a ProtectedRoute component, and anything that needs to run server-side runs as a Firebase Cloud Function instead.
The functions that exist today do the recurring platform chores:
- notifications — push and email notification dispatch
- posts — post processing and event triggers
- listAuthUsers / backfillAuthUsers — admin-side account reconciliation between Firebase Auth and Firestore
- advancedProxy — a Gen2 HTTP function that fetches external pages and rewrites HTML, images, CSS, JavaScript, fonts and video embeds through the proxy, with caching and retry-on-failure
03The synchronisation contract
XOM's subsystem specification defines automation of external work as a distinct subsystem, API Bridge Sync, whose stated purpose is external integration, API orchestration and cross-platform synchronisation. Its defined steps are: register an external service in an integration registry, map data fields through a schema mapper, configure webhooks against an event listener network, define sync rules, set a polling frequency, choose a conflict-resolution and merge strategy, select sync endpoints, monitor sync health, and configure retry logic.
Three of those steps are specified as AI-assisted rather than manual: generating a connector for a newly registered service, optimising the sync rules, and configuring a platform connector. The rest are operator decisions.