Your Supermarket Barcode Usually Does Not Contain the Price

You pick up a box of cereal. A cashier passes it over the scanner. Beep. The correct product appears on the screen with a price. It feels obvious that the scanner has "read the price" from the barcode. Usually, that is not what happened. The barcode did something more modest — and far more powerful. It identified something so another system could decide what information belonged to it.

Beep.

€3.49.

It happens so quickly that the mechanism disappears.

Barcode.

Scanner.

Price.

Our brain connects them:

barcode → price

But there is a missing step.

And that missing step explains an enormous part of the digital world.

A Barcode Is Often An Identifier

Look at a retail barcode.

The bars encode a number.

That number identifies an item within a particular identification system.

The scanner reads the symbol.

Software interprets the number.

Then another system can use that identifier to find information associated with the product.

Identifier ≠ Complete Record

The barcode does not need to carry everything we know about the cereal.

It needs to help the system know which cereal we are talking about.

Think About What A Store Knows

For one product, a retailer may store information such as:

product name;

current price;

tax category;

inventory status;

promotion;

supplier;

department;

description;

perhaps many other fields.

Would all of that need to be printed into every barcode?

No.

Identification Can Be Separated From Description

That separation is one of the great ideas of information systems.

The Barcode Can Stay The Same While The Price Changes

Today:

€3.49.

Next week:

€3.79.

During a promotion:

€2.99.

The physical package may still carry the same product identifier.

Same Identifier + Changed Database Record → Changed Checkout Result

That immediately tells us something important.

If the price can change while the barcode remains unchanged, the price cannot simply be identical to the barcode.

This Is Why A Sale Does Not Require Reprinting Every Package

Imagine a supermarket with 30,000 products.

Friday promotion:

10% off selected items.

If price lived permanently inside every printed product barcode, changing prices would become a packaging problem.

Instead, price can be maintained elsewhere.

Separate Stable Identity From Changeable Information

Now the system becomes flexible.

This Is Database Thinking

We can model it simply:

physical product

↓

barcode symbol

↓

encoded identifier

↓

scanner

↓

software

↓

database lookup

↓

product record

↓

current price

↓

checkout decision

The scanner does not need to understand breakfast cereal.

It needs to capture the identifier reliably.

This Is More Interesting Than It Looks

Because humans constantly confuse:

the thing;

the label;

the identifier;

the information attached to the identifier.

Representation ≠ Object

And:

Identifier ≠ Meaning

An identifier points.

It does not necessarily explain.

Your Name Works Differently

"Anna" carries human linguistic meaning.

But it is a terrible unique identifier.

There may be millions of Annas.

Human-Readable ≠ Unique

Information systems often need identifiers that prioritize reliable distinction over natural-language elegance.

This Is Why Databases Love IDs

Customer ID.

Order ID.

Invoice number.

Student ID.

Tracking number.

Ticket number.

Product code.

Names Describe. IDs Distinguish.

Sometimes one value can do both partially.

But the functions are different.

Imagine Two Customers Named John Smith

A company has:

John Smith, London.

John Smith, Toronto.

If software identifies customers only by name, trouble begins.

Same Label ≠ Same Entity

The database needs a more reliable way to distinguish records.

Now Reverse The Problem

One person changes their surname.

Did the person become a different person?

No.

Changed Label ≠ Changed Entity

This distinction is fundamental.

Information Systems Need Stable References

Suppose every internal relationship depended on the customer's displayed name.

Change the name.

Now invoices?

Orders?

Support history?

Subscriptions?

Everything becomes harder to connect.

A stable internal identifier allows the display information to change without destroying the relationships.

Identity Architecture Reduces Coupling

That sounds technical.

But you encounter it every day.

A Library Works The Same Way

A book has:

title;

author;

edition;

publisher;

language;

year;

identifiers;

shelf location;

catalogue record.

The title is not the whole book.

The shelf number is not the book.

The catalogue record is not the physical object.

One Entity → Multiple Representations

Each representation serves a different task.

This Is Why "The Same Book" Can Be A Difficult Question

Same title?

Same text?

Same edition?

Same translation?

Same ISBN?

Same physical copy?

"Same" Requires A Criterion

Databases force us to make that criterion explicit.

Language Often Lets Us Avoid This

Someone says:

I bought the same book as Maria.

Do they mean the exact physical object?

Usually not.

They probably mean another copy of the same work or edition.

Everyday Language Tolerates Flexible Identity

Databases cannot always afford that flexibility.

This Is Where Computer Science Meets Philosophy

What makes two things the same?

What makes them different?

