decision_log is the table everything resolves to. Catalog transitions, discount tests, drafts, revivals — each is a row. Rows are the audit trail and are not pruned, though deleting a product, variant or store removes its rows; reads are how you audit, writes are how the agents act.
Row shape
{
"id": "a1b2c3d4-9f2e-4b7a-8c1d-6e5f4a3b2c1d",
"store_id": "0f8e7d6c-…",
"product_id": "5b4a3c2d-…",
"variant_id": null,
"from_state": "ACTIVE",
"to_state": "OPTIMIZING",
"trigger": "roas_below_floor",
"evidence": {
"action": "optimize_loser",
"roas_30d": 0.8,
"reasoning": "ROAS under the store floor for 30 days; rewrite before discounting."
},
"cost_tier_at_decision": "A",
"applied_to_shopify": true,
"status": "applied",
"acted_at": "2026-07-02T06:14:09Z"
}Integrity
Each row is updated in place as its action moves on — approved_at, applied_at, failed_at and reverted_at are stamped on the row that started it — and the rows are the audit trail. They are not pruned; deleting a product, variant or store removes the rows that belong to it. Access is controlled by row-level security — each store sees only its own rows.
Reading it
curl -X POST https://app.magistry.io/api/v1/tools/get_recent_decisions \
-H "Authorization: Bearer mag_sk_live_..." \
-H "Content-Type: application/json" \
-d '{"limit": 50}'The same tool is available over MCP, so an AI client you've connected can read the log directly. See API + MCP for auth and scopes — decisions need only a read scope.
Reversing an action
To undo, the revert executor reads the row and derives the inverse mutation from evidence.action — a draft or vault republishes the product, a discount_test restores the original price, an optimize_loser restores the previous content version. It stamps reverted_at and reverted_by on the row and rolls the lifecycle state back. See ALLOWED_TRANSITIONS for which state moves are valid on catalog rows.