Tags and discovery

Tags are set on the Publish step. They drive search ranking, the related-content rail, and the public tag pages.

The three layers

Discovery runs on a three-level taxonomy.

Broad categoryfour, fixed

Technical, Data & AI, Product & Design, and Game Design.

Sub-interest32, curated

Six to eleven per broad category, and the level a reader chooses between. Grows slowly and additively.

Tagfreeform

What you attach to a blueprint. Tags map upward into sub-interests.

Broad category	Covers
Technical	Architecture, cloud, networking, security, DevOps, APIs, embedded, hardware, robotics
Data & AI	Pipelines, analytics, ML systems, generative AI, agents, MLOps, data modelling
Product & Design	User flows, IA, wireframes, service blueprints, product strategy, UX research, design systems
Game Design	Mechanics, level design, branching narrative, economies, AI behaviour, multiplayer

A reader picks broad categories and sub-interests, and your tags are matched against them. The match fills a signed-in reader's dashboard, reaching people who never searched for the blueprint.

Suggestions

At publish time a classifier proposes tags from your content, using embeddings and a language model, each with a confidence score. You accept the right ones and delete the rest.

Every attachment records how it got there:

Provenance	Means
`manual`	You typed or picked it. No confidence score
`llm-accepted`	Proposed by the classifier, accepted by you
`llm-suggested`	Proposed, not yet confirmed. A review candidate rather than a live tag

An unaccepted suggestion is not attached.

A wrong tag is worse than a missing one. It puts your blueprint in front of people looking for something else, who bounce, lowering its ranking for the people who did want it. Delete a plausible but wrong suggestion before adding more right ones.

Checking what stuck

list_blueprint_tags on the MCP server returns each tag with its slug, label, provenance and taxonomy placement.

set_blueprint_tags replaces the whole set, so read before you write.