Rule processor updates (transactional history implementation) not ACID compliant

[Justus-at-Tazama]

As a config service user,
I want to see a complete history of all users who had updated a rule processor
So that I can see who has been working on the rule processor

Current behaviour

1. Create new rule processor and submit

2. Click Modify on the Rule Processor Row
3. Update the Description and submit

The database now contains two entries for the same rule processor:

• Edited:

The edited has a createdAt and updatedAt value reflecting the time of the edit
The edited contains a new originatedID with the _key of the original record

• Orignal:

The original has an edited true-false flag (what is its purpose?)
The original has an updated updatedAt attribute

On the screen, the edited record is displayed:

It is impossible to tell which timestamps are being displayed on the Review page without the detailed time-inclusive timestamp:

This appears to be poorly-implemented transactional record change logging for rule processor updates. This approach is not ACID compliant.

• Atomicity and Isolation: Multiple interdependent records relate to the rule processor, and code-level inference is required for appropriate understanding of the context
• Consistency: Different records in the same collection now have different contents, depending on their inferred purpose.
• Durability: Previous records are updated when new records are added.

Expected behaviour

If the objective here is active operational data combined with a change log of some sort, it would make more sense to maintain the current active version of the data in the rule collection and farm out the change log to a structured event log in a different collection.
In other words, follow this process to update the data, while maintaining the complete change history:

1. User updates rule processor and clicks Submit

2. System writes the update to the structured event log keyed to the rule processor record and timestamps the action, e.g.

{
  "ruleId": "479aeae0-5f8d-482b-89e3-b0517b49df75",
  "timestamp": "2025-09-08T15:25:00Z",
  "changeType": "UPDATE",
  "changedBy": {
    "userId": "tazama-config-studio-admin@tazama.org",
    "source": "Tazama Config Studio",
    "ipAddress": "192.168.0.101"
  },
  "changes": {
    "desc": {
      "from": "Rule 001",
      "to": "Rule 001 - edited"
    },
    "updatedAt": {
      "from": "2025-09-08T15:03:14.709Z",
      "to": "2025-09-08T15:25:00Z"
    },
    "updatedBy": {
      "from": "tazama-config-studio-admin@tazama.org",
      "to": "tazama-config-studio-admin@tazama.org"
    }
  },
  "reason": "Description updated by user"
}

3. On successful persistence of the change in the structured event log, update the transaction in the rule collection (_key = "479aeae0-5f8d-482b-89e3-b0517b49df75")

{
  "cfg": "1.0.0",
  "desc": "Rule 001 - edited",
  "name": "001",
  "dataType": "NUMERIC",
  "ownerId": "tazama-config-studio-admin@tazama.org",
  "state": "01_DRAFT",
  "createdAt": "2025-09-08T15:03:14.709Z",
  "updatedAt": "2025-09-08T15:25:00Z",
  "updatedBy": "tazama-config-studio-admin@tazama.org"
}