The Case of the Identical Twins: A LeanIX Mystery

Thomas Schreiner

Thomas Schreiner

— 2 min read
Share

Or: How I learned to stop trusting my eyes and love hex editors

I recently discovered an impossible situation in a customer workspace: they had two Applications in their LeanIX workspace with the exact same name.

"That can't be right," I thought. LeanIX enforces unique display names within each Fact Sheet type. It's literally impossible to create duplicates. The system won't let you.

And yet, there they were. Two Applications, both named 1C Enterprise, peacefully coexisting in the inventory like nothing was wrong.

Time to put on my detective hat.

Suspect #1: The Invisible Space

My first instinct? Sneaky whitespace. A trailing space, a leading space, maybe a tab character pretending to be innocent. This is the most common culprit in "identical but not identical" mysteries.

I carefully selected both names, copied them, pasted them into a text editor. Compared character counts.

Verdict: Both strings were exactly the same length. No hidden spaces.

Suspect #2: The Lookalike Letter

Okay, new theory. Maybe someone's playing typography games. A lowercase l that looks like an uppercase I? A zero that's actually the letter O? The classic homoglyph attack?

I squinted at the screen. Zoomed in. Changed fonts.

1C Enterprise
1C Enterprise

Nope. Every letter looked identical. No suspicious characters trying to blend in.

Suspect #3: The Non-Breaking Space

Now I was getting creative. What if one of the spaces wasn't a regular space, but a non-breaking space?   disguised as a normal space, probably copy-pasted from some website?

I checked the hex values of the space characters.

Verdict: Both were honest-to-goodness ASCII spaces. 0x20. Nothing fancy.

The Real Culprit

At this point, I was genuinely puzzled. Same length, same visible characters, no hidden whitespace tricks. There had to be something different.

So I did what any reasonable person would do: I dumped the hex codes of every single character.

And there it was. The C.

One Application was spelled:

31 43 20 45 6E 74 65 72 70 72 69 73 65
1  C     E  n  t  e  r  p  r  i  s  e

The other:

31 D0A1 20 45 6E 74 65 72 70 72 69 73 65
1  С       E  n  t  e  r  p  r  i  s  e

Do you see it? That's not a C (hex 43). That's a С (hex D0A1 in UTF-8) — the Cyrillic letter "Es," which looks exactly like the Latin letter C but is a completely different Unicode character.

The Plot Twist

It all made sense now. 1C Company is a Russian software firm, known for their ERP platform. Someone had entered the company name using the Cyrillic spelling (perfectly natural if you're typing on a Russian keyboard), and someone else entered it using the Latin alphabet.

To human eyes: identical.
To LeanIX's uniqueness check: completely different strings.

Lessons Learned

  1. Unicode is wild. There are hundreds of characters that look identical to ASCII letters but aren't. Cyrillic А, Е, О, С, Р, etc. all have Latin doppelgängers.
  2. Copy-paste is dangerous. When importing data from various sources, you're also importing their character encodings.
  3. When in doubt, check the hex. Your eyes will lie to you. Hex codes never lie.
  4. LeanIX is working as designed. The uniqueness check is based on actual character values, not visual appearance. Which is technically correct — the best kind of correct.

The Fix

For anyone running into this issue: normalize your text inputs. A simple approach is to detect and replace Cyrillic lookalikes with their ASCII equivalents during data import. Or at least flag them for review.

As for my customer, we merged the two Fact Sheets and kept the ASCII version, merging all redundant relations into a consolidated version.

Thanks, LeanIX, for keeping us humble. Just when you think you've seen everything, Unicode shows up with a Cyrillic plot twist.

You keep us learning every day. 🎓

Have you encountered any Unicode gremlins in your Enterprise Architecture data? I'd love to hear your stories. Get in touch!

Read more