Capitalization is usually presentation until a system treats it as identity

A mixed-case column can look untidy. That often prompts a quick instruction: make everything uppercase, lowercase, or Proper Case.

Sometimes that is harmless formatting. Sometimes it quietly changes a business rule.

The real question is not whether Acme, ACME, and acme look more consistent after cleanup. It is whether the relevant system considers them the same thing. If it does, capitalization may be presentation. If it does not, changing case can merge records, break a lookup, or make an export impossible to reconcile.

That distinction should be documented field by field, rather than settled by a blanket cleanup rule.

One value can have four valid forms

A useful data policy separates four jobs that are often mistakenly assigned to one column:

• Source value: the incoming text, retained as received.
• Display value: a version formatted for people.
• Comparison value: a separate value used for an approved matching or search rule.
• System key: an identifier whose exact characters must be preserved for another system.

A brand name may reasonably have a display format and a case-insensitive comparison value. An external file key may not. The mistake is overwriting the source value because a matching task needs a normalized copy.

A better pattern is to retain customer_name and, where appropriate, add a clearly named field such as customer_name_match_key. That name tells the next analyst that the field has a specific purpose. It also avoids presenting a matching rule as though it were the original fact.

When case is part of identity

Amazon S3 offers a concrete example. Object keys uniquely identify objects within a bucket, and object key names are case-sensitive. a.txt and A.txt can therefore exist as separate objects.

The lowercase version might be useful for a search index. It cannot safely replace the object key. AWS also documents conflicts that can arise when objects differing only by case are downloaded to a case-insensitive local filesystem.

The lesson extends beyond file storage. If changing xYz to XYZ would make a later lookup, export, or retrieval ambiguous, case is part of identity for that use.

Email addresses call for similar restraint. The formal SMTP standard requires the local part before @ to be preserved and treated as case-sensitive. Real-world provider behavior is not uniform, which makes blanket uppercasing or lowercasing a poor preservation strategy. Keep the source value, then establish a separately documented rule if a business process needs matching.

Equality can change as data moves

Case behavior is not guaranteed to stay consistent across a data stack.

Microsoft documents that Power Query M is case-sensitive, distinguishing Foo, foo, and FOO. In the documented Power BI Desktop loading behavior, different capitalizations are normalized as the same value. An analyst who sees three categories during preparation may encounter different grouping or distinct-value behavior after loading.

Databases make the same point in a different way. In SQL Server, collation settings can be case-insensitive (CI) or case-sensitive (CS), governing how character data compares and sorts. Other platforms also allow collation choices at the column or expression level.

So “the database treats these as equal” is incomplete. Which database, which column, which collation, and which stage of the pipeline? Those details determine whether case is cosmetic or consequential.

Unicode adds another reason to avoid casual transformations. Uppercasing and lowercasing are not universal, reversible comparison algorithms. Case mapping can depend on locale. Turkish dotted and dotless letter forms are a familiar example, and some mappings can expand from one character to multiple characters. Unicode advises using case-folded text for internal processing rather than storing or displaying it as user-facing text.

Ask four questions before changing case

Before applying a case transformation, a business team should answer four questions:

1. Is this field a human label, a lookup term, or a system-issued identifier? 2. What does the authoritative source say about comparison? 3. Could two existing values collide after the proposed transformation? 4. Will the original value remain available for audit, export, correction, and troubleshooting?

The third question deserves a small control before deployment. Create the proposed comparison value, group records by it, and count the distinct original values in each group. Review every group containing more than one original spelling.

A collision is not automatically a duplicate or an error. Acme and ACME may be intentional distinctions, or they may be alternate presentations of the same organization. Either way, the collision proves that normalization removes a distinction. Someone who owns the business rule should decide whether that is acceptable.

The practical policy is straightforward: preserve the source value; format a copy for display; normalize a separate copy for an approved comparison rule; and never case-convert opaque or system-defined identifiers unless the system owner documents that it is safe.

Clean-looking data has value. But a consistent appearance is not the same as a consistent meaning.