@@ -119,6 +119,28 @@ edit (two registered `description` strings) and was ruled a hold, as 1.0.4's was
   for one date should cost you that date, not the twenty fields beside it that parsed. The
   component is now left unset, which is what "lost" already means everywhere else in that pass.
 
+- **Java: an unparseable decimal became `0` instead of null.** `DataConverter.toBigDecimal`
+  caught the `NumberFormatException` and returned `BigDecimal.ZERO` — the one wrong answer
+  available, because `0` is a plausible amount, so unreadable input reached a money field as a
+  real-looking value with nothing to distinguish it from a genuine zero. Every sibling
+  converter (`toInt` / `toLong` / `toDouble` / `toFloat`) throws for the same input; decimal
+  was the lone exception. It now throws too, and the lenient extract tier's never-throws guard
+  turns that into a lost component — so the answer there is `null`, which is the honest one.
+
+- **Java/Kotlin: a declared `field.decimal @isArray` was silently dropped.** `DataTypes` had no
+  `DECIMAL_ARRAY`, and `arrayTypeFor(DECIMAL)` mapped decimal to ITSELF with a comment saying
+  arrays-of-decimal "aren't in the metamodel" so the declaration would "degrade gracefully". It
+  did not degrade gracefully: the loader accepts the declaration, all five ports generate code
+  for it, and C# populates it correctly (now pinned by value in
+  `Fr010DelegatingMirrorLockStepTests`) — so this was a JVM gap presented as a design position,
+  not a metamodel rule. Added `DECIMAL_ARRAY` plus a `toBigDecimalArray` that element-converts
+  through `toBigDecimal` rather than a double, so precision survives the round trip. The new
+  member takes id 22 rather than a slot beside `DECIMAL=10`: those ids are persisted
+  identifiers, and renumbering the existing members to keep the enum tidy would silently
+  repoint stored data. Kotlin inherits the fix — it consumes the same `metadata` module — and
+  C#, TypeScript and Python needed no change (that conversion table is JVM-only; TS binds
+  `field.decimal` to `string` and Python to `Decimal`).
+
 - **Java: `DataConverter.toDate` could not parse an ISO-8601 date.** The `String` arm was a bare
   `Long.parseLong`, so it accepted epoch milliseconds and nothing else — a plain `"2026-03-04"`
   threw `NumberFormatException`. Since that is the form `normalization.md` puts on the wire, no
 
@@ -162,6 +162,38 @@ public void Generated_delegating_extract_populates_nested_decimals()
         Assert.Equal(7m, many[1].GetType().GetProperty("v")!.GetValue(many[1]));
     }
 
+    [Fact]
+    public void Generated_delegating_extract_populates_a_nested_decimal_ARRAY()
+    {
+        // The compile gates above prove a decimal ARRAY emits code that builds. They do not
+        // prove the VALUES arrive: DlgList(..., DlgDecimal) could return an empty list, or
+        // round every element through a double, and still compile. Java cannot do this at all
+        // (its object model has no DECIMAL_ARRAY conversion, so the component is dropped), so
+        // whether C# genuinely supports the shape is a fact worth pinning rather than assuming.
+        var root = Load(NestedScalarModel(FIELD_SUBTYPE_DECIMAL, true));
+        var asm = Compile(root);
+
+        var parserType = asm.GetType("Acme.Generated.ProbeParser")!;
+        var extract = parserType.GetMethod("ExtractLenient",
+            new[] { typeof(MetaObject), typeof(string), typeof(MetaObjects.Render.Extract.ExtractOptions) })!;
+
+        const string dirty = "```json\n{ \"id\": \"A-1\", \"single\": { \"v\": [1.25, 2.5, 7] } }\n```";
+
+        var result = extract.Invoke(null, new object?[] { root.FindObject("Probe")!, dirty, null })!;
+        var data = result.GetType().GetProperty("Data")!.GetValue(result)!;
+
+        var single = data.GetType().GetProperty("single")!.GetValue(data);
+        Assert.NotNull(single);
+        var v = (IEnumerable)single!.GetType().GetProperty("v")!.GetValue(single)!;
+        var elems = v.Cast<object?>().ToList();
+
+        Assert.Equal(3, elems.Count);
+        // decimal?, element-typed — NOT string, and precision preserved.
+        Assert.Equal(1.25m, elems[0]);
+        Assert.Equal(2.5m, elems[1]);
+        Assert.Equal(7m, elems[2]);
+    }
+
     // ---- harness ----
 
     private static void AssertGeneratedCompiles(string subType, bool isArray)
 
@@ -150,31 +150,31 @@ public void coercedScalarsCarryTheirValuesAndMalformedOnesBecomeNull() throws Ex
             List<?> counts = (List<?>) get(p, "counts");
             assertEquals("int array is element-typed, not List<String>", List.of(3, 4), counts);
 
