diff --git a/Tests/XSTSSuiteTests.swift b/Tests/XSTSSuiteTests.swift
index 9e4bf28..aeb8150 100644
--- a/Tests/XSTSSuiteTests.swift
+++ b/Tests/XSTSSuiteTests.swift
@@ -89,7 +89,9 @@ struct XSTSSuiteTests {
     /// 8 -> 7: an identity-constraint field that selects a node whose declared type is
     /// not simple (the ur-type anyType, no xsi:type rescue) is rejected per
     /// cvc-identity-constraint.3 (idZ010). See ``XSDParser/identityNonSimpleFieldKeys``.
-    private let knownInstanceInvalidAccepted = 7
+    /// 7 -> 6: mgO013.i reclassified as contested (see the excluded set). Its
+    /// `invalid` is unsatisfiable jointly with its own `valid` schemaTest.
+    private let knownInstanceInvalidAccepted = 6
     /// Instance tests excluded from the counts because their expected validity is not
     /// authoritative, mirroring how the suite's own `status="queried"` entries are
     /// skipped. Each must carry a spec-grounded justification; this is never a place to
@@ -125,7 +127,18 @@ struct XSTSSuiteTests {
     ///   collection's declarations on conflict) is conformant. Confirmed by an
     ///   adversarial analysis that separated these from schA7.i, whose `invalid` IS
     ///   spec-grounded (a genuine policy deviation, left in the count).
-    private static let specDivergentInstances: Set<String> = ["anyURI_a004_1339.i", "schA2.i", "schA5.i"]
+    ///
+    /// - `mgO013.i`: a `redefine` whose group `all{e1(1,1)}` redefines a base
+    ///   `all{e1(0,0)}` without referencing itself. `src-redefine` clause 6.2.2 makes
+    ///   that a restriction obligation, and `all{e1(1,1)}` is not a valid restriction
+    ///   of `all{e1(0,0)}` (Occurrence Range OK: derived max 1 > base max 0), so
+    ///   enforcing it rejects the schema, contradicting the `valid` schemaTest and
+    ///   producing a valid-schema-rejected false positive. Yet §4.2.2 makes the type's
+    ///   `group` reference resolve to the redefined `all{e1(1,1)}`, against which the
+    ///   single-`e1` instance is valid. The `valid` schema and `invalid` instance
+    ///   expectations are mutually exclusive; libxml2 accepts both. Confirmed by an
+    ///   adversarial analysis that found no third path.
+    private static let specDivergentInstances: Set<String> = ["anyURI_a004_1339.i", "schA2.i", "schA5.i", "mgO013.i"]
 
     @Test("Every XSTS case behaves: compile, reject, validate, invalidate")
     func test_suite() throws {
diff --git a/docs/xsts-deviations.md b/docs/xsts-deviations.md
index ee24711..48f62de 100644
--- a/docs/xsts-deviations.md
+++ b/docs/xsts-deviations.md
@@ -130,11 +130,26 @@ separated the contested from the genuine):
   the reference on a construct whose composition order in a cycle the spec does not
   pin down. Tracked as deferred scope, not excluded.
 
+`mgO013.i` is reclassified as contested (`invalid-instances-accepted` 7 -> 6).
+A `redefine` defines `group = all{e1(1,1)}`, redefining a base `all{e1(0,0)}`
+without referencing itself. `src-redefine` clause 6.2.2 makes a no-self-reference
+group redefine a restriction obligation, and `all{e1(1,1)}` is not a valid
+restriction of `all{e1(0,0)}` (Occurrence Range OK fails: derived max 1 > base
+max 0), so enforcing it rejects the schema, a valid-schema-rejected false positive
+against the `valid` schemaTest. Yet §4.2.2 makes the referencing type resolve to
+the redefined `all{e1(1,1)}`, against which the single-`e1` instance is valid. The
+`valid` schema and `invalid` instance expectations are mutually exclusive; libxml2
+accepts both. An adversarial analysis found no third path. The identity-field
+case `idZ010` (a `key`/`keyref` field selecting a non-simple `anyType` node) was a
+genuine bug and is fixed (reject per cvc-identity-constraint.3).
+
 Takeaway: on the schema side, libxml2 parity is reached except the one case now
 fixed; the remaining nine are a deliberate choice to exceed the reference. On the
-instance side the Ethiopic-digit `\d`/`\D` and `\i`/`\c` name-class cases are now
-fixed (reference-aligned) and `anyURI_a004_1339` is shown contested; the remaining
-reference-aligned cases are real but each needs its own analysis, not a sweep.
+instance side the Ethiopic-digit `\d`/`\D` and `\i`/`\c` name-class cases and the
+identity-field `idZ010` are now fixed (reference-aligned); `anyURI_a004`, `schA2`,
+`schA5`, and `mgO013` are shown contested; the remaining cases (`schA7` policy,
+`schU3/4/5` circular redefine that exceeds libxml2, `particlesZ001` which the suite
+itself marks ambiguous, `targetns00101m`) are real but each needs its own analysis.
 
 ## Category A: genuine correctness bugs