Which differences matter for this task?

Identity Depends On The Question

A supermarket and a museum may model the same object differently.

Consider A Bottle Of Water

For supermarket inventory:

one unit of a particular product.

For manufacturing:

a batch, production time and line may matter.

For logistics:

carton, pallet and shipment may matter.

For quality control:

lot or batch may become critical.

Same Physical Object → Different Relevant Identities

The system chooses what distinctions it needs.

This Is Data Modeling

Before building a database, somebody must decide:

What entities exist?

Which properties belong to them?

How are they related?

What makes one record distinct from another?

Database Design Begins Before The Database

It begins with conceptual decisions.

Bad Models Create Strange Problems

Imagine a school database where the student's name is used as the permanent identifier.

Then two students have the same name.

Problem.

A student changes their name.

Problem.

Someone enters the name differently.

Problem.

Convenient Label ≠ Reliable Key

The mistake happened before any software bug.

It happened in the model.

This Is Why Programming Is Not Only Coding

A programmer can write syntactically perfect code around a bad conceptual model.

The software will faithfully execute the bad model.

Correct Code ≠ Correct Architecture

That distinction matters enormously in IT education.

Now Return To The Supermarket

You scan the cereal.

The system retrieves a record.

But what if the database contains the wrong price?

The barcode was read perfectly.

The scanner worked perfectly.

The result can still be wrong.

Correct Identification ≠ Correct Associated Data

Another important distinction.

This Gives Us A Diagnostic Chain

Wrong checkout price.

Where is the failure?

Barcode damaged?

Scanner misread?

Wrong product identifier?

Wrong database record?

Promotion not applied?

Synchronization problem?

Incorrect shelf label?

Human data-entry error?

Same Symptom → Multiple Failure Points

"Barcode problem" is not yet a diagnosis.

The Shelf Label Adds Another Layer

The customer sees:

€2.99.

Checkout shows:

€3.49.

Now there are two representations of price.

Which one reflects the intended current price?

That becomes an operational and sometimes legal question depending on jurisdiction and circumstances.

Conflicting Displays Reveal Hidden Architecture

The disagreement tells us that information exists in multiple places.

Duplication Creates Synchronization Problems

Suppose the price is stored independently in:

checkout database;

website;

mobile app;

printed shelf label;

advertisement.

Change one.

Forget another.

Now the system disagrees with itself.

More Copies → More Synchronization Responsibility

Information architecture matters.

This Is Why "Single Source Of Truth" Is Such A Powerful Idea

Where should authoritative information live?

Which other systems should derive from it?

Who can update it?

How quickly do changes propagate?

Information Needs Governance

Not merely storage.

Schools Have The Same Problem

Teacher availability appears:

on a website;

in an administrator's notes;

in a calendar;

in a message thread;

in someone's memory.

One changes.

Others do not.

Data Exists ≠ Data Is Current

Operational reliability requires deciding which source is authoritative.

Language Learning Has A Similar Trap

A student writes:

English level: B2.

What exactly does that identifier tell us?

Something useful.

But not everything.

Level Label ≠ Complete Competence Profile

Two B2 learners can differ dramatically.

One May Be Strong In Reading

Another in speaking.

One may understand grammar well.

Another may communicate fluently despite gaps.

One may handle everyday English.

Another may know professional terminology.

Same Category ≠ Same Internal Structure

The label helps locate.

It does not fully describe.

This Is The Barcode Problem In Education

We see a compact label.

We begin treating it as if it contains the entire record.

B1.

B2.

C1.

Beginner.

Advanced.

Gifted.

Weak.

Motivated.

Classification ≠ Person

A label can help a system operate.

It can also hide variation.

Grades Work The Same Way

85%.

A.

7/10.

These are compressed outputs.

But what produced the score?

Conceptual understanding?

Memory?

Calculation errors?

Time pressure?

Misreading instructions?

Language difficulty?

Score ≠ Mechanism

The number identifies an outcome.

It does not automatically diagnose its cause.

This Is Why Assessment Needs Depth

Suppose two students score 60%.

Student A misunderstands one central concept.

Student B understands everything but makes several arithmetic mistakes.

Same score.

Different intervention.

Same Result ≠ Same Learning Need

The database value is useful.

The teacher still needs a model.

Now Think About Vocabulary

A student recognizes the word:

bearing.

Do they know it?

Maybe.

Bearing can relate to:

direction;

mechanical components;

support;

manner;

relevance;

tolerance;

and other contexts.

Word Form ≠ One Stored Meaning

Language itself behaves like a lookup problem — but a much richer one.