-            // A decimal ARRAY is deliberately NOT a metamodel shape: DataTypes has no
-            // DECIMAL_ARRAY ("arrays-of-decimal aren't in the metamodel" — the same position
-            // C# records as SP-A "decimal is single-only"), so DataTypes.arrayTypeFor maps
-            // field.decimal @isArray to DECIMAL and the assembled value cannot be populated.
-            // What matters is the FAILURE MODE: the component is lost, and the rest of the
-            // payload still parses. Before the never-throws fix in MetaObjectExtractor.assemble
-            // this threw out of the whole extract. It still COMPILES (see
-            // GeneratedScalarExtractLockStepTest) — a declared shape must never emit broken code
-            // even when the runtime cannot fill it.
-            assertNull("decimal array is unsupported by the object model — lost, not fatal",
-                    get(p, "rates"));
+            // A decimal ARRAY now populates, element-typed and precision-exact. It used to be
+            // dropped silently: DataTypes had no DECIMAL_ARRAY, so arrayTypeFor(DECIMAL)
+            // returned DECIMAL, the conversion failed, and the component came back null with
+            // no error — while the loader accepted the declaration and every port generated
+            // code for it. C# populated the same shape correctly, so this was a JVM port
+            // divergence rather than a metamodel position.
+            List<?> rates = (List<?>) get(p, "rates");
+            assertNotNull("decimal array must populate", rates);
+            assertEquals("rates size", 2, rates.size());
+            assertTrue("rates element is BigDecimal, not String", rates.get(0) instanceof BigDecimal);
+            assertEquals("rates[0] precision", 0, ((BigDecimal) rates.get(0)).compareTo(new BigDecimal("1.25")));
+            assertEquals("rates[1] precision", 0, ((BigDecimal) rates.get(1)).compareTo(new BigDecimal("2.5")));
 
             // --- NEVER-THROWS: a malformed component does not cost the whole extract ---
             assertNull("malformed date degrades to null", get(p, "badDate"));
             assertEquals("a bad field must not cost the good ones", "W-1", get(p, "ref"));
 
-            // KNOWN HAZARD, asserted as-is so it is visible rather than silently relied on:
-            // DataConverter.toBigDecimal returns BigDecimal.ZERO for an unparseable string
-            // instead of null, so "not-a-number" reaches the record as 0 — a plausible-looking
-            // money value standing in for "we could not read this". Null would be the honest
-            // answer. NOT changed here: toBigDecimal is a core converter the OMDB persistence
-            // path also uses, so flipping its contract is a decision with its own blast radius,
-            // not a drive-by. When it is fixed, this assertion flips to assertNull.
-            assertEquals("unparseable decimal currently becomes ZERO, not null",
-                    BigDecimal.ZERO, get(p, "bad"));
+            // An unreadable decimal is NULL, not zero. DataConverter.toBigDecimal used to
+            // swallow the NumberFormatException and return BigDecimal.ZERO, which is the one
+            // wrong answer available: 0 is a plausible amount, so unreadable input became a
+            // real-looking money value indistinguishable from a genuine zero. It now throws
+            // like every sibling converter does for the same input, and assemble's
+            // never-throws guard turns that into a lost component.
+            assertNull("unparseable decimal must be null, never a plausible-looking 0",
+                    get(p, "bad"));
         }
     }
 
 
