Reliability and governance
Every control on what agents may do, the Activity log, versioning, and how Meerkats keeps data current and the system up.
Governance in Meerkats is the set of controls that decide what an agent may do, how far, and who has to say yes, plus the records that let you check it afterwards. Reliability is the set of practices that keep the data current and the system up. This page is the reference for both. Most of the controls are explained in depth elsewhere; the table links to each.
The controls#
| Control | What it does | Where it's explained |
|---|---|---|
| Approval by default | Every change starts as a proposal. Nothing runs without a person, unless you allow a specific rule and action type. | Approvals |
| Caps | Budget down ≤ 20% per change, up ≤ 50% per week, bids ≤ 15%, bidding changes 14 days apart. Apply in every mode. | Actions and limits |
| Risk classes | None, low, medium, high. Medium always needs approval; high asks twice. The class, not the predicted return, sets the friction. | Actions and limits |
| Protected entities | Anything marked protected in the goal frame is never changed automatically. | The context layer |
| Live re-check | Before applying, the target is re-read. Drift aborts and re-proposes. | Stateful automations |
| Read back | After every write, the object is read back and compared with the plan. A difference stops the plan. | Stateful automations |
| Rollback | Every change stores the value it replaced. Undo from run history. | Run history |
| Earned autonomy | Auto mode is recommended only when an action type's predicted-vs-actual record clears an accuracy bar. | Stateful automations |
| Access levels | Read Only can see; Read & Write can approve and build; only the owner shares. | People and roles |
| Isolation | Row-level security per workspace. No data, context or history crosses a workspace. | Workspaces |
The Activity log#
Every workspace keeps an activity log: who did what, when. It is separate from run history, which is per agent; the Activity log is the account-level record, and it also logs every API call against the workspace.
- Open it
Select your name at the bottom of the sidebar, then Workspaces, then the share icon on the workspace. The Activity log is below Shared With.
- Filter
All activity, Access & sharing (invitations, level changes, removals), Data changes (connections, resyncs, uploads, deletions) or Automation (rules created or changed, proposals decided, actions executed, rollbacks).
- Read an entry
Each line shows the event, the actor (a person's email, or the app whose API key was used), and the time. API calls show the method, path and status, for example
POST /api/v1/metrics/query → 200. - Load older
Select Load older at the bottom. The log is kept for the life of the workspace and can be exported.
Who did what#
Three records answer the question, from different angles.
| Question | Where to look |
|---|---|
| Who approved this change, and on what evidence? | The run in Agents run history: proposal, approver, time, before and after |
| What did this agent do last month? | Agents run history, filtered by the agent |
| Who was given access, and when? | The Activity log, filtered by Access & sharing |
| What did this API key do? | The Activity log: every call, with the app as the actor |
| What did we approve last week, and did it work? | Inbox Activity on the Agents page |
Every decision is recorded against a person with Read & Write access, or against the app that holds the API key. There are no anonymous actions.
Goal frames and protection#
The goal frame is where you tell Meerkats what it must not touch. Mark a campaign, product or account as protected and no rule changes it, whatever its mode. Set caps tighter than the defaults if you want. Declare a learning phase on a new campaign and edits are frozen until it ends, with the date shown. The frame is proposed by Meerkats from your data and confirmed by you; agents read it on every run. See Goals and conventions.
Versioning#
- Rules and agents keep a version history. A change creates a new version; runs record which version ran.
- Metric definitions are versioned. A report from before a change shows the definition in force then, and says so.
- Documents you upload are versioned on replace. Agents use the newest; older runs cite the version they read.
Reliability#
Keeping data current#
- Every sync run is logged with its status in Sync History (Data Hub › Bronze Layer). Failed syncs are retried and shown; a connection that needs you shows needs attention on Integrations.
- Meerkats stays within each platform’s API limits and backs off when a platform is slow or rate-limiting, so a busy day never gets your account throttled.
- Agents never present stale data as current. A stale source is labelled with its sync time and a refresh is triggered.
Keeping the system up#
- Databases are backed up daily and can be restored to a point in time.
- Agent behaviour is tested against a fixed set of cases before any change to the engine ships. A failure found in production becomes a case in that set.
- A run that cannot finish says so, with what it needs. Every state in the engine names who owns the next step: the agent, you, or the system waiting for something named. No run ends silently.
Model changes
When a platform silently redefines a metric (a new attribution model, a changed eligibility gate), a step change on that date is treated as a model change, not a business change. Meerkats keeps a per-platform changelog and rebaselines across those dates, so a rule doesn’t fire on an accounting change.Export your records#
Run history and the Activity log export as CSV or JSON from their pages. Reports export to Excel from Cross Platform Reports, and to CSV from Product Revenue and the Gold Layer tables. Over the API, GET /automations/{id}/runs and GET /agents/run-history return the same records.
Troubleshooting#
An action ran that I didn't approve
Open the run in Agents run history. It shows the mode: either a person approved it (named), or the rule was in auto for that action type. Switch the rule back to suggest if you want every change proposed.
I need to prove who changed a budget
The run shows the approver and the time; the Activity log shows the same event under Automation. Both export.
A protected campaign was changed
Only a person can change a protected entity, directly in the platform or by approving a high-risk proposal after its second confirmation. The run or the Activity log names them.