How a hash-chained log secures audit continuity (EU AI Act Art. 12)

«High-risk AI systems shall technically allow for the automatic recording of events («logs») throughout the system's lifecycle. Logs shall enable the traceability of the system's functioning to an extent appropriate to the intended purpose.»

The key word is «traceability». The regulator must be able to reconstruct any decision made by the system months or years later. This means logs cannot be edited or deleted after the fact — not even by a database administrator.

1. Append-only table schema:

The audit_logs table has fields: id, tenant_id, sequence_number (monotonically increasing per tenant), actor_email, action, entity_type, changes (jsonb), timestamp, previous_hash, record_hash.

2. Each record hashes the previous one:

On INSERT we compute record_hash = SHA256(prev_record_hash || JSON(this_record_payload)). The previous_hash field stores the hash of the prior record. If anyone modifies a record mid-chain, the next previous_hash will no longer match the new record_hash of the previous record. Detected by a single SQL query.

3. Postgres trigger blocks UPDATE and DELETE:

CREATE FUNCTION raise_audit_immutable() RETURNS trigger AS $$
BEGIN
  RAISE EXCEPTION '%s is append-only (TG_OP=%s)', TG_TABLE_NAME, TG_OP;
END $$ LANGUAGE plpgsql;

CREATE TRIGGER audit_logs_no_update BEFORE UPDATE OR DELETE ON audit_logs FOR EACH ROW EXECUTE FUNCTION raise_audit_immutable(); ```

This trigger fires at the DATABASE LEVEL — even if the application is compromised, no UPDATE audit_logs or DELETE FROM audit_logs will succeed. Only root access to Postgres + DROP TRIGGER + restoring from backup can change anything — and any such attempt leaves its own trace in system logs.

An auditor can run a read-only query at any time:

WITH chain AS (
  SELECT sequence_number, record_hash, previous_hash,
         LAG(record_hash) OVER (ORDER BY sequence_number) AS prev_actual
  FROM audit_logs
)
SELECT COUNT(*) FILTER (WHERE previous_hash IS DISTINCT FROM prev_actual
                        AND sequence_number > 1) AS broken_links
FROM chain;

If broken_links = 0, the chain is intact. If > 0, tampering occurred somewhere.

Across all current AZTender Audit deployments, broken_links = 0 is automatically re-verified every 24 hours.

Without a hash chain, logs are just text records. They can be edited via UPDATE audit_logs SET action='confirm' WHERE id=... and the trace will appear «correct» at read time.

With a hash chain, such an edit immediately breaks the next record. The regulator can reconstruct «what really happened» via snapshot or backup and compare the divergence. This provides proof of imperfection, not merely «consent to trust».

For Hesablama Palatası and similar audit institutions, this is critical — audit conclusions must withstand court review, parliamentary inquiry, donor due-diligence. Hash-chain is the technical standard required by the EU AI Act and being developed in PARALLEL in Germany (BSI), Estonia (X-Road), Finland (Suomi.fi).

• ❌ Does not protect against FALSE data being entered at the very start. If an operator deliberately enters actor_email='audit-team@hp.gov.az' to impersonate someone — that gets written and hashed. Hash-chain protects against POST-HOC modification, not against initial falsification.

• ❌ Does not protect against full database destruction (DROP DATABASE). That is solved by backups.

• ❌ Does not make AI decisions «correct» — it simply ensures that whatever decision AI makes is recorded immutably.

• ✅ Guarantees one thing: once a record is written, no one — including sysadmins, developers, AZTender as the vendor — can change it via the application. Any modification requires root Postgres access and leaves traces in the system.