How Trellis Governs Automated Changes: Audit Trails, Approvals, and Change History
When automation touches your bids and budgets, the question that matters in a review is whether you can show what changed, who approved it, and why. If you can't, every automated change is a liability someone has to explain from memory.
Most operators have been on the wrong end of that conversation. Spend moved, ACoS shifted, and the only record is a dashboard that shows the result but not the decision. Governance is the discipline of making sure the decision is on file before anyone asks for it.
This post covers what a defensible record of automated changes needs, how Trellis produces one across Qinetix and Qore, and where the record stops.
Quick Answer
- Three things govern automated changes in Amazon Ads: a change history at the campaign and target level, approval controls that decide which actions a human must sign off, and logic you can read, so the 'why' exists as something other than a model's judgment.
- Qinetix provides per-campaign history logs, change annotations, and per-target bid history.
- Qore lets operators set which actions require approval, defaults actions to manual approval, and runs locked skills whose logic is visible as a graph.
- Together they let a team reconstruct a change: what moved, under which rule, and who signed off.
- The upside and the risk: automation you can scale and defend, against a first audit or client question you cannot answer.
Why automation without a record fails the first audit
The gap between a result and a decision
A performance dashboard tells you spend rose on a campaign. It does not tell you which rule raised the bid, what the ACoS ceiling was that week, or whether a person authorized it. Reconstructing that from exports and Slack threads takes hours, and the answer is often 'we think so.'
Who asks, and when
The questions arrive from predictable places: a client questioning last month's spend, a finance lead asking why a budget moved, an agency principal reviewing a junior's account, a teammate inheriting a portfolio. Each one needs the same three answers, and each one arrives after the fact. For teams that have already been burned by automation, this is the objection that stalls adoption, and it is a fair one.
The same record that defends a change is also how you find the next dollar
Defensibility is the first reason to keep a record, and it is not the only one. A change history is the feedback loop that optimization runs on. When you can see that a bid moved on Tuesday and ACoS fell on Thursday, you can attribute the result to the change rather than to the week's traffic, keep what worked, and reverse what did not. Without that record, every adjustment is a one-off you cannot learn from, and the wins never compound.
That is where the dollar sits. A team that can tie a performance shift to the specific change that caused it stops repeating the moves that lost money and leans into the ones that made it. Over a quarter, the account that keeps a clean record out-optimizes the one that cannot, not because its operators are smarter, but because they can tell which of their decisions actually worked. The record pays for its own friction in better decisions long before it earns its keep in a review.
What a defensible change record contains
An audit trail worth the name answers five questions for every automated change. If your tooling can't, you have logs, not governance.
- What changed: the object (campaign, target, bid, budget) and the before and after values.
- When: timestamped, so it lines up against performance shifts.
- Under what logic: the rule, algorithm, or skill that produced the change.
- Within what limits: the guardrails that bounded it, such as an ACoS range or a down-only bidding default.
- With whose sign-off: whether a human approved it or the rule was pre-authorized to run.
The table below shows how three common setups hold up against those questions.
| What you need to show | Manual edits and spreadsheets | Opaque automation | Governed automation (Qinetix and Qore) |
|---|---|---|---|
| What changed | Only if someone logged it | Often summarized, not itemized | Per-campaign history log and per-target bid history |
| Why it changed | Lives in the operator's head | Model judgment you can't read | Selected algorithm and rules, plus change annotations |
| Who approved it | Implicit, since the person made the edit | Usually no approval step | Approval gates you configure per action type in Qore |
| Limits in force | Whatever the operator remembered | Set by the vendor | ACoS floor and ceiling, learning phase, down-only bidding default |
| Effort and speed | Best for one account; falls apart across a roster | Fast, with no accountability | Approval steps add friction where you choose to place them |
The last row is the honest cost. Governance is not free: every approval gate you add is a human who has to respond. The point is that you decide where that friction sits.
How Qinetix records what changed and why
Qinetix is the platform that moves bids and prices at volume within guardrails. Its record of that work has three layers.
Per-campaign history and per-target bid history
Each campaign carries a history log, and each target carries its own bid history. When a keyword's bid moved on a given day, you can see the movement rather than infer it from a spend curve. Change annotations mark shifts on the timeline, so a performance change lines up against the adjustment that preceded it.
The algorithm and its limits are named, not implied
Qinetix offers six selectable algorithms (Product Launch, ROAS Boost, GrowthMax, SmartSpend, Placement Max, and Rules Only), and the operator picks per campaign. That matters for governance because 'why did the bid move' has a named answer: the campaign ran ROAS Boost with a 30-day lookback, inside a set ACoS range, rather than 'the algorithm decided.'
The boundaries are recorded settings too. The ACoS range is a floor and a ceiling, a bidding zone rather than a single target. A 7-day learning phase holds new campaigns back before optimization begins, and Down-Only bidding is the default. Rules run in parallel with algorithms, and the operator sets where automation ends and manual logic begins for each campaign.
The Bid Simulator as a pre-change check
The Bid Simulator lets an operator test a bid change before committing to it. It is a preview, not a record, but it serves governance: the reviewer sees the expected effect before the change is made, not just the outcome afterward.
How Qore puts a human in the loop for actions
Qore is where you turn an analysis or review you run by hand into a workflow that runs itself. Q, the assistant, helps you describe the workflow and assembles it as a visible node graph. You review the graph, lock the skill, and it runs the same way each time.
Approval is configurable, not all or nothing
Actions in Qore, such as bid changes, pauses, negations, and budget moves, default to manual approval. Operators configure which actions require sign-off and which can run automatically, so a team can let low-risk negations run on a schedule while a budget move waits for a person. Autonomy is available once you trust a skill; approval is the starting posture, not a ceiling.
The boundary is explicit: plans cannot spend or take actions on their own, and approval never licenses spending. Automated chat surfaces such as scheduled Slack monitors are read-only by default. Where Q stages a change, it appears as an approval card attached to the task, and tasks close only when a person changes the status.
Locked logic is the answer to 'why'
The strongest governance property of a locked skill is that the logic is fixed and visible. There is no language model making a fresh judgment at runtime, so the same inputs produce the same outputs. When someone asks why a change happened, the answer is a node graph you can open and read, and the same graph will make the same call tomorrow. That is the difference between explaining a decision and defending a guess.
What to do if your current automation can't produce a record
If you are already running automation that shows results but not decisions, you have practical options before changing tools.
- Export what exists and freeze a baseline. Pull your current campaign settings and change history so you have a dated starting point.
- Write the approval policy on paper. List the action types (bids, budgets, negations, pauses) and mark which need a person and which do not.
- Ask your vendor five questions. For any change, can they show the before and after, the timestamp, the logic, the limits, and the approver? Ask for a demonstration on one of your own campaigns, not a sample account.
- Keep a manual change log for high-stakes moves until the tooling catches up. A shared sheet with date, object, change, reason, and approver is better than nothing.
- Review on a cadence. Our Amazon PPC audit workflow is a starting point for a recurring review.
Where the record stops
Governance claims should carry their limits, so here are ours.
- Qore is in beta. Its analytics and insight stand on their own, and it can carry out certain approved actions directly, including an auto-run state once you trust a skill, so it does not require Trellis to be your bid manager of record.
- A change history documents what the system did. It does not judge whether the strategy was right. A well-recorded bad decision is still a bad decision.
- The approval step is only as strong as the person clicking it. Gates that get approved in bulk without reading are a formality.
- We haven't claimed a specific retention window or export format here. If your compliance team needs one, ask for it in writing during a walkthrough.
Conclusion: the audit trail is what makes automation safe to scale
Automation earns wider trust when its changes are provable. Qinetix keeps the campaign and target-level history, names the algorithm and limits behind each move, and previews changes before they land. Qore keeps a person in charge of which actions run alone and which wait, and its locked, readable logic answers the question of why. The teams that scale automation are the ones who can hand the record to a client, a finance lead, or a new hire and let it speak.
If you're weighing automation and need to know what your review process would look like, see how Qinetix and Qore work together or book a walkthrough on one of your own campaigns, and ask us to show the change record.
Frequently Asked Questions
An Amazon ads audit trail is a dated record of every change to campaigns, bids, budgets, and targets, showing what changed, when, under what logic, and who authorized it. Amazon's console shows some change history, but a complete trail also needs the reason and the approver.
Standardize the fields (date, object, before and after values, reason, approver) and capture them in one place. Platforms that log changes per campaign and per target do this automatically. Without one, a shared change log reviewed weekly is the minimum.
It means deciding in advance which automated actions may run alone, which need human approval, what limits bound every change, and how each change gets recorded. Approvals, guardrails, and inspectable logic are the three working parts.
Actions default to manual approval. Operators configure which actions require approval and which can run automatically, and autonomy is available once you trust a skill. Plans cannot spend or take actions on their own.
Qinetix keeps per-campaign history logs, change annotations, and per-target bid history, and each campaign runs a named algorithm inside a set ACoS range. That gives you the movement, the timing, and the logic in force.
Yes. Q assembles a skill as a visible node graph, and once you lock it, it runs deterministically without a language model at runtime. You can open the graph to see what it does.
No. A record makes review faster and more reliable, but it does not judge strategy. Someone still needs to read it.
Ask for a live demonstration on one of your campaigns showing before and after values, timestamp, logic, limits, and approver for a real change. If any of the five is missing, ask why.