Skip to content

Policy Versioning

Every change to a policy in Mayo ASPM creates a new version. Version history lets you track changes over time, compare revisions, and roll back to a previous version if needed.

How versioning works

v1 (initial) ──▶ v2 (edit) ──▶ v3 (edit) ──▶ v4 (current)
                                    │
                                    └── rollback target
  • Each save creates a new version with an incrementing number.
  • The current version is the one that is evaluated in production (if the policy is active).
  • Previous versions are read-only snapshots.
  • Versions are never deleted — the full history is retained.

Viewing version history

  1. Open a policy from Policies in the left sidebar.
  2. Click the History tab.
  3. You see a list of all versions:
Version Date Author Summary
v4 2026-04-14 alice@acme.com Added EPSS threshold rule
v3 2026-04-10 bob@acme.com Fixed conflict in severity rules
v2 2026-04-05 alice@acme.com Added test-file suppression
v1 2026-04-01 alice@acme.com Initial policy creation

Comparing versions

  1. In the History tab, select two versions using the checkboxes.
  2. Click Compare.
  3. A diff view shows what changed between the two versions:
  package mayo.triage

  import rego.v1

  decision := "accept" if {
      input.finding.severity == "critical"
  }

+ decision := "accept" if {
+     input.finding.severity == "high"
+     input.finding.epss_score > 0.7
+ }

  decision := "reject" if {
      input.finding.severity == "info"
  }

Rolling back

To revert a policy to a previous version:

  1. Open the History tab.
  2. Click on the version you want to restore.
  3. Click Restore this version.
  4. Confirm the rollback.

Rollback creates a new version

Rolling back to v2 doesn't delete v3 and v4. Instead, it creates a new v5 whose content matches v2. The full history is preserved.

Version metadata

Each version stores:

Field Description
Version number Auto-incrementing integer
Timestamp When the version was saved
Author The user who made the change
Rego source The complete policy code
Scope The policy's scope at that point in time
Active status Whether the policy was active at that point
Commit message Optional message describing the change

Adding commit messages

When saving a policy, you can add a commit message in the Save dialog:

  1. Make your changes in the editor.
  2. Click Save.
  3. Enter a commit message (e.g., "Added EPSS threshold for high-severity findings").
  4. Click Confirm.

Tip

Commit messages make version history much easier to navigate. Treat them like git commit messages — concise and descriptive.

API access to versions

List versions

curl https://mayoaspm.com/api/policies/{policy_id}/versions \
  -H "Authorization: Bearer mayo_ak_..."

Response:

{
  "versions": [
    {
      "version": 4,
      "created_at": "2026-04-14T09:30:00Z",
      "author": "alice@acme.com",
      "message": "Added EPSS threshold rule",
      "active": true
    },
    {
      "version": 3,
      "created_at": "2026-04-10T14:15:00Z",
      "author": "bob@acme.com",
      "message": "Fixed conflict in severity rules",
      "active": false
    }
  ]
}

Get a specific version

curl https://mayoaspm.com/api/policies/{policy_id}/versions/3 \
  -H "Authorization: Bearer mayo_ak_..."

Restore a version

curl -X POST https://mayoaspm.com/api/policies/{policy_id}/versions/3/restore \
  -H "Authorization: Bearer mayo_ak_..."

Audit trail

Policy version history serves as an audit trail for compliance. You can answer questions like:

  • Who changed the triage policy and when?
  • What was the policy at the time a specific finding was triaged?
  • When was a rule added or removed?

Finding evaluation log

Each finding records which policy version was used to evaluate it. Navigate to a finding's Timeline to see the exact policy version that produced its triage decision.

Best practices

  1. Always add commit messages — future you will thank present you.
  2. Review diffs before saving — catch unintended changes.
  3. Test before activating — use the playground to validate changes before they go live.
  4. Use rollback instead of manual revert — it preserves history correctly.

Next steps