Every BES operations team I have worked with has a story about this. A letter arrives from EGM or SEDDK. It does not ask for numbers — the numbers were already submitted. It asks for the reasoning: which contract versions were included, why a specific participant was classified the way they were, what the state fund matching calculation looked like on that specific reference date, which reference tables were active, and who signed off on the run.
And the pipeline, which happily produced the submission months ago, cannot answer any of it without a sprint.
What the regulator actually wants
The misunderstanding starts here. Compliance teams assume a regulatory evidence request is a data request. It is not. It is a defense request. The regulator already has the numbers you submitted. What they want to reconstruct is:
- The exact input snapshot as of the submission cut-off — not today's version of the same tables
- The version of every transformation, rule, and lookup table active at the moment the run executed
- The lineage from raw contract or contribution record all the way to the submitted aggregate
- The exception decisions: which records were excluded, suppressed, reclassified, and by what rule
- The human sign-off chain and the reconciliation evidence attached to it
This is a bundle, not a query result. And most BES pipelines were designed to produce the query result and throw away the bundle.
Why the reconstruction sprint happens
Walk through a typical BES submission pipeline in a Turkish pension company. Contribution data flows from the operational system, gets enriched with participant status from a slowly-changing dimension, joins to the state contribution matching rules table, applies the vesting and eligibility logic, and produces the aggregate that goes to the regulator. The pipeline runs. The output is filed. Done.
Three months later the request arrives. Now the team discovers:
- The source contribution table has been overwritten by daily loads. The snapshot as of the submission date is gone unless someone was pulling backups for other reasons.
- The matching rules table was updated twice since. Nobody versioned it because it lives in a reference schema that gets refreshed operationally.
- The transformation SQL is in a scheduler, but the scheduler kept only the latest version. The logic that ran on the submission date is in a Git commit somebody has to hunt for — assuming it was committed at all and not patched directly in production.
- The exception log exists but was never joined back to the submission run ID, so figuring out which exceptions applied to which submission requires timestamp guessing.
- Sign-off happened in email.
So a team of three people spends two to three weeks reconstructing something that existed, briefly, on the day of the run.
The design flaw: evidence as afterthought
The root cause is architectural. Pipelines are built to produce the submission, and evidence is treated as something that can be assembled later from logs, backups, and Git history. This assumption breaks the moment any of those substrates get rotated, refreshed, or garbage-collected — which they will, because they were not designed as evidentiary storage.
The pipeline is optimized for the wrong output. It treats the aggregate file as the deliverable. The regulator treats the defensibility of the aggregate as the deliverable.
Treating the defense bundle as a first-class artifact
The fix is not more logging. More logging produces more archaeology, not less. The fix is to make the defense bundle a required output of every submission run, produced by the same job, in the same transaction, with the same finality as the submitted file itself.
Concretely, every submission run should emit a bundle containing:
- Input snapshots, physically frozen. Not a pointer to a table that will change. A materialized copy of every source dataset used, stored in an immutable location keyed to the run ID.
- Rule and reference table snapshots — the exact contents of every lookup, mapping, and parameter table at the moment of execution. Contribution matching rates, vesting schedules, fund allocation tables, participant classification rules.
- Code fingerprint. Git commit hash of every transformation script, plus the actual serialized SQL or code executed. Not a reference — the text.
- Lineage graph from raw records to submitted aggregates, generated by the pipeline itself, not reconstructed after.
- Exception ledger scoped to this run ID: what was dropped, what was reclassified, which rule fired, what the record looked like before and after.
- Reconciliation evidence — the checksums, the row counts, the tie-out to the source-of-truth system, produced automatically and attached to the bundle.
- Sign-off record with the user, timestamp, and the specific bundle hash they approved. If sign-off happens outside the system, it does not exist.
The bundle is written once, stored immutably, and indexed by submission reference. When the regulator asks, you retrieve. You do not reconstruct.
What this costs and what it saves
The objection I hear is that this adds overhead to every run. It does. Snapshotting inputs and reference tables costs storage. Generating lineage costs compute. Enforcing sign-off in-system costs process change.
Compare that to the cost of a three-week reconstruction sprint pulling senior people off roadmap work, plus the risk that reconstruction produces a bundle that does not exactly match what was submitted — which is a far worse regulatory position than not having the bundle at all. A submission you cannot defend consistently is worse than a submission you cannot defend quickly.
Storage is cheap. Explaining to SEDDK why your reconstructed evidence does not match your original submission is not.
Where to start if you already have the problem
Most teams reading this already have years of undefended submissions behind them. Retrofitting evidence for old runs is not realistic. What is realistic:
- Draw a line. From the next submission cycle forward, every run produces a bundle.
- Pick the highest-frequency, highest-scrutiny submission first. Prove the pattern there.
- Freeze reference table snapshots immediately, even before you build full lineage. Reference table drift is the single biggest source of reconstruction failure.
- Move sign-off into the system. Email approvals do not survive an audit.
The pipeline that produces the number and the pipeline that defends the number are the same pipeline. Once you accept that, the architecture follows.