Context Selects The Record

ball bearing

bearing north

bearing the load

bearing on the question

The visible word remains similar.

The conceptual destination changes.

Same String ≠ Same Meaning

This is why translation cannot simply replace strings.

A Dictionary Is Not A Word-Replacement Table

You look up a word.

Several entries appear.

The dictionary does not know automatically which one your sentence requires.

Lookup ≠ Decision

The user must interpret context.

Machine Translation Faces The Same Challenge

Input string.

Possible meanings.

Context.

Domain.

Syntax.

Pragmatics.

Target-language possibilities.

Matching Form ≠ Recovering Meaning

The system needs more than a bilingual list.

Technical Translation Makes This Obvious

Consider:

current

Electrical current?

Current price?

Current version?

Ocean current?

Current events?

Familiar Word → Multiple Domain Records

The correct interpretation depends on the conceptual system around it.

This Is Why Domain Knowledge Matters

A translator working with engineering, law, medicine, logistics or finance does not merely need more vocabulary.

They need to understand which conceptual record the language is pointing toward.

Term Recognition ≠ Domain Interpretation

Again:

identifier versus information.

URLs Work Like This Too

A web address identifies a resource location.

The visible anchor text may say:

Learn German

But the link itself points somewhere specific.

Link Text ≠ Destination

That is why broken or outdated URLs matter.

The label may look perfect.

The route may fail.

Search Engines Face The Reverse Problem

A person types words.

The system must infer which resources those words might refer to.

Query ≠ Exact Intent

"Python course"

could mean:

programming;

a course about snakes;

a particular school;

beginner instruction;

professional automation;

data science.

Context narrows the interpretation.

Human Conversation Does This Constantly

Someone says:

Put it there.

What is it?

Where is there?

The sentence alone may be nearly useless.

But shared context makes it effortless.

Language Uses References Everywhere

Pronouns are tiny pointers.

"She" Does Not Contain A Person

It refers to someone recoverable from context.

Pronoun ≠ Person

That sounds obvious.

But structurally it resembles the barcode.

A compact signal points beyond itself.

This Is Deixis And Reference

I.

You.

Here.

There.

Now.

Tomorrow.

Their interpretation depends on who speaks, where and when.

Meaning Can Depend On Coordinates Outside The Word

Language is not self-contained.

"Tomorrow" Has No Permanent Date

Say it Monday.

It points to Tuesday.

Say it Friday.

It points to Saturday.

Same Word + Different Context → Different Referent

The string remains stable.

The lookup changes.

This Is Why Context Is Not Decoration

Context can determine what the expression refers to.

Without it, the identifier may be unresolved.

Context Completes Reference

That principle connects linguistics and information systems surprisingly well.

But Human Language Is More Flexible Than A Barcode

If a barcode is damaged beyond recoverability, the scanner may fail.

Humans can often reconstruct incomplete language.

Pass me the… uh… the thing for opening bottles.

You may still understand.

Human Reference Can Survive Imperfection

Shared models compensate.

This Is Why Communication Is More Than Encoding

Speaker creates an expression.

Listener reconstructs a referent and intention.

Words Point. Minds Reconstruct.

That is a richer architecture than word replacement.

Now Consider Names

A student learns:

London.

Does knowing the label mean knowing the city?

Obviously not.

Name Recognition ≠ Knowledge Of The Thing

Yet education often rewards recognition as if it were understanding.

Geography Can Become A Barcode Exercise

Capital?

River?

Mountain?

Country?

Recognize label.

Return label.

Correct Lookup ≠ Geographic Understanding

Where is the mechanism?

Climate?

Trade?

Population?

Transport?

History?

Terrain?

Relationships?

Biology Can Become The Same

Mitochondria.

Photosynthesis.

DNA.

Osmosis.

Students recognize terms.

Terminology Recognition ≠ Biological Model

The label is only an entry point.

Physics Too

Momentum.

Voltage.

Acceleration.

Entropy.

Students can repeat definitions while lacking an operational model.

Definition Retrieval ≠ Conceptual Understanding

A word can identify the concept without containing the concept.

This Is The Deep Lesson Of The Barcode

A compact representation can be extremely useful precisely because it does not contain everything.

It points into a larger system.

Compression Requires External Structure

Without the larger structure, the code loses much of its usefulness.

A Formula Works Similarly

F = ma

Three symbols.

Tiny representation.

Enormous conceptual system behind it.

Formula ≠ Physics

The formula points toward relationships that must be understood.

A Map Symbol Does The Same

Blue line.

River.

