# [The data wall](https://rebilder.com/help/trust/data-wall)

> Your per-store data never feeds any buyer-side negotiation engine. Only anonymous aggregates of 25+ merchants ever cross, and the wall is built into the database, not just the policy.

## The promise

Rebilder exists to make your store visible to AI buyers. That only works if you can trust us with the traffic data. So the promise is simple: your store’s data is never used against you. It is never sold, and it never feeds any negotiation engine or buyer-side agent at per-merchant granularity. No system on the buyer side of commerce can ever look up what a specific store’s traffic or conversion looks like.

The only thing that can cross to anywhere else is anonymous, aggregated benchmarks, and only when a bucket contains at least 25 merchants, so no individual store is identifiable or reverse-engineerable from the numbers.

## How it is enforced

The wall is architectural. It would take deliberate engineering work to violate, and automated checks exist to catch exactly that:

- Separate database schemas with separate credentials: your Rebilder data lives behind its own database role, and other systems’ credentials have no access to it; the database itself refuses cross-boundary reads.
- One narrow, read-only crossing: the k ≥ 25 aggregate benchmark views. The 25-merchant minimum is baked into the view definitions, not applied by application code that could forget.
- A CI boundary check: every code change is automatically scanned, and any import or credential reference that crosses the wall fails the build before it can ship.
- An audit log: every query against the benchmark views is recorded, so every crossing is accountable.

## Which buyer-side engine we mean: ours

Rebilder LLC also builds MUMM, a consumer negotiation agent at trymumm.com. We would rather tell you that than have you find it out somewhere else. It is also why the wall is enforced in the database, not just promised in a policy.

- MUMM cannot read your store’s data. Not your traffic, not your conversion, not your events: no per-merchant granularity, at any price, to anyone.
- The only westbound crossing is the k ≥ 25 aggregate benchmark views described above, and the floor is in the view definition.
- Nothing about a MUMM shopper travels the other way into Rebilder. Data whose subject is a buyer does not cross: not per-person, not aggregated, not anonymised.
- When a shopper asks MUMM to negotiate with you, the message you receive is service delivery on their instruction. It travels over an enumerated set of fields. It is a customer contacting you, not a data transfer.

> The wall runs both ways and is checked in CI on every commit. We build both the buyer side and the merchant side, which is exactly why the wall has to be structural rather than a promise.

## We talk about this openly

The data wall is written into our terms of service, and we talk about it openly. If you are evaluating Rebilder and want to probe it harder, ask. We treat the question the way serious vendors treat a security review.