Provenance fields are immutable after creation

Provenance fields that can be overwritten are not provenance — they are annotations. If an enrichment job can silently replace source_id or acquired_at on an existing contact, the audit trail is broken. GDPR Art. 5(1)(d) requires data accuracy, which includes accuracy about the origin of the data. SLSA Provenance L2 requires that provenance records be unforgeable after creation. CWE-345 (Insufficient Verification of Data Authenticity) applies when records can be modified post-creation in ways that destroy traceability.

Exclude provenance fields from all update schemas at the application layer, and optionally enforce immutability at the database layer with a trigger.

// Zod update schema in src/lib/contacts/update.ts
const updateContactSchema = z.object({
  email:      z.string().email().optional(),
  first_name: z.string().optional(),
  last_name:  z.string().optional(),
  // source_type, source_id, acquired_at intentionally excluded
})

-- Database-level enforcement
CREATE OR REPLACE FUNCTION prevent_provenance_update()
RETURNS TRIGGER LANGUAGE plpgsql AS $$
BEGIN
  IF NEW.source_type IS DISTINCT FROM OLD.source_type OR
     NEW.source_id   IS DISTINCT FROM OLD.source_id   OR
     NEW.acquired_at IS DISTINCT FROM OLD.acquired_at THEN
    RAISE EXCEPTION 'Provenance fields are immutable after creation';
  END IF;
  RETURN NEW;
END;
$$;

CREATE TRIGGER enforce_provenance_immutability
  BEFORE UPDATE ON contacts
  FOR EACH ROW EXECUTE FUNCTION prevent_provenance_update();