The data wall

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 blunt: 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 look up “what does this specific store’s traffic or conversion look like” — ever.

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 (not just promised)

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 crossings are not just constrained — they are accountable.

Marketed, not hidden

This is written into the terms of service and talked about openly — it is a feature, not a footnote. If you evaluate Rebilder and want to probe the data wall harder, ask; we treat the question the way serious vendors treat a security review.