Revision history

Every time you save a policy — draft save, publish, or restore — InPolicy writes an immutable revision to history. History is append-only. Nothing is ever deleted.

Opening history

From a policy’s detail view, click the History tab. You’ll see a reverse-chronological list of revisions, each with:

• Kind — one of INITIAL, DRAFT_SAVE, PUBLISHED, RESTORED
• Author — a user’s name and avatar, or the PolicyBot marker if the revision was AI-generated
• Timestamp — when the revision was created
• Change summary — a short description of what changed (e.g. “Updated severity from 3 to 4; edited body”)

Revision kinds

Kind	When it’s created
INITIAL	The first time a policy is saved, whether from scratch or accepted from the Policy Inbox
DRAFT_SAVE	Each subsequent save-as-draft
PUBLISHED	Each save-and-publish (including the first)
RESTORED	When you restore a prior revision

Each revision is a full snapshot — title, body, severity, scope, the works. You can open any revision and see the exact state of the policy at that moment.

Reading a diff

Click any revision other than the first to see a diff against the previous revision. InPolicy shows:

• Body changes — word-level additions (green) and deletions (red/strikethrough) inline.
• Metadata changes — field name, old value → new value, for everything that changed (severity, area, tags, scope, etc.).

Diffs are computed at word granularity, so small wording tweaks show up cleanly. Large rewrites may look like a wall of deletions followed by a wall of additions — that’s expected.

Restoring a previous revision

From any revision in the history:

1. Click Restore.
2. InPolicy writes a new RESTORED revision containing the content of the revision you restored from.
3. The policy’s current state updates to that restored content.

Important: restore creates a new revision. It does not delete anything. You can always see in history that you restored from revision X.

Restore restores everything in the body and metadata, including severity, scope, effective dates, rationale, and tags. If you only want to revert text and keep new metadata, restore then manually re-apply the metadata.

PolicyBot-authored revisions

When PolicyBot creates or modifies a policy — most commonly when you accept a suggestion from the Policy Inbox — the revision is tagged author: PolicyBot with the model name recorded. This tagging is permanent: even if you heavily edit the body afterwards, the original INITIAL revision stays marked as PolicyBot-authored.

This matters for audit: you can always trace which policies originated from AI versus a human author.

What versioning does not do (yet)

This is the honest version:

• Publishing a new version does not automatically require anyone to re-acknowledge the policy. Acknowledgement workflows are not shipped in the current release.
• There’s no “minor vs. major” flag. Every publish is effectively a new version; it’s up to you to use the rationale/change-summary field to describe the nature of the change.
• There’s no retention limit. Revisions are stored indefinitely. That’s deliberate — compliance teams need the full audit trail — but it means the history tab can get long on a heavily-edited policy.

Common patterns

• Testing a change on a draft before publishing: save-as-draft repeatedly, iterate, then publish once you’re happy. All the intermediate drafts remain in history if anyone asks what you tried.
• Rolling back a bad publish: go to the most recent PUBLISHED revision that was correct, click Restore, then click Save & publish to re-publish the restored content.
• Seeing who last touched a policy: the top revision in history tells you. The Author column is always a real user or the PolicyBot marker.