Imagine a repair business using artificial intelligence to organize inquiries before staff download a spreadsheet. A customer note is text on the web, but may be treated as a formula after export. Review the whole path, not only the model response.

A harmless example is equals one plus one. As a note, it should remain the original text. As a formula, it can become two. Public security guidance describes this as formula injection. Customer content is not permission to execute spreadsheet logic.

Define each column first. Notes and ticket identifiers are text. Validated labor hours are numbers. Formulas come only from an approved template. Do not ask the model to guess which customer strings can become formulas, or treat quotation marks as a guarantee.

For a staff workbook, consider writing untrusted values explicitly as text cells. For machine exchange, agree on the parser contract. Keep original business values separate from display transformations, so a presentation fix does not damage a ticket identifier.

Use invented data to test opening, saving, closing, reopening, and re-importing. Include leading zeros, negative numbers, commas, quotes, and line breaks. Check both interpretation and data fidelity. Verify the actual tools; behavior is not universal.

Finally, have the business owner confirm column meanings, retain developer test evidence, and let staff review the reading and import workflow. Approve only supported tools and paths. Never ask staff to ignore security warnings or describe unmeasured savings as achieved results.