How do you manage a category network covering 300,000 books?

A category system looks simple while the catalog is small. A few labels are created, content is placed where it seems to fit, and the structure appears to work. At scale, the problem changes. The question is no longer only "where does this book belong?" It becomes "can the same classification logic be applied consistently hundreds of thousands of times?"

At Ekip Dağıtım, the system we worked on covered 300,000 books. The operation lasted roughly 12 months and involved a 17-person team, co-organized and managed by Ahmet and Seçil.

At scale, the real product is not the category tree itself. It is the decision system that can reproduce the same classification logic across hundreds of thousands of records.

Why the problem changes with scale

Intuition can be enough for ten items. With thousands of records, parallel labels, ambiguous parent-child relationships and inconsistent interpretation start producing systemic errors.

I think about the information architecture as five connected layers:

The operating flow was therefore not just a tree. It was Input → Category network → Team review → Quality control → Delivery.

1. Design decision boundaries before labels

A category name is only a label if the underlying decision is unclear. For every meaningful node, the team needs to understand what it includes, what it excludes, how it differs from its parent and neighbors, and what happens when an item appears to fit several places.

1const taxonomyNode = {2  label: '...',3  includes: ['...'],4  excludes: ['...'],5  parent: '...',6  ambiguityRule: '...',7};

This is a mental model, not the literal production schema. The important idea is that a taxonomy node needs decision behavior, not only a name.

2. Look for repeated decisions before adding nodes

One of the most expensive failure modes in a large catalog is unnecessary category growth. If two people solve the same distinction with different labels, the tree grows without becoming more expressive.

A new category should therefore answer a stronger question than "does this label sound reasonable?" The useful question is: can the existing model express this distinction clearly?

This is similar to introducing a new abstraction in software architecture. Every new need should not automatically create another layer.

Taxonomy quality is not measured by how many categories exist, but by how clearly the necessary distinctions can be expressed with minimal ambiguity.

3. Documentation becomes part of the product

A 17-person operation cannot remain consistent through verbal guidance alone. If part of the information architecture exists in the tree and another part exists only in individual memory, the system will drift.

Useful decision documentation should be short and answer five things:

• What is the decision?
• Why does this rule exist?
• What is a clear positive example?
• What similar example should be excluded?
• Where does ambiguity escalate?

The principle is the same one I now use with AI coding agents: speed amplifies inconsistency when there is no shared source of truth.

4. Quality control cannot be only a final gate

Reviewing hundreds of thousands of records only at the end is too late. A misunderstood rule can be repeated across many records before anyone notices.

1Input2  ↓3Classification4  ↓5Team review6  ↓7Quality control8  ↺ update the rule when needed9  ↓10Delivery

The feedback arrow matters. When the same error repeats, correcting individual records is not enough. The classification rule itself may need to change.

5. Treat repeated mistakes as system signals

When the same mistake appears across several people, I do not start with "who made the error?" I look at whether the rule is ambiguous, the examples are weak or the review stage detects the problem too late.

Human attention matters, but quality does not scale if the entire model depends on exceptionally careful individuals.

6. Taxonomy affects more than navigation

Even when the category tree is not directly visible, it influences search, filtering, discovery, reporting, content operations and downstream data systems. Poor information architecture leaks into each of those surfaces as a separate problem.

If the same concept is represented inconsistently:

• users struggle to find the right result,
• filters multiply without meaning,
• operators classify similar items differently,
• reporting fragments,
• downstream systems inherit dirty source data.

Information architecture is therefore not post-design content cleanup. It is the layer between data, operational decisions and user understanding.

7. What the 300,000-book scale taught me

The strongest lesson was that there is no useful concept of a "correct category" in isolation. A correct classification is the result of clear definitions, shared decision rules, consistent application and a functioning quality loop.

If I started a large information-architecture project today, I would still use this sequence:

1. Map input types and ambiguity. 2. Define decision boundaries before category labels. 3. Set an explicit threshold for creating new nodes. 4. Keep rules in one shared, concise source. 5. Place review and quality control inside the workflow. 6. Treat recurring errors as system problems. 7. Define completion as more than processed records: the system should remain explainable and maintainable.

1const taxonomyReady =2  clearBoundaries &&3  sharedDecisionRules &&4  reviewLoop &&5  qualityControl &&6  explainableOwnership;

Where information architecture meets systems architecture

I still use the same reasoning today when designing product modules, data boundaries or AI-agent workflows:

• Where does this concept begin and end?
• What is the source of truth?
• Is the same idea being recreated in several places?
• How is ambiguity resolved?
• Does quality depend on memory or on the system?

Information architecture taught me that organizing complexity is not about putting things into boxes. It is about making decisions repeatable without making them contradictory.

That is why I treat product, information and systems architecture as three scales of the same problem: turning complexity into a structure that can be understood, owned and operated.