Four systems want to write to the same CRM record. Instead of letting them, every source submits a proposal and a gateway decides: identity resolution with Claude breaking ties, a per-field authority matrix with freshness decay, echo suppression for sync loops, and an append-only audit ledger. Watch a captured run of the real system, then break the rules yourself in the playground.
The walkthrough is a captured run of the real system— a live Salesforce org, live Snowflake, a live Claude call — replayed here, not re-run, because the gateway writes to a real CRM. The rationale you'll see in beat 2 was written by Claude during that run. The playground, though, runs entirely in your browser: same decision engine, ported line for line.
Nothing writes to Salesforce directly. Every system submits a ProposedChange — a request, never an instruction — and the gateway runs it through five stages in a fixed order. The write lands as an upsert on a unique, case-insensitive external ID, so a duplicate account isn't policed after the fact; it's impossible.
Identity — which company is this even about?
Three tiers, each weaker and louder than the last. The interesting one is the narrow band in the middle: when name similarity is genuinely ambiguous, Claude referees — it can only choose from candidates the resolver found, its rationale is written into the audit trail, and any failure means "no match," because a missed match is a duplicate a human merges in ten seconds while a wrong merge fuses two customers' histories.
One authority ruling, end to end
This is the exact ruling from beat 3 of the walkthrough. Four claims arrive for one field; the allow-list strikes product before it can compete, freshness decay and the confidence floor discount the old, authority rank decides among survivors, and the incumbent competes like everyone else — with exact ties going to it. Try bending this policy yourself in the Playground.
Echo — breaking the sync loop
The gateway's own write syncs out and comes straight back as the freshest "observation" in the system — the write that starts an infinite loop. Three checks catch it, and the third is the one an idempotency guard can't do: values that came back reformatted still normalize to the claim we ourselves wrote seconds ago. In production traffic this fired unprompted, catching HubSpot's duplicate event for a single form submission.