Research Journal

One Declaration, Two Readers

Structured data is a declaration: this is who we are, this is where, this is what we sell. The framework says to make it plainly and let the algorithm read it. What the framework has not said clearly enough until now is that a declaration has a recipient, and the recipient decides whether any of it matters.

Northern Cyprus, where the case study ran, is Google country. A Google Business Profile there is not a marketing extra. Keep the hours, the address and the menu current and the listing does real work, because that is the database the local audience is actually querying.

The figures show it from the side. Over sixteen months the restaurant site took 377 impressions and 16 clicks on iskele yemek, Turkish for food in Iskele. A click-through rate near four per cent on a query that generic looks poor until you remember what that result page looks like: a map and a row of business cards, with the blue links below them. The profile was answering a good share of those searches directly. The site and the listing were the same declaration, filed in two places, and the listing got read first.

Now move the same discipline to Russia and it stops paying. The markup is no worse, the profile is no better maintained, and the audience is asking Yandex, which keeps its own directory. Same declaration, different reader, no result. We hit the infrastructure version of this while building a listing site for the same region: it is hosted on Cloudflare, Cloudflare is unreliable from Russia, and the analytics that works everywhere else simply cannot see a Russian-speaking visitor.

Put it plainly: the method is not a spell. A clear, honest, machine-readable statement of fact still has to be filed where the reader looks. Before asking how to say it, ask which algorithm the audience is actually addressing. That question belongs in the method, not in a footnote, and it is also the answer to anyone who reads a case study from one market and copies the tactics into another.

Naive Parsing, Human and Machine

A production incident and a content review landed in the same week, and they turned out to be the same bug wearing different clothes.

The incident: a price-sync worker split a CSV on commas. Product names contained commas of their own ("Kani Maki, 8 pcs"), the columns drifted, and roughly fifty items silently got the wrong price for hours before anyone noticed. The parser wasn't careless — it applied a rule (comma = delimiter) that happened to be wrong for this data, and it failed exactly as confidently as it would have if the rule had been right.

The review: a collaborator flagged a stylistically ordinary em dash as "an AI tell." Same shape of error — a rule (dash length signals authorship) applied with total confidence to data it doesn't actually predict. The mark itself didn't change; people just stopped reaching for a key that takes one extra step, and mistook their own shortcut for a rule about machines.

What's worth sitting with is the asymmetry. An API call with a wrong parameter fails loudly and immediately — a curl request either works or it doesn't, and nobody expects it to guess your intent. Human language gets no such courtesy. Use the wrong word, or the "wrong" punctuation mark, and people don't fail loudly; they quietly construct a confident wrong meaning and act on it, then treat you as the one who communicated poorly. We ask software to reject bad syntax outright and ask human listeners to be flawlessly telepathic about a mark as small as a dash — backwards, but it's the actual bar people hold each other to.

The Expert's Vocabulary Problem

Spent a month building content for a client who is, herself, an experienced marketer — reasonably assuming that her own vocabulary would transfer directly to content for her audience. It didn't. Terms like "offer" or "audit" are fluent inside a marketing circle and opaque outside it; her own readers flagged them as foreign on contact.

The cost of that mismatch wasn't abstract. Close to six people on our side touched this project across the month — research, drafting, review — on top of the client's own budget for it. A wrong vocabulary collected at the very start doesn't stay a small problem; it compounds through every hour spent building on top of it before anyone notices the foundation was off.

The useful lesson isn't about that one client. It's that semantic authenticity is never inherited from the source's expertise — it has to be verified against the receiver, every time, even when the source is fluent, confident, and correct within her own professional register. A word doesn't carry its meaning intact just because the person using it understands it perfectly.

A smaller footnote from the same review: a collaborator flagged an em dash in the copy as "an AI tell" and asked for it removed. The mark predates any language model by a couple of centuries; what actually changed is typing friction, not authorship. Surface heuristics like this one propagate faster than the linguistics behind them do — worth tracking as its own small case of algorithmic folklore, sitting right next to the marketing-jargon problem above: both are pattern-matching mistaken for understanding.