A marketplace group of Flipkart's shape trades through three legal entities in five markets. In 2027 a dispute asks which consumer-protection and data rules applied to an order placed in 2025. The code resolves the regime at request time from the customer's IP address and the current entity mapping. Design the layer that answers the question.

Requirements that drive the structure

The question is historical, so the system must answer what the rules were, not what the rules are. Three things change underneath a live mapping: a market gains or loses an entity, a licence changes what an entity may sell, and a regulation starts applying on a date. Recomputing a 2025 order against the 2027 mapping produces an answer that is confident, undocumented and probably wrong, and nothing in the record reveals the drift.

The second requirement is that the answer be cheap. If reconstruction takes a six-week forensic exercise, the organisation will settle rather than answer.

The design

Write a regime determination in the same transaction as the order, holding:

• the inputs as observed: contracting entity, delivery country, declared country of residence, product class and licence, sales channel, and the IP-derived country recorded as an input rather than as the answer;
• the regime set resolved, as identifiers rather than prose;
• the version of the rule table used, and which rule fired;
• the timestamp and the service version.

The rule table is effective-dated data, published by the obligation-mapping process, append only. A deployment never changes history, because history references a version id that resolves to immutable content. Derived records such as invoices, exports and warehouse rows copy the determination; they never recompute it.

The hard part

Resisting the urge to let IP decide. The network path is evidence of where a device was, which is the right input for geo-licensing and the wrong one for which regime governs a contract. Regime applicability follows the legal relationship: the contracting entity and the declared residence. Keep the IP-derived country for the cases where location genuinely is the test, and keep it labelled as one input among several.

The second hard part is organisational: somebody must own the rule table, and the obligation mapping must land there rather than in a slide deck.

How it fails

• Storing only the output. A column saying "EU" cannot be explained three years later, and the explanation is what the dispute is about.
• Editing the rule table in place, so a version id resolves to different content than it did. That is worse than having no stamp, because it looks like evidence.
• Backfilling old records from today's table, which manufactures evidence. Leave historical rows unstamped and say so.
• Recomputing in a downstream job, so the warehouse and the order disagree and neither knows which is authoritative.

What it buys and what it costs

One narrow table, one write per order, a few hundred bytes. In exchange, retention clocks, residency routing, consent requirements and tax treatment all key off the same stamp, so one artefact serves many obligations and the 2027 question becomes a query.

What I would build first

The stamp and the versioned rule table, before any enforcement logic. Enforcement without a record of what was decided produces behaviour you cannot explain; a record without enforcement at least produces evidence.

When this is the wrong answer

A single-entity product in one market does not need any of it. A constant in configuration and a dated changelog is the proportionate answer, and it stays proportionate until the second legal entity or the second regulated market appears. That is the trigger, and it is usually visible a quarter ahead, which is enough time to build this before there is history to backfill.