Changes through Golden 3.4.0

This page summarizes customer-visible changes since Golden 3.1.0. Check the version of your environment before applying a version-dependent action. The API reference describes the 3.4.0 contract.

3.2.0: identity, lineage and history

• Record writes use one identity rule on every intake path. A free _id on a DEFAULT dataset can create a record under that identifier. COLUMN and SCRIPT datasets refuse missing or conflicting identities instead of assigning a replacement identifier. An identity script cannot read _id.
• An update may add origins, and a dataset can enable lineageUnique to prevent two live records from holding one source pair. Source configurations can declare their provenance key. Review source rows that carry _id and datasets that require _src_id before running a load.
• Merge survivors can continue a live or historical identity. A new survivor is not fed by an old source. Preview mergeIdentity before a decision and handle the event order according to the survivor type. SPLIT is no longer an automatic action.
• History keeps versions of deletes, merges and undos. A deleted entity record can be restored; an ADMIN can release an origin from a live record. A table clear removes every version and earlier audit event.
• Resource imports can be previewed before they are applied.

3.3.0: received input in audit

On an audited table, the record timeline can show the documents received and the steps that changed each field. An unchanged resend now leaves an audit event with empty changes; full resends may therefore grow audit storage. Received input can include values that a cleaner did not store as business data, and remains in audit until the table is cleared. Review who can read audit and the retention of sensitive source values. See Audit and history.

Receivers may see changes on a merge survivor’s MERGE audit element and cleaner changes from a table load. They never receive the stored received documents or processing steps. See Product events.

3.4.0: access, disabled entities and indexing

A row-restricted caller no longer receives identifiers outside their scope through record metadata, refusal details or audit relationships. Clients should use the visible structured identifiers and tolerate a refusal with no related identifier. See Data access.

Disabling an entity stops its scheduled work and refuses further writes and decisions. Asynchronous indexing waits until it is enabled. An ADMIN can inspect failed indexing entries and retry them after correcting the cause; see Disabled entities and indexing failures.