Regime Determination Record

Two years after a transaction, somebody asks which consumer-protection, tax and data-protection rules applied to it. The code can answer what the rules are now, from the current mapping of market to legal entity to obligation. That is not the question, and the difference is invisible: a new entity was incorporated, a licence changed what one entity may sell, and a regulation started applying on a date in between.

Recomputing therefore produces an answer that is confident, undocumented and often wrong. The pattern is to stop recomputing. At the moment the transaction is created, write a record of the determination: the inputs as they were observed, the version of the rule table consulted, which rule fired, and the regime set that resulted. The determination is data, written in the same transaction as the business record.

Why it matters

Regulatory questions arrive years late and are answered under time pressure by people who were not there. Without a stamp the organisation has two options, both bad: reconstruct the mapping from deployment history and git archaeology, which takes weeks and produces a contested answer, or assert today's mapping and hope nobody checks.

The second reason is operational rather than evidential. Retention clocks, residency routing, consent requirements and tax treatment are all functions of the same determination. Computing it once and storing it converts four independent sources of drift into one, and every downstream system reads instead of re-deriving.

Implementation patterns

• Stamp in the same transaction as the business record, never in an after-the-fact job. A determination written later is a determination made under different conditions.
• Store inputs, not only the conclusion. Contracting entity, delivery country, declared country of residence, product class and licence, sales channel, and the IP-derived country recorded as an input. A conclusion alone cannot be explained or re-argued.
• An effective-dated, append-only rule table published by the obligation-mapping process, with a version identifier that resolves permanently to the same content. Deployments change behaviour from now on; they never change history.
• Derived records copy the stamp, so invoices, exports and warehouse rows agree with the order by construction rather than by a reconciliation job.
• Keep the determining logic in one service with a replay interface that takes inputs plus a version and returns the regime, so a dispute can be re-run exactly.

Industry example

The clearest public analogue is in-line fiscal clearance regimes, where an invoice is not valid until a government service registers it and returns a reference. Firms operating under those regimes keep the returned reference, the payload as submitted and the schema version together, because an invoice questioned in 2027 must be shown as it was accepted. The same discipline applied to regime applicability is what turns a six-week reconstruction into a single row, and it is the one artefact that financial and marketplace groups with several legal entities consistently wish they had started earlier.

Failure scenarios

• Output only. A column containing "EU" with no inputs and no rule version. The dispute is about how the conclusion was reached, so the stamp answers nothing.
• A rule table edited in place. A version id that now resolves to different content is worse than no stamp, because it presents as evidence while being wrong.
• Backfilling. Stamping historical rows from today's table manufactures evidence. Leave them unstamped and record why.
• Downstream recomputation. The warehouse recomputes, disagrees with the order, and nobody knows which is authoritative.
• IP as the determination. The network path is evidence of where a device was, not of which legal relationship governs. It belongs in the inputs and never in the answer.

Trade-offs

The write cost is one narrow row of a few hundred bytes, under 1% of the size of a typical order record, and one extra write on a path that already has several. The real price is organisational: somebody must own the rule table, and obligation mapping has to land there rather than in a slide deck.

When not to use it

A single legal entity selling in one market does not need this. A constant in configuration and a dated changelog is proportionate, 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 the stamp before there is history to backfill. Also skip it for records with no regulatory dimension at all: stamping every row in the estate is how the pattern gets a reputation for ceremony.

Interview question

Q: A dispute in 2027 asks which rules applied to an order placed in 2025 through one of your three legal entities. Your code resolves jurisdiction at request time from the customer's IP and the current entity mapping. What do you tell the lawyers, and what would you have built?

What a strong answer covers: that recomputation cannot answer a historical question because the mapping has changed three ways since; that IP is an input and the contracting entity plus declared residence is the determination; the stamp's contents, including the rule-table version id and which rule fired; that derived records copy rather than recompute; and the refusal to backfill historical stamps, with the gap documented instead.

Quick check

Quiz: Which field makes a regime stamp defensible rather than decorative? The version identifier of the effective-dated rule table, because without it the stored conclusion cannot be tied to the rules as they stood.

Flashcard: Why does recomputing the applicable regime for an old order give a wrong answer? Because entities, licences and commencement dates all change underneath the mapping, so today's table describes today's rules and nothing in the record shows the drift.