--- title: "Event governance — data you can trust" description: "Define every event, check every release, and keep only the events your plan defines — so every chart and answer rests on data you can trust." canonical: "https://www.togohq.ai/docs/concepts/governance" applies_to: "Every Togo SDK, the dashboard and the MCP server" updated: "2026-11-03T00:00:00Z" --- # Event governance — data you can trust Define every event, check every release, and keep only the events your plan defines — so every chart and answer rests on data you can trust. ## Why it matters Analytics is only as good as the events underneath it. Without a plan, the same action arrives under three names, a property is a number in one release and a string in the next, and an event fires on a screen nobody saw. Each of those is a chart that looks right and is wrong — a funnel that undercounts, a retention curve that splits one cohort in two, an answer you act on. **Governance is how you prevent that, once, instead of finding it later in a chart.** In Togo it comes down to one habit — **define every event before you ship it** — and the controls that enforce the plan for you. A defined event pays off three ways: - **Your numbers mean what they say.** Every event has one name, one meaning and typed properties, so two people — or two agents — asking the same question get the same answer. - **Your agent answers better.** A definition tells the AI what the event means, when it fires and when it does **not** — the difference between "people who saw pricing" and "people the pricing page rendered for". - **Mistakes are caught before they reach your data.** A misspelled name, a missing event or a property that would be dropped is flagged before you ship, not discovered a month later. ## What a definition holds | Part | Example for `checkout_started` | | --------------------- | ---------------------------------------------------------------- | | What it means | A person began paying for a plan | | When it fires | The checkout page has loaded with a plan selected | | When it does **not** | A plan is previewed from the pricing page; a checkout is retried | | Its properties, typed | `plan`: one of `starter`, `pro`, `team` · `seats`: number | The "does not fire" line matters most. It is what stops a conversion event quietly turning into a page-render event as the product changes around it. ## The recommended setup 1. **Define every event before the code sends it.** The agent install does this for you: it reads your product's flows and defines each event first ([Install Togo with your AI agent](/docs/install)). Your agent can define or refine one at any time with [`update_event_definitions`](/docs/reference/mcp-tools#update_event_definitions), and you can review them all in the dashboard's **Event registry**. 2. **Check every release against the plan.** Before you ship, have your agent check its test run with [`verify_tracking`](/docs/reference/mcp-tools#verify_tracking): it shows each event the run sent with what is wrong with it and the fix, and counts the errors, the warnings and the expected events that never arrived ([Check that events arrive](/docs/verify)). 3. **Turn on strict event governance** once your plan covers your traffic, so only defined events reach your reports (below). ## What Togo enforces for you | Control | What it does | | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Strict event governance** | Keeps only events your plan defines; everything else is dropped as it is processed | | **Safe changes to live events** | Once an event has traffic, a definition change that would break code already sending it — a narrower type, a removed allowed value — is refused, with the reason | | **Stable keys and merge suggestions** | Every event keeps one key for life, and two names that look like one event are flagged to merge — never merged silently ([Events](/docs/concepts/events)) | | **Release checks** | `verify_tracking` and **Live View** show, for every test event, whether production keeps it | | **Checks on arrival** | Reserved `$` names, oversized values, too many properties and implausible timestamps are refused before they are stored ([Event diagnostics](/docs/reference/event-diagnostics)) | ## Strict event governance Turn it on in your project's **Settings**, under **Event governance → Only keep defined events**. From then on, an event whose key has no definition is dropped when it is processed. Its name still appears in the **Event registry**, so you can see it and define it. **Turn it on when your plan covers your traffic.** Before switching, check that every event you rely on is defined: **Live View** marks any test event production would drop as **Not defined**, and `verify_tracking` says the same. Define what it names, and switch on. **Drops are permanent.** An event dropped while the setting is on is not stored, so turning it off later does not bring it back. That is why the switch belongs to a person: an owner or admin turns it on in the dashboard, and agents — which can define events — cannot change it. ## Who can change the plan | Change | Who | | -------------------------------------- | --------------------------------------------------- | | Define or refine an event | Your agent with a **Read and change** connection | | Merge two events | Your agent, after asking you — a merge is permanent | | Turn strict event governance on or off | An owner or admin, in the dashboard | [What a connection can see and do](/docs/mcp/security) covers agent access in full.