But the symbol is not wet.

It does not flow.

It has no depth.

Representation Selects Features

Useful representations deliberately omit reality.

This Is Why More Detail Is Not Always Better

A barcode succeeds because it is limited.

It does not try to print the entire product database in black lines.

Good Representation Knows What To Leave Elsewhere

That is information architecture.

Education Needs The Same Discipline

What should the student memorize?

What should they understand?

What can they look up?

What must they retrieve quickly?

What requires judgment?

Knowledge Architecture Matters

Not every piece of information needs the same cognitive treatment.

Suppose A Student Can Look Up A Formula

Fine.

But can they decide:

which formula applies?

what the variables mean?

whether the units make sense?

whether the answer is physically plausible?

Access To Information ≠ Ability To Use Information

The database can store.

The human still has to decide.

AI Makes This Distinction More Important

AI can retrieve, generate and reorganize enormous amounts of information.

So the educational question shifts.

Not simply:

Can you produce information?

But:

Can you evaluate what the output refers to?

Can you detect the wrong record?

Can you choose the right model?

Retrieval Power Increases The Value Of Judgment

The scanner gets faster.

Architecture still matters.

At Levitin Language School

At Levitin Language School, this distinction connects naturally with Languages, Academic Subjects, and Language + Subject.

A learner can recognize a term without understanding the concept.

Know a level label without having an even competence profile.

Find a translation without knowing whether it fits the domain.

Retrieve a formula without understanding the physical mechanism.

And Language Learnings extends the same question into practical and professional language: identifying information is useful, but using it correctly requires context, domain knowledge and decisions.

The Commercial Question Changes Too

People search:

B2 English tutor

business English course

math tutor

technical translation

German lessons

Those labels are useful identifiers.

But what problem actually sits behind them?

Search Category ≠ Complete Need

"Business English" may mean meetings.

Presentations.

Logistics.

Email.

Negotiation.

Technical vocabulary.

Job interviews.

International sales.

The Label Helps Us Find The Shelf

It does not tell us everything inside the box.

That is exactly what the barcode teaches.

Classification Helps Navigation

Diagnosis determines intervention.

The Tymur Levitin Question

When a number, label, code, score, level, term or category seems to tell you what something is, ask:

Is this representation actually describing the thing, merely identifying it, classifying it for a particular purpose, or pointing me toward information stored somewhere else — and what important structure disappears if I mistake the label for the reality?

That question begins at a supermarket checkout.

It belongs to databases, programming, linguistics, translation, assessment, mathematics, science and education.

Full Architecture

physical product

↓

printed barcode

↓

encoded identifier

↓

scanner

↓

software

↓

lookup

↓

database record

↓

current information

↓

checkout result

But the deeper architecture is:

reality

↓

representation

↓

identifier / label / category

↓

external system

↓

stored relationships

↓

contextual interpretation

↓

decision

And the distinctions matter:

barcode

≠ price automatically

identifier

≠ complete record

identification

≠ description

same identifier

≠ same associated information forever

name

≠ unique identity

same label

≠ same entity

changed label

≠ changed entity

catalogue record

≠ physical object

same

≠ one universal relationship

convenient label

≠ reliable key

correct code

≠ correct architecture

correct identification

≠ correct associated data

data exists

≠ data is current

level label

≠ complete competence profile

classification

≠ person

score

≠ mechanism

same result

≠ same learning need

word form

≠ one meaning

lookup

≠ decision

term recognition

≠ domain interpretation

link text

≠ destination

query

≠ exact intent

pronoun

≠ person

name recognition

≠ knowledge of the thing

terminology recognition

≠ conceptual model

formula

≠ mechanism

representation

≠ reality

access to information

≠ ability to use information

search category

≠ complete need

The scanner beeps.

The price appears.

The whole process takes less than a second.

That speed hides the architecture.

The black lines did not need to contain the supermarket.

They needed to provide a reliable route into a larger information system.

That is why the barcode is such a useful intellectual object.

It teaches us that a label can be useful without being complete.

A number can identify without explaining.

A category can organize without describing the whole person.

A word can point toward a concept without containing the concept.

A formula can compress a relationship without teaching the mechanism.

And a level like B2 can help us locate a learner without telling us what that learner actually needs next.

Sometimes the mistake is not that the label is wrong.

The mistake is asking the label to tell us more than it was designed to know.

© 2026 Tymur Levitin. All rights reserved. Tymur Levitin Founder & Director, Levitin Language School Language educator, teacher & researcher Levitin Language School Language Learnings tymurlevitin@levitintymur.com