AI
aiLLMs, ML, agents, prompt design, model APIs, inference, training.
A learning library for builders, structured around two primary experiences - structured learning and knowledge discovery. The platform architecture is intentionally simple.
Topics are none of those - they're labels that help users find content across the library.
A structured sequence of Articles - a roadmap through a subject, from first principles to production.
A standalone piece of knowledge - the core content unit of StackNova.
A curated traversal across Articles - tells you where to start and in what order. Can span Paths.
A label for discovery and filtering. Not a content type - never a container.
A Path is a curated learning journey: a roadmap through a subject, from first principles to production. Paths primarily organize Articles into a deliberate learning sequence.
aiLLMs, ML, agents, prompt design, model APIs, inference, training.
cloudCloud platforms, infrastructure, deployment, edge, networking.
dataDatabases, pipelines, warehouses, analytics, streaming, data modeling.
designUX/UI, design systems, wireframing, Figma.
engineeringLanguages, runtimes, testing, architecture, performance, tooling.
webFrontend frameworks, build tooling, browser platform, web standards.
Adding a new Path is a product decision, not a content-authoring one. If an Article doesn't obviously fit one of these six, sharpen its angle rather than invent a Path.
An Article is the core content unit of StackNova - a standalone piece of knowledge. Articles can take many forms; they live inside Paths but each one stands on its own.
Architecture writeup
answers "how is THIS system built?"
One named system taken apart: its components, how they connect, the design tradeoffs behind the structure.
ExampleInside Aspire's AppHost: how it orchestrates resources.
Case study
answers "what happened when I did this?"
A narrative of one real instance - past tense, first person.
ExampleClaude Code is a Magician.
Comparison
answers "X or Y?"
The two side by side, on the axes that actually decide between them.
ExamplesCopilot vs Claude Code; esbuild vs Vite.
Explanation
answers "how does X work?" in general
Builds a mental model of a concept; no task to complete.
ExamplesWhat is TypeScript; What is Docker; What is NoSQL; The event loop in JavaScript.
How-to
answers "how do I do this?"
Reproducible steps to complete one specific task - imperative, second person.
ExamplesHow to add Azure SQL Database to an Aspire app; How to add Redis caching to an Aspire app.
Every Article carries a level marker shown in its eyebrow chip. The level is the article's contract with the reader - depth, prior-knowledge assumptions, and tone all derive from it.
Readers who are new to the topic and want a working mental model.
Readers who have built something in this area and want real-world tradeoffs.
Readers who are comfortable with the platform and want edge cases, performance, debugging.
Readers who know the domain deeply and want internals, scalability, failure modes.
A Map is a curated index - a page that tells you where to read, in what order, and why. Maps don't carry new knowledge; they organize existing Articles into a useful traversal. They can pull Articles from more than one Path into one organized view.
Cross-cutting by design. A Map can pull Articles from multiple Paths into one organized view. The Web stack Map lives under the Web Path conceptually but pulls in API doc Articles from Engineering. That is the point.
| Article | Map | |
|---|---|---|
| Owns | New knowledge or explanation | A path through other content |
| Reader task | “Teach me X” | “Tell me what to read about X” |
| Cuts across | Lives inside one Path | Can span Paths |
| Update frequency | Stable | Living document - updates as the library grows |
Maps are discovered through the home page (featured), the Maps index, the footer Maps column, and inline cross-links from individual Articles.
Presentation order. Whenever Maps are listed as a set - the home featured grid, the Maps index page, the footer Maps column - sort them A-Z by display name. The only exception is each Map's own Related cards section, which is ordered by editorial relevance, not alphabetically.
Topics are organizational labels - not a content type. Articles belong to Topics; Topics don't own content directly - they surface related Articles across the library. One Article can belong to many Topics.
Topics are deliberately distinct from Path names. A Path is the one home an Article lives in - AI, Cloud, Data, Design, Engineering, Web. A Topic is a cross-cutting label many Articles share across Paths.
A three-level hierarchy creates real problems. "What is Docker" lives in the Cloud Path - but which Topic owns it? Containers, DevOps, or Infrastructure? The answer is all three, which under a three-level hierarchy means either the content gets duplicated or users can't find it.
Where does "Docker" live - under Cloud, DevOps, or Platform Engineering? All three. Forcing one parent means duplicating the content or losing it from the other two.
Topics are labels on Articles, not containers above them. The Article has one home in a Path and any number of Topic labels for discovery.
StackNova favors a flat, flexible knowledge architecture. Each piece has one job, and they compose without overlap.
provide structure
provide knowledge
provide traversal
provide discovery
This keeps the library scalable, searchable, and easy to navigate as the platform grows.