Audit and traceability

PROVEN keeps two complementary histories: the changes that actually reached the catalog and the important events that led to them. Together they help explain who took an action, what changed, and which result was confirmed.

#Catalog change history

For a supported change, history can show:

• the product, field, or image involved;
• the value observed before the change;
• the approved value;
• who started the action;
• the verified result after publication;
• whether the change can be restored safely.

History keeps intent, publication, and verification separate. Shopify accepting a request is not automatically treated as proof that the final result matches the approved value.

#History of important actions

Alongside catalog changes, PROVEN keeps a chronological history of important access, configuration, synchronization, and publishing actions. Events already recorded are not rewritten. Depending on the feature being used, the journal can include:

• sign-ins, granted or denied access, and permission changes;
• Shopify app installation, configuration, and uninstall;
• team access changes;
• the start, stop, and outcome of synchronization or checks;
• problem review, approval or rejection of a fix, and publication to Shopify;
• support requests and other events needed for security or issue investigation.

When the information exists and is allowed to be shown, history can include the time, user, store, affected item, and result. Passwords, access tokens, and other secrets are not exposed as audit details.

#Fixing and publication

Approving a proposal is not the same as publishing it. PROVEN can keep approval, application of the change, and the verified result as separate events. Catalog history covers the fields and change types that PROVEN can currently track.

Audit follows important product actions rather than every interface interaction.

#Store and role separation

A merchant’s history stays limited to their store and permissions. Authorized PROVEN team members can investigate support and security events without changing store history. For reversible changes, see Controlled restore.

#Controlled restore

For reversible changes, the previous version can be kept for restoration. Before restoring it, PROVEN checks the store again. If the state changed elsewhere, the restore stops to avoid overwriting a newer change.

A successful restore appears as a new change in history; it does not erase the original change.