Every time a campaign is updated — manually or via a learning proposal — a new version is created. The full history is visible in the operator platform. Any version can be restored with one click.
Every change to prompt-facing campaign fields creates a new campaign_version record. The version captures the full configuration snapshot, the user who created it, the timestamp, and — if the change came from a proposal — the from_proposal_id. The campaign's current_version_id always points to the version currently being used by new conversations.
Version history turns campaign improvement from a risk into a routine. Every change is recoverable. Every decision is traceable. The learning engine can attribute outcomes to specific versions — meaning you always know what changed when performance moved.
If a recent change makes performance worse, any prior version can be restored from the version history view. Reverting creates a new version record so the revert action itself is in the audit trail.
How it works: All new conversations switch to the reverted config immediately on revert. current_version_id is updated — no cache to clear.
Versions created from proposals link back to the originating proposal. From version history, navigate directly to the proposal detail — evidence class, metric projection, readable diff — even after the proposal is marked applied.
How it works: resulting_version_id on the proposal row and from_proposal_id on the version create a bidirectional link — traceable in either direction.
Conversations started before a version change are linked to the prior version. The learning engine uses this to attribute outcomes correctly — a booking that happened before a question was changed is counted against the old version, not the new one.
How it works: current_version_id is captured at conversation creation — attribution is always accurate regardless of when the analysis runs.
Every version records the user who created it. Friyay operators performing a revert on behalf of a client are identified in the audit trail. The full version history is exportable as part of the campaign's audit log CSV.
How it works: Creator identity is stored on every campaign_versions row — accessible in the version history view and in the exported audit log.
We'll show you a full version timeline — manual changes, proposal-driven changes, and a revert.