Preimage Audit Log¶
Document — instantiates Collision-Free Mapping Design
A record preserving source-to-target assignment evidence for collision diagnosis.
A preimage audit log is an append-only record of which source got mapped to which target, written at the moment of every assignment and never overwritten — so that when a collision surfaces later, the sources that collapsed onto a shared value can still be recovered. Its whole value is retained evidence: a duplicate target that a scan or index can point at is only a dead end unless you can answer "which two sources are these, exactly?" The log answers that. Unlike the guards and detectors around it, it prevents nothing and catches nothing in the moment; it is the mechanism that makes a collision repairable instead of merely visible, by preserving the preimages — and by recording, alongside them, which merges were authorized on purpose.
Example¶
An enterprise runs identity federation: several upstream identity providers — an acquired company's Okta, the parent's Azure AD — feed into one federated directory keyed on email. A recycled email alias, briefly reassigned between two employees, once caused the directory to fuse them into a single federated identity, quietly mixing one person's access with another's. By the time anyone noticed, the mutable mapping showed only the merged result; it could not say what had merged.
The preimage audit log is what let engineers unwind it cleanly. Every source-account-to-federated-ID assignment had been written as an immutable entry — source IdP, source subject ID, timestamp, and the version of the mapping rule that made the link. Reading the log, they reconstructed exactly which two source subjects had collapsed onto the shared identity, split them back apart, and reissued distinct federated IDs. Because the preimages were preserved, a collapsed target was reversible; without them, the merge would have been a permanent conflation nobody could see through.
How it works¶
- Write on every assignment. Each source-to-target mapping is recorded as it happens, capturing the source's identifying attributes, the target, and the rule version.
- Keep it append-only. Entries are never edited or deleted, so the record of what mapped where survives even the overwrite that caused a collision.
- Preserve enough source identity to distinguish preimages. The log stores the attributes that define a distinct source, so two collided sources can actually be told apart after the fact.
- Log intentional merges too. When a merge is authorized, the authorization — who approved it, when, and why — is written into the record, so a deliberate merge is distinguishable from an accidental collapse.
Tuning parameters¶
- Capture depth per entry — minimal (target + source key + timestamp) versus rich (full source attributes + rule version + context). Richer entries diagnose more but cost storage and may carry sensitive data.
- Retention window — how long entries are kept. Longer reach for forensics versus storage cost and data-minimization obligations.
- Immutability guarantee — strict append-only / write-once media versus a mutable table with audit triggers. Stronger immutability resists the very overwrite that erases evidence.
- Write granularity — log every assignment versus only on conflict. Logging everything is complete but voluminous; logging only conflicts is lean but can miss the benign write that a later collision turns significant.
- Linkage to merge-authorization records — whether authorized merges are cross-referenced into the same log, keeping intent and evidence in one place.
When it helps, and when it misleads¶
Its strength is that it is what makes a collision repairable rather than merely visible: with the preimages in hand, a collapsed target can be split back into its distinct sources; without them, a duplicate value is a distinction already lost.
Its honest failure mode is that a log is passive — it prevents nothing on its own, and worse, if it is not truly append-only, the very overwrite that caused the collision can erase the evidence of it, leaving a record that agrees with the corrupted present.[n1] The classic misuse is logging only the target and a timestamp, so that when two sources collide you can confirm that they did but not who they were — evidence too thin to repair anything. The guarding discipline is to capture enough source identity per entry to distinguish preimages, and to keep the log immutable and separate from the mutable mapping it documents.
How it implements the components¶
preimage_evidence_record— it is the retained source-to-target evidence, the record that lets a collapsed target be traced back to the sources that produced it.source_identity_boundary— it stores the attributes that define each distinct source, so two collided preimages can be told apart after the fact.merge_authorization_record— authorized merges are written into the record with approver, rationale, and timestamp, keeping intentional merges distinguishable from accidental collapse.
It does not detect collisions (Duplicate Target Scan), enforce uniqueness at write (Unique Index Constraint), or run the review workflow that decides them (Collision Quarantine Queue); it is the evidence those mechanisms draw on.
Related¶
- Instantiates: Collision-Free Mapping Design — it is the archetype's preserved evidence layer, the record that makes collisions diagnosable and repairable.
- Sibling mechanisms: Duplicate Target Scan · Collision Quarantine Queue · Unique Index Constraint · Namespace Reservation Table · Deterministic ID Allocator · Booking Lock · Hash Collision Check
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Preimage Audit Log operates as a persistent ledger, log, register, or case record that preserves history and traceability because it a record preserving source-to-target assignment evidence for collision diagnosis.
Independent corroboration: The frozen evidence defines Preimage Audit Log as 'A record preserving source-to-target assignment evidence for collision diagnosis', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Preimage Audit Log is most plausibly rooted in the computer_science tradition because its characteristic form depends on algorithms, data structures, formal interfaces, and software-system practice. The assignment tracks that formative lineage, not the many settings in which the mechanism can now be applied.
Related originating lineages:
- Accounting & Auditing — The accounting_auditing tradition materially shaped Preimage Audit Log through its own practice of controls, traceable records, assurance, and audit evidence.
- Mathematics — The mathematics tradition materially shaped Preimage Audit Log through its own practice of formal definition, proof, mapping, and quantitative structure.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of computer science. NIST SP 800-92: Guide to Computer Security Log Management; Encyclopedia of Mathematics: Function and Preimage documents the defining practice, history, or theory described in the selected origin rationale. Other domains are retained only where the blind reviews identify material co-development or translation; broad later application is recorded separately as domain_reach=multi_domain, while origin_mode=cross_disciplinary_synthesis describes the relationship among formative lineages.
Attribution caveat: The blind-review boundary with mathematics is substantive: those traditions materially developed, translated, or operationalized part of the mechanism. The cited provenance places its defining lineage in computer science.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NIST SP 800-92: Guide to Computer Security Log Management
- Encyclopedia of Mathematics: Function and Preimage
Notes¶
[n1] An append-only (write-once) log admits new entries but never edits or deletes existing ones, making it tamper-evident. If an audit log is instead mutable, the same overwrite that collapses a target can also erase the evidence needed to undo it, leaving a record that silently agrees with the corrupted state. ↩