Spawned · Ideas Journal

SITAC Released: The Stable-Identity Temporal Audit Chain

Full History. Stable Identity.

Most of the applications SPAWN.LONDON founder Paul Emerton now works on require ISO 27001 levels of auditability, traceability and record protection. We live in an age where systems increasingly require greater transparency and stronger defences against malicious activity.

In response, Emerton expanded on established temporal data methods by developing the Stable-Identity Temporal Audit Chain (SITAC) — a database specification where every record retains its permanent UUID while carrying a complete, attributable history of every change.

No repointing relationships. No chasing changes through application logs to rebuild histories. Full history, stable identity, instantly available.

Having begun work on SITAC in 2024, Emerton has today (18 August 2026) published a white paper documenting SITAC in detail, and made the source code available under the MIT license so that others can use and improve upon the method in their own software development. SITAC is supported commercially by SPAWN.LONDON.

Get SITAC
# Install via npm npm install sitac-core # Inspect the package npm view sitac-core # Clone the source (MIT license) git clone https://github.com/verifie/sitac.git

One central requirement

Temporal data and record versioning are established concepts. SITAC is Emerton's particular application-level variation, designed around one central requirement:

The permanent identity of a live record should not change merely because the record has been edited.

Under SITAC, each logical record has a permanent canonical UUID. Before a record is changed, its current state is copied into a historical snapshot. The original canonical row is then updated in place and linked backwards to that snapshot. Each earlier snapshot links to the version that preceded it.

The result is a complete history chain showing:

  • Who created each version
  • When that version became effective
  • What the data contained at that time
  • Who subsequently changed it
  • When it ceased to be the current version
  • Whether the canonical record was later deleted or restored

Crucially, the canonical UUID remains unchanged throughout. That means invoices, projects, permissions, messages and other related data can continue referencing the same identity. We do not have to repoint foreign keys throughout the database every time a record changes.

SITAC does not replace security logging, independent backups or retention controls, and it makes no claim to have invented temporal data. What Emerton has developed is a clearly specified variation combining temporal history with stable relational identity, attributable changes, soft deletion, restoration and controlled archival.

Retrofit-ready by design

One of SITAC's significant practical benefits is that it can be retrospectively introduced into many existing database-centric applications without requiring the principal application logic and existing data relationships to be rewritten.

That makes it particularly useful when improving the auditability of an established system where replacing the existing data model would introduce significant cost and risk.

Why specifications matter in the age of AI-written software

There is another reason specifications such as this are becoming increasingly important. AI can implement a software pattern remarkably quickly — but first somebody has to define exactly what that pattern is, why it exists, and which rules must never be compromised.

As more software is written by AI from what can sometimes amount to little more than a list of desired features, using a General Software Design Requirements (GSDR) document first provides a way of establishing the architectural, security and compliance principles that the generated software must always obey. We shall continue to deploy the SITAC method as a significant and standard part of our GSDR.

Why SITAC where audit and data integrity matter

Database backups capture the entire state of a system at discrete moments so you can restore after a disaster. They cannot answer “what did this specific record say on Tuesday, and who changed it?” without restoring an entire older copy of the database — slow, operationally heavy, and useless for real-time audit. Here is how SITAC compares with the standard alternatives.

System-versioned / temporal tables

SQL:2011, SQL Server, MariaDB, Oracle Flashback — the database automatically keeps old row versions with system timestamps.

SITAC advantage: keeps the original primary key stable forever so foreign keys never break, works uniformly across MySQL and PostgreSQL without vendor lock-in, and gives explicit control over which columns are versioned and which secrets are excluded.

Trigger-based audit / history tables

A trigger on every UPDATE/DELETE copies the old row into a separate history table.

SITAC advantage: history lives in the same table with a clear discriminator, child rows are archived atomically with the parent, and restoration itself becomes an auditable event that preserves the original deletion evidence.

Simple soft-delete (deleted_at)

Rows are marked deleted instead of being removed, but no previous versions of the data are kept.

SITAC advantage: retains the full previous state of every material change, not just the fact that the row was eventually deleted.

Change Data Capture (CDC) tools

Debezium, AWS DMS and similar — the transaction log is streamed to an external system that records every change.

SITAC advantage: history is queryable inside the same database with ordinary SQL, requires no extra infrastructure, and is deliberately shaped for compliance evidence rather than raw replication.

Application-level event sourcing

Every state change is stored as an immutable event; current state is derived by replaying events.

SITAC advantage: when you already have a conventional relational model, you keep normal tables and foreign keys, add history only where it is needed, and avoid the complexity of rebuilding state from an event log.

ORM versioning plugins

paper_trail, sequelize-temporal and similar — the framework intercepts saves and writes old versions to a versions table.

SITAC advantage: database-centric and table-agnostic, works the same way regardless of which ORM (or none) you use, and enforces the stable-identity, child-archival and restoration-with-evidence rules that most plugins leave incomplete.

Implementing SITAC in your project?

If you'd like us to take a look at your project, or would like further information or training on implementing SITAC, drop us a message. Commercial support is available from SPAWN.LONDON.