Non-visual mirror Harbour Rewards · no customer data
One Definition, Many Merchants
How can one definition serve many merchants without drift or data leakage?
Narrative sequence
- Definition blooms — One merchant token expands into a versioned analytical definition.
- Separate bindings — Invariant logic separates from account, region, dataset and permission bindings.
- Replicate lanes — Keyed components replicate across fictional merchant lanes.
- Leak mutation — An injected wrong binding attempts a cross-tenant leak and the gate fails.
- Cross-region deploy — Correct bundles cross account and region boundaries.
- Rendered reconciliation — Rendered totals and permissions reconcile to the source definition.
- Version replay — Version history rolls one coherent change forward or back.
| Evidence | Value | Status / meaning |
|---|---|---|
| Definition | v1.8 | shared |
| Merchant A | PASS | isolated |
| Merchant B | PASS | isolated |
| Merchant C | FAIL | wrong binding |
| Manual baseline | 9 h | scenario |
| Bundle path | 2 h | scenario |
Trivial baseline
Manual merchant-by-merchant dashboard rebuilding, measured as a fictional time baseline.
Sensitivity
Increase merchant complexity and inject one wrong dataset binding and one shared metric error; affected deployments must fail together.
Strongest counter-case
Automation can replicate one definition error everywhere; shared validation must fail every affected deployment.
Verdict
SURVIVES: tenant gate catches the injected binding. UNTESTABLE: adoption effect.
Synthetic example. Deterministic fictional records; not customer data or achieved customer results.