Audit Logs And Control Data

Onumia keeps its own operational state in a small set of dedicated control tables rather than scattering it across WordPress options. This separation is deliberate. When Onumia clones the database into a sandbox, it must be able to copy your real site content without dragging along Onumia’s own control plane, and it must be able to record an audit trail that survives independently of any single sandbox. Keeping sandbox records, the activity log, and settings in their own tables is what makes that possible.

Control Tables

Onumia creates three control tables, each prefixed with your site’s WordPress table prefix. On a standard install with the wp_ prefix you will see wp_onumia_sandboxes, wp_onumia_logs, and wp_onumia_kv. The prefix is resolved from the live WordPress configuration, so the names match whatever your installation already uses, and they can be overridden with the ONUMIA_HOST_TABLE_PREFIX constant when needed.

Table	Purpose
onumia_sandboxes	Sandbox records and their lifecycle state.
onumia_logs	The audit and activity log: tool calls, command execution, settings changes, promotion stages, and rollback artifacts.
onumia_kv	Key-value control data such as role capabilities, sandbox defaults, the schema version, and per-user Workspace preferences.

Because these tables hold the control plane rather than site content, sandbox cloning treats them as off-limits. A sandbox sees a copy of your posts, options, and other WordPress data, but it does not see or mutate Onumia’s own bookkeeping.

Sandbox Records

Each row in onumia_sandboxes describes one unit of work: its owner, its current lifecycle status, the isolated database and files it uses, a time-limited preview link, an optional label, and timestamps. When a sandbox is promoted or discarded, the record also notes how that happened.

This is the data that lets several people or agents work against the same WordPress site at once. Each sandbox is fully described by its own row, so Onumia always knows which database state, code checkout, and preview belong to a given task.

Key-Value Store

The onumia_kv table holds Onumia’s settings and a small amount of per-user state. It stores the control schema version, the role capability map that governs what each WordPress role is allowed to do, the sandbox defaults that control TTL and clone limits, and each user’s personal Workspace preferences, kept separate per user and never copied into a sandbox.

What The Activity Log Captures

The onumia_logs table is Onumia’s audit trail and activity feed in one. Every record is anchored by an operation ID, with an optional parent ID so related events can be grouped, and a UTC creation timestamp. Each entry identifies the actor’s WordPress user ID and, where relevant, the sandbox it acted on. The event itself is described by an event type, an optional tool name, a status, a severity, and a human-readable message.

Alongside that metadata, Onumia stores the richer payloads that make a log useful after the fact: a context object, the full input and output of the operation, any error payload, before and after state, and revert data for operations that support targeted rollback. Where it can, Onumia records the complete MCP tool input and output, so an audit review can reconstruct exactly what an agent was asked to do and what it returned.

Events That Are Logged

Onumia writes to the activity log across the full lifecycle of agent work, not just at the moments where data changes. It records control table initialization, sandbox creation, preview generation, and sandbox discard. It records command execution against a sandbox, including completion and failure, and it records when a sandbox database mutation is captured. It records each stage of promotion, and it records settings changes and resource reads.

Database merges are logged in particular detail because they touch live data. Onumia records scan events, updates to the staged change selection, the preflight check, the apply step, and any rollback. Together these events give you a continuous record of how a change moved from a sandbox toward the live site.

A Note On Sensitive Data

Because Onumia deliberately logs tool input and output to give you a faithful audit trail, anything an agent passes through a command can end up stored in onumia_logs. Treat the activity log as sensitive operational data, and avoid sending values you would not want persisted: passwords, API keys, access tokens, payment details, customer private data, or any personal data the task does not actually require. The safest habit is to keep secrets out of agent commands entirely and let server-side configuration supply them.

Revert And Rollback Data

Some events carry a revert payload. For database merge apply operations in particular, Onumia stores rollback artifact metadata in the revert payload so a promotion can be undone with row-level precondition checks. This supports a targeted rollback workflow where you can reverse a specific promotion rather than restoring everything. It is a convenience built on top of the audit trail, not a substitute for full site backups, and you should continue to keep independent backups as part of normal operational discipline.