A governance layer for commerce automation.

Every recommendation oddly surfaces is produced by a fixed rule applied to a signal you connected. The same inputs always produce the same output.

oddly does not guess and it does not predict. There is no black box deciding what is wrong with your account. When a card appears, it appears because a specific condition in your data was met: a campaign held a sustained return shortfall, a keyword spent without converting, a top product walked toward a stockout. No AI guessing. A rule, a signal, a number you can check.

That is the trade. oddly will not invent an insight that is not in the data, and in exchange you get something rarer than cleverness: you get to verify it. Every card traces back to the exact signal that triggered it.

This is the one constraint everything else is filtered through, and it is not a setting you can toggle. It is hardcoded into how oddly is built.

oddly can pause an ad, reduce a bid, or block a bleeding campaign on its own. It cannot raise your budget on its own. Not by a dollar, not ever, regardless of tier or automation level. If more spend would genuinely help, oddly shows you the evidence and hands you the button. The increase decision stays with you.

Decrease-only is the spine of the whole model, not a safety feature bolted on the side. It is enforced at the lowest level: the connectors that touch Google and Meta do not expose an increase path at all, and the build fails if anyone tries to add one. The product cannot spend more of your money than you told it to.

Before oddly changes anything in a live account, it runs the change as a dry-run, shows you the exact operation, and holds it. The change is made only when you approve it, and it can be reversed.

A proposed change moves through a held pipeline. oddly verifies the plan against the live account, you see precisely what will happen and the rule that decided it, and only then does it execute. Every executed change carries a path back.

Every signal read, every rule fired, every plan proposed, and every change made is recorded in an order you can inspect. It is meant to be read, not buried.

An internal log exists to help engineers debug. An audit trail exists to answer one question for the operator: what did you do to my account, and why. oddly treats it as the second thing. Here is the shape of one, for a single change:

Illustrative figures. A real trail shows your accounts, your numbers, your timestamps.

There is nothing to take on faith. This is the full set of deterministic rules in the engine right now, grouped by the source they read. Pulled straight from the registry the product runs on.