diff --git a/content/docs/analyzers/LinterCop/LC0031.md b/content/docs/analyzers/LinterCop/LC0031.md
index 838ecf9..28e0a23 100644
--- a/content/docs/analyzers/LinterCop/LC0031.md
+++ b/content/docs/analyzers/LinterCop/LC0031.md
@@ -18,7 +18,7 @@ linkTitle = 'LC0031'
 
 `ReadIsolation`, introduced in Business Central 2023 wave 1 (v22), sets the isolation level on the **specific record variable** only. Other variables of the same table remain unaffected. The two are not equivalent, and that difference is the point: `ReadIsolation` keeps lock scope tight and predictable.
 
-There is a second reason to make the switch. [Tri-state locking](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-tri-state-locking) (default from v25 onward) performs reads after writes optimistically, and a single `LockTable()` switches the table back to pessimistic locking for the rest of the transaction:
+There is a second reason to make the switch. [Tri-state locking](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-tri-state-locking) (introduced in version 23, enabled by default, and always on from version 26) performs reads after writes optimistically, and a single `LockTable()` switches the table back to pessimistic locking for the rest of the transaction:
 
 > Explicitly using the LockTable method in code maintains the same behavior, disabling optimistic reads.