No system should ever fail silently if a required field suddenly goes missing or has the wrong type/unit.
E.g., give rows a type, give columns a type, and then if you multiply two matrices, see if the type of the columns of the first matrix and the type of the rows of the second matrix match.
Also, the typesystem could use units, just as they are used in physics.
http://www-ksl.stanford.edu/knowledge-sharing/lib/unit-conve...
Given the way this appears to be defining some sort of class-based hierarchy, with the correct type requirements this code should perform exactly the sort of unit/type checking the grandparent post wanted, but I didn't go digging into the rest of the project files to confirm this code defined things in the correct manner for that to work.
You could even do it with SQL field (column) names and natural joins. The performance hit is even bigger and discipline/retraining is even bigger, as few SQL users are used to thinking about column names (rather than types) as type definitions.
Further, this would only catch a class of bugs that are relatively easy to spot manually. The difficult case is when the processes that generated the numbers have slowly changed in time (e.g., you have a very different mix of visitors/customers now than during model training).