Point-in-Time Reconstruction

A regulatory submission is a record. Years later it may be questioned, and the institution must be able to explain how the figure was produced.

Regenerating it from current data produces a different number — a case was reopened, a policy amended, a correction applied, a rule changed — and the difference has no explanation available. That is a finding.

Point-in-time reconstruction means the report can be regenerated as it was: same data state, same rules, same result.

Why it matters

It is the difference between defending a submission and being unable to. It is also a capability rather than a process: no amount of documentation substitutes for the ability to reproduce the number.

Implementation patterns

• Bitemporal or versioned data, so the state as at a date is recoverable rather than only the current state. Corrections are recorded as new versions rather than overwriting.
• Effective-dated rules, so a report over a past period applies the rules in force then. A system that cannot express "governed by the rules as at its date" needs a data migration for every regulatory change — which is the actual source of the disruption teams attribute to regulation.
• A stable internal model with a mapping layer per regulator and per report version, so a format change is a configuration change rather than a domain change.
• Retention of the submitted artefact, not just the ability to regenerate — because what was submitted is the record, and the regeneration is evidence about it rather than a replacement for it.
• Auditability of every figure to its inputs, since "the system computed it" is not an answer.
• A reconciliation between the report and the source systems, since a report that does not tie back is one nobody can defend.
• A named owner per report, or it is regenerated by whoever is available in a way nobody can explain.

Industry example

Insurers such as Digit and brokerages such as Groww submit reports whose underlying records have long lifecycles and are amended after submission. The characteristic failure is regenerating a prior period from current data, and it is prevented only by the reconstruction being a designed capability rather than an assumption about the data model.

Failure scenarios

• Current-state-only data, making reconstruction impossible.
• Rules in code, so a change loses the prior behaviour.
• The submitted artefact not retained, leaving only a regeneration that differs.
• No lineage to inputs, so a challenged figure cannot be traced.
• Corrections overwriting rather than versioning.

Trade-offs

Bitemporal modelling is materially more complex: every read must resolve a version, every query carries a temporal predicate, and the storage grows with the history rather than with the entity count.

Applying it everywhere imposes that cost where there is no benefit. The judgement is which entities are subject to retrospective questions — regulated records, financial transactions, decisions with an appeal right — and applying it precisely there, with current-state modelling elsewhere.

Interview question

"A regulator asks about a figure you submitted three years ago. Walk me through how you would produce the same number today, and tell me what in your data model makes that possible or impossible."