@@ -16,8 +16,7 @@ public enum DataTypes {
     STRING(8), DATE(9),
 
     // Exact decimal (BigDecimal-backed; field.decimal). Slot 10 (between DATE=9
-    // and BOOLEAN_ARRAY=11). No DECIMAL_ARRAY — arrays-of-decimal are not a thing
-    // in the metamodel; getArrayEquivalent maps DECIMAL to itself (see below).
+    // and BOOLEAN_ARRAY=11).
     DECIMAL(10),
 
     // Numeric  Arrays
@@ -30,6 +29,18 @@ public enum DataTypes {
     // Object and Object Array
     OBJECT(20), OBJECT_ARRAY(21),
 
+    // Exact-decimal array (field.decimal @isArray). Added at 22 rather than beside
+    // DECIMAL=10 because the ids are PERSISTED identifiers — renumbering the existing
+    // members to keep the enum tidy would silently repoint stored data.
+    //
+    // This used to be absent, with getArrayEquivalent mapping DECIMAL to ITSELF so the
+    // declaration "degraded gracefully". It did not degrade gracefully: the loader accepts
+    // field.decimal @isArray, every port generates code for it, and the conversion then
+    // failed and the component was dropped with no error. C# populates the shape correctly
+    // (proven by value in Fr010DelegatingMirrorLockStepTests), so the JVM being unable to
+    // hold it was a port divergence, not a metamodel position.
+    DECIMAL_ARRAY(22),
+
     // Custom
     CUSTOM(99);
 
@@ -79,6 +90,7 @@ private DataTypes( int id ) {
             case 18: valueClass=List.class; isArray=true; itemClass=String.class;  isStringArray=true;  break;
             case 19: valueClass=List.class; isArray=true; itemClass=Date.class;    isDateArray=true;    break;
             case 21: valueClass=List.class; isArray=true; itemClass=Object.class;  isObjectArray=true;  break;
+            case 22: valueClass=List.class; isArray=true; itemClass=java.math.BigDecimal.class; isNumericArray=true; break;
 
             case 99: valueClass=Object.class; isCustom=true; break;
 
@@ -182,10 +194,7 @@ public DataTypes getArrayEquivalent() {
             case OBJECT: return OBJECT_ARRAY;
             case CUSTOM: return OBJECT_ARRAY; // Custom objects become object arrays
 
-            // No DECIMAL_ARRAY exists (arrays-of-decimal aren't in the metamodel);
-            // map to itself so @isArray on a decimal degrades gracefully rather
-            // than throwing. Matches the "no array form" intent of slot 10.
-            case DECIMAL: return DECIMAL;
+            case DECIMAL: return DECIMAL_ARRAY;
 
             // Already arrays - return as-is
             case BOOLEAN_ARRAY:
@@ -198,6 +207,7 @@ public DataTypes getArrayEquivalent() {
             case STRING_ARRAY:
             case DATE_ARRAY:
             case OBJECT_ARRAY:
+            case DECIMAL_ARRAY:
                 return this;
 
             default:
 
@@ -50,6 +50,7 @@ public static Object toType( DataTypes dataType, Object val ) {
 				return unsupported(dataType,val);
 
 			case DATE_ARRAY: return toDateArray( val );
+			case DECIMAL_ARRAY: return toBigDecimalArray( val );
 			case STRING_ARRAY: return toStringArray( val );
 			case OBJECT_ARRAY: return toObjectArray( val );
 
@@ -337,7 +338,13 @@ public static java.math.BigDecimal toBigDecimal( Object val )
 	    if ( val instanceof String ) {
 	        String s = ((String) val).trim();
 	        if ( s.isEmpty() ) return null;
-	        try { return new java.math.BigDecimal( s ); } catch ( NumberFormatException ignored ) { return java.math.BigDecimal.ZERO; }
+	        // Let NumberFormatException propagate, exactly as toInt/toLong/toDouble/toFloat do
+	        // for the same input. This used to swallow it and return ZERO, which is the one
+	        // wrong answer available: 0 is a PLAUSIBLE amount, so unreadable input became a
+	        // real-looking money value with nothing to distinguish it from a genuine zero.
+	        // Callers that must not fail — the lenient extract tier — already treat a throw
+	        // here as "component lost" (MetaObjectExtractor.assemble), which yields null.
+	        return new java.math.BigDecimal( s );
 	    }
 	    if ( val instanceof Boolean ) return ((Boolean) val) ? java.math.BigDecimal.ONE : java.math.BigDecimal.ZERO;
 	    if ( val instanceof java.math.BigInteger ) return new java.math.BigDecimal( (java.math.BigInteger) val );
@@ -351,8 +358,9 @@ public static java.math.BigDecimal toBigDecimal( Object val )
 	    }
 	    if ( val instanceof Date ) return java.math.BigDecimal.valueOf( ((Date) val).getTime() );
 
-	    try { return new java.math.BigDecimal( val.toString().trim() ); } catch ( NumberFormatException ignored ) {}
-	    return java.math.BigDecimal.ZERO;
+	    // Same contract as the String arm above and as every sibling converter's tail: parse,
+	    // and throw if it is not a number. No ZERO fallback.
+	    return new java.math.BigDecimal( val.toString().trim() );
 	} // toBigDecimal
 
 	/**
@@ -833,6 +841,41 @@ public static List<Date> toDateArray(Object val) {
 	/**
 	 * Convert value to Double array (List&lt;Double&gt;)
 	 */
+	/**
+	 * Convert the object value to a List of BigDecimal.
+	 *
+	 * <p>Element-converts through {@link #toBigDecimal(Object)} rather than a double, so a
+	 * decimal array stays precision-exact — the reason {@code field.decimal} exists at all.
+	 * Shape mirrors {@link #toDoubleArray(Object)} exactly, including the comma-split for a
+	 * single delimited String.</p>
+	 *
+	 * @param val Value
+	 * @return List of BigDecimal
+	 */
+	public static List<java.math.BigDecimal> toBigDecimalArray(Object val) {
+		if (val == null) return null;
+
+		if (val instanceof List<?>) {
+			List<?> list = (List<?>) val;
+			return list.stream()
+				.map(DataConverter::toBigDecimal)
+				.collect(java.util.stream.Collectors.toList());
+		} else if (val instanceof String) {
+			String s = (String) val;
+			if (s.trim().isEmpty()) return new java.util.ArrayList<>();
+
+			if (s.contains(",")) {
+				return java.util.Arrays.stream(s.split(","))
+					.map(item -> toBigDecimal(item.trim()))
+					.collect(java.util.stream.Collectors.toList());
+			} else {
+				return java.util.Arrays.asList(toBigDecimal(s.trim()));
+			}
+		} else {
+			return java.util.Arrays.asList(toBigDecimal(val));
+		}
+	}
+
 	public static List<Double> toDoubleArray(Object val) {
 		if (val == null) return null;