Update safely, and what never changes

Schema upgrades

The domain model uses versioned custom tables. Upgrades run on activation and on update. If the schema cannot be read or migrated, governance fails closed — requests are refused rather than evaluated against a schema the plugin does not understand.

That is the correct behaviour and not a bug to work around. A refused request is recoverable; a request evaluated against a half-migrated permission table is not.

What a release will never do quietly

• Widen an existing permission. A decision you made stays the decision you made.
• Shorten audit retention. Shortening destroys evidence and always requires explicit confirmation from an administrator.
• Move a security control behind a paid plan. Every security control is identical in every edition.

After updating

1. Open readiness and run runtime verification. Do not assume the update landed correctly.
2. Verify the audit chain, so you know the record is intact across the upgrade.
3. Read the changelog before diagnosing anything that behaves differently. Changed behaviour that is documented is not a fault.

If the licence server is unreachable

An unreachable licence server is never treated as a verdict. A network failure will not be read as an invalid licence, and the plugin will not disable itself because it could not reach us.

Related guides

• SetupVerify the control plane after activation

  Use readiness scoring and runtime verification to test the governance controls on your installed site, rather than assuming the install landed correctly.

• EvidenceVerify the audit chain

  HMAC-SHA-256 chaining with a signed head means the record can prove it has not been edited. How to run a full-chain verification and when it is worth doing.

• SetupDeactivate, uninstall, and your data

  The difference between deactivating and uninstalling, why data removal is opt-in, and why removing the plugin cannot leave an agent with extra privileges.