Published October 29, 2026 ยท Independent educational guide
Read Matrix Products Through Axis Labels, Order and Units
An AI explanation can print a plausible matrix product while losing the meaning of its rows and columns. Two compatible rectangular arrays tell you that a calculation can be formed. They do not establish that the contracted positions represent the same things. Before accepting a product, identify what each axis names, how those names align, what units travel through each multiplication, and which unknown values remain unresolved. These questions matter when reviewing an invented allocation exercise, a spreadsheet explanation or a proposed calculation in an AI handoff.
This guide develops one small, explicit row-by-column calculation. All names, values, labels and proposed outputs below are original fictional teaching inputs. They are not business measurements, observed model responses, client data or evidence about a deployed system. The accompanying worksheet supplies six case groups. Its independent arithmetic checks test those supplied groups only. No NumPy function, language model, embedding service or production application was executed, and the checks do not certify a general matrix library or the meaning of actual records.
Read the two-dimensional contract before the numbers
For the ordinary two-dimensional example here, write the left array as n rows by k columns and the right array as k rows by m columns. The repeated k describes the positions to be paired and summed. Each left row meets each right column, producing one output cell. The result therefore has n rows and m columns. State this contract in words alongside the dimensions: output rows inherit the left row roles, output columns inherit the right column roles, and the shared positions disappear into the sums.
NumPy's matmul documentation, read October 29, 2026, describes ordinary two-dimensional matrix products and the matching inner dimensions. It also documents separate behavior for one-dimensional inputs and higher-dimensional stacks. Those are distinct interface cases; a two-dimensional explanation should not silently promise their behavior. This guide uses only authored rectangular lists and explicit finite arithmetic. It does not reproduce the documentation's worked examples or claim that the local checks test NumPy's implementation, broadcasting, dtype handling, performance or numerical behavior.
In a review request, include dimensions and axis labels before asking for an explanation. A useful original prompt is: Explain this declared two-dimensional product, retain the supplied row and column labels, show one cell's terms, and identify unresolved assumptions. That instruction narrows the requested explanation. It does not turn the supplied labels into verified identities or establish that the proposed product answers a real operating question. If the source lacks axis descriptions, the useful first output may be a request for those descriptions rather than a completed numerical table.
Build a product with a visible shared axis
Case A supplies two fictional task bundles called Cedar and Maple. The left array has columns named EX-A, EX-B and EX-C. Cedar's row is 1, 2, 0; Maple's row is 0, 1, 3. These are declared counts of task occurrences in a teaching exercise. The right array has rows EX-A, EX-B and EX-C, in that order, and columns called amber credits and blue credits. Its rows are 2, 1; 4, 0; and 1, 5. Credit units are invented, not currency, staffing standards or measured effort.
The Cedar amber cell is 1 times 2 plus 2 times 4 plus 0 times 1, giving 10 invented amber credits. Cedar blue is 1 times 1 plus 2 times 0 plus 0 times 5, giving 1. Maple amber is 0 times 2 plus 1 times 4 plus 3 times 1, giving 7. Maple blue is 0 times 1 plus 1 times 0 plus 3 times 5, giving 15. The complete authored product is therefore rows 10, 1 and 7, 15, with Cedar and Maple still naming the rows.
The shape check is equally concrete. A two-by-three left array and a three-by-two right array produce a two-by-two result. There are four output cells, and every cell contains three paired multiplication terms. Neither the output cell count nor the number of terms measures model accuracy, task completion or business value. They describe this declared calculation. A reviewer can inspect one term and ask which source cell supplied each factor, then repeat that inspection for the remaining positions without making any claim about an actual team.
Keep matrix multiplication separate from cellwise multiplication
A common ambiguity begins with the word multiply. A proposed explanation might mean pair corresponding cells, multiply every value by one scalar, or perform the row-by-column sums used here. Those are different requests. Resolve the operation before comparing outputs. Writing an operator symbol alone does not settle how a particular application interprets its operands. Preserve the source's declared operation and ask about the application contract when that information is absent.
Case B makes the distinction visible with two square arrays. Let X have rows 1, 2 and 0, 1. Let Y have rows 2, 0 and 3, 1. The row-by-column product XY has rows 8, 2 and 3, 1. The corresponding-cell products have rows 2, 0 and 0, 1. Both proposed results are two by two, so shape alone cannot distinguish the intended operation. Checking the upper-left entry does: 1 times 2 plus 2 times 3 equals 8, while 1 times 2 alone equals 2.
This is a useful place to improve an AI request. Ask for the upper-left output's complete expression before requesting a long verbal interpretation. The expression exposes whether the explanation is summing across the shared axis. It still cannot establish that the task labels, amounts or operation were appropriate to a business decision. Keep a separate statement of purpose: in this exercise the result totals invented credit requirements from invented occurrence counts. It is not an observed cost estimate, recommendation or promise of sufficient resources.
Check operand order even when both products fit
With the same square X and Y, the reversed product YX has rows 2, 4 and 3, 7. This differs from XY's rows 8, 2 and 3, 1. Both products are dimensionally possible. That makes a successful shape check an incomplete review. Preserve which array appears on the left and which appears on the right, then show the corresponding axis roles. Reversing the expression changes the paired terms and may change what the result could mean under a declared interpretation.
Avoid repairing an unfamiliar formula merely because another order produces a number that looks convenient. Ask what the original author intended to transform, aggregate or combine. If that purpose is unknown, report the two explicit calculations and leave their applicability unresolved. A numeric difference between the two products is evidence about these supplied arrays. It is not evidence that a real model made an error, that one operating plan is better, or that a particular software package reversed its operands.
This distinction also helps when a document uses ordinary-language phrases such as apply the mapping or combine the tables. Those phrases may omit direction. Copy the expression and attach an axis sentence to it: these left rows are paired with these right columns across these named intermediate positions. If the sentence cannot be written from the available source, the missing information is substantive. Generating more decimals or a polished narrative will not supply it.
Match labels before trusting matching dimensions
Case C returns to the two-by-three task array from Case A. Imagine that a second copy of the right table arrives with row labels EX-C, EX-A and EX-B, and rows 1, 5; 2, 1; and 4, 0. This is the same declared label-to-value mapping in a different incoming order. If a positional calculation uses it without alignment, the resulting rows are 5, 7 and 14, 1. Those values differ from the label-aligned product 10, 1 and 7, 15.
The arithmetic is not enough to choose whether real labels identify the same underlying entities. In this fictional example, their equality is an explicit teaching assumption. Under that assumption, reordering the right rows to EX-A, EX-B, EX-C restores the first product. In an actual handoff, record where the label mapping came from and whether it is authoritative for the intended task. Similar names, matching abbreviations or equal row counts do not independently prove identity.
Ask the reviewer to expose the alignment operation as a separate step. Show incoming labels, desired labels and the resulting permutation. Preserve the original incoming order in the evidence rather than replacing it invisibly. If a repeated or missing label prevents a unique mapping, stop the proposed labeled calculation and explain that condition. An arbitrary first match can create an apparently complete matrix while discarding the very ambiguity that needed attention.
Treat transposition as an axis change
Case D supplies the transpose of the Case A right array. It has rows 2, 4, 1 and 1, 0, 5, giving a two-by-three shape. The original left array is also two by three. Their inner dimensions are three and two, so the ordinary product in that stated order is incompatible. This is a shape finding about the supplied two-dimensional arrays. It is not a diagnosis of an actual file, model or software error.
Transposing that second array again produces the original three-by-two right array and permits the original product. However, permission to perform a transpose is a meaning question. The source must establish whether rows now name credit categories and columns name task types, or whether the file already expressed a different relationship. A reviewer should not transpose automatically whenever it makes dimensions fit. Many unintended expressions can be made calculable by moving axes; that does not make them appropriate.
Write before and after axis descriptions in the review note. Before transposition, the teaching table has credit-category rows and task-type columns. After transposition, it has task-type rows and credit-category columns. The labels move with the values. A proposed edit that swaps numbers but leaves old headers in place creates a different error. The worksheet checks the authored shape and value relationships, while the actual document's intended orientation would still need its own source evidence.
Carry units through the shared-axis sum
Case E makes the invented units more explicit. The occurrence counts in the left array are counts, and each right-table entry is a declared number of a particular credit category per occurrence of its row's task type. Multiplying count by credits per occurrence yields credits. The Cedar amber result of 10 is an amber-credit quantity; Cedar blue's 1 is a blue-credit quantity. The units support those separate sums under the authored definitions.
The two output columns are not automatically interchangeable. Adding 10 amber credits to 1 blue credit gives an arithmetic total of 11 numeric entries, but the exercise supplies no conversion between the categories. It therefore supplies no single combined credit quantity with an agreed interpretation. An AI explanation should retain the two columns and state that a combined measure needs an explicit rule. A convenient single number is not a substitute for such a rule.
The same caution applies to an average across output rows. Cedar and Maple are different fictional bundles. Their arithmetic mean is a calculation over these supplied bundles, not a representative workload estimate. No demand distribution, frequency or planning authority has been supplied. If someone wants an aggregate, first specify which bundles are included and how their contributions are weighted. Keep that additional operation separate from the original matrix product so a reader can see which assumptions generated each number.
Preserve unknown entries rather than silently filling zero
Case F changes Cedar's EX-C occurrence count from the confirmed zero in Case A to an unknown value. Cedar's confirmed EX-A and EX-B terms contribute amber 10 and blue 1. The full Cedar row is unresolved because the EX-C terms depend on the missing count. A proposed display may label the two confirmed subtotals clearly, but it should not label them the completed product. Missing data and confirmed zero produce different evidence states even when a particular calculation happens to coincide.
Two explicit hypothetical completions illustrate the distinction. If the unknown count were later confirmed as zero, Cedar's result would be 10, 1. If it were later confirmed as two, Cedar's result would be 12, 11. These are conditional authored calculations. Neither is an estimate of the missing count or an observed outcome. Reporting both can help someone identify what additional information matters, provided the explanation keeps the hypothetical condition adjacent to each result.
Unknown values can also interact with a zero coefficient. If a separate declared output used zero for the missing position's coefficient, its contribution would be zero for every finite numeric completion under ordinary arithmetic. That algebraic observation would not make the missing source field known. Preserve the distinction between a result being insensitive to a field and the field being complete. The current worksheet checks only its two stated finite completions and makes no claim about null propagation in any library.
Review a proposed AI explanation in small steps
Begin by saving the supplied arrays, axis descriptions, units and requested operation together. Give the two arrays distinct names and preserve their version or source locators if available. Record whether all entries are known and whether rectangular shape has actually been checked. This preparation supports a concrete explanation request. It does not authorize an import, update or deployment, and it does not confirm that the supplied data reflects a current real process.
Next ask for the output shape and axis roles without interpretation of the numeric results. Check that statement against the input labels. Then ask for one cell's paired terms, followed by the remaining product. Keep the calculation short enough to inspect. A longer output is not necessarily a better explanation. If the reviewer notices an ambiguity in operation, alignment or units, return to that question before elaborating the narrative.
Finally compare any proposed interpretation with the declared purpose. A statement that Cedar requires 10 invented amber credits follows the teaching definitions. A statement that Cedar is more productive, cheaper or ready for deployment does not follow. Such claims require information beyond this exercise. Record which interpretations remain unresolved, and retain the original inputs alongside the reviewed explanation so a later reader can reconstruct what was actually checked.
Make the worksheet useful without overstating its checks
The downloadable case worksheet records six authored groups: one labeled rectangular product; an operation-and-order contrast; an incoming-label permutation; an orientation mismatch; unit-category separation; and an unknown-entry sensitivity exercise. Its companion local check uses explicit integer arithmetic and supplied labels. That design makes the examples reproducible without turning the worksheet into an executable matrix utility or claiming to cover all valid or invalid array forms.
A passing assertion means that a stated relationship held for the supplied finite input. For example, it can establish that the Case A output equals the four manually declared numbers, or that the Case D inner dimensions differ. It cannot establish that a label corresponds to an actual task, that a source count is correct, or that an AI explanation understood the business purpose. Keep these separate findings visible when summarizing the exercise.
The local Python runtime and check count should be recorded with the results. The linked NumPy page supplies interface vocabulary; the local checks do not run NumPy and therefore do not establish behavior for that documentation's version. If the examples later become part of a real application review, add application-specific input handling and output evidence under a new, explicit scope. Do not relabel this small teaching exercise as evidence about a model or production integration.
Preserve an inspectable correction
If an explanation confuses an operation or axis, correct the specific statement and retain a short record of what changed. For example, a teaching correction can say that the earlier expression used corresponding-cell multiplication while the declared request required row-by-column sums. Include the corrected upper-left expression and the resulting four cells. Avoid expanding this into a claim about the reliability of a real model when no model output was observed.
If a later source changes a value, distinguish that input revision from a calculation repair. An updated count can change a correctly calculated product without making the earlier arithmetic wrong for its earlier inputs. Preserve both versions, their labels and the reason supplied for the revision. Where the reason is unknown, leave it unknown. This gives a future reader enough information to compare the calculations without inventing a cause for the change or assuming that the latest table has independent verification.
Frequently asked questions
Does a matching inner dimension prove that the product is meaningful?
It proves only that the ordinary two-dimensional shape contract permits the stated product. Labels, units and purpose still need examination. In Case C, positional multiplication is dimensionally possible but differs from the explicitly label-aligned calculation. Actual identity and alignment require source evidence beyond equal counts or similar names.
Why show one output cell before the entire result?
One complete cell expression makes the pairing and summation rule inspectable. It can distinguish row-by-column multiplication from corresponding-cell multiplication even when both produce the same shape. The expression remains a finite arithmetic check; it does not certify every other cell or justify an unsupported interpretation of the result.
Can I reverse the two arrays if both orders fit?
Compute either declared expression when the task requires it, but preserve its operand order and axis roles. Case B shows that both orders can fit and produce different values. Choosing which expression answers an actual question requires its intended relationship, rather than a preference for one output's appearance.
Should I transpose a table to repair incompatible dimensions?
First establish what its rows and columns represent. A transpose can make the example calculable while changing the axis relationship. Show the before-and-after labels and obtain the intended orientation from the source. Shape compatibility after a proposed edit does not independently establish that the edit preserves the task.
Can an unknown entry be treated as zero for a draft explanation?
Only present that as an explicit hypothetical completion unless the source confirms zero or the task declares an imputation rule. Keep the original unknown visible. Case F's zero and two completions produce different results, and neither supplies evidence about which value actually belongs in the missing field.
Do these examples demonstrate an AI model's mathematical accuracy?
No. They are authored inputs with narrow local arithmetic and label checks. No model response, NumPy execution or production result was evaluated. The examples help formulate and inspect a bounded explanation request; an actual evaluation needs its own cases, outputs, criteria and documented limits.
Original fictional practice data
Original fictional teaching cases, not actual client records, reservations, model outputs, professional review or operating approval. No executable utility is supplied.
| case | supplied |
|---|---|
| A | {"case": "A", "left": [[1, 2, 0], [0, 1, 3]], "right": [[2, 1], [4, 0], [1, 5]], "expected": [[10, 1], [7, 15]]} |
| B | {"case": "B", "left": [[1, 2], [0, 1]], "right": [[2, 0], [3, 1]], "expected": [[8, 2], [3, 1]], "reverse": [[2, 4], [3, 7]], "cellwise": [[2, 0], [0, 1]]} |
| C | {"case": "C", "left": [[1, 2, 0], [0, 1, 3]], "incomingLabels": ["EX-C", "EX-A", "EX-B"], "desiredLabels": ["EX-A", "EX-B", "EX-C"], "right": [[1, 5], [2, 1], [4, 0]], "positional": [[5, 7], [14, 1]], "aligned": [[10, 1], [7, 15]]} |
| D | {"case": "D", "left": [[1, 2, 0], [0, 1, 3]], "right": [[2, 4, 1], [1, 0, 5]], "inner": [3, 2], "transposeProduct": [[10, 1], [7, 15]]} |
| E | {"case": "E", "counts": [1, 2, 0], "rates": [[2, 1], [4, 0], [1, 5]], "quantities": [10, 1], "units": ["amber credits", "blue credits"], "combinedRule": null} |
| F | {"case": "F", "known": [1, 2, null], "rates": [[2, 1], [4, 0], [1, 5]], "subtotal": [10, 1], "ifZero": [10, 1], "ifTwo": [12, 11], "full": "unresolved"} |
Primary sources and editorial scope
AI-assisted website editorial. Sources read October 29, 2026 America/New_York. Original fictional teaching inputs and planning records only; no actual ticket, reservation, visit, inquiry, artwork/material observation, experiment, route inspection, individual access assessment, professional review or institutional endorsement. Original examples checked independently. No record change, actual client dataset, observed model output, professional review, security certification or operating approval is asserted.