Content building blocks

A content building block is an independent subject knowledge unit with a stable identity. In the graph, it is an addressable node that can be found, linked, placed in structure, and reused across perspectives. The building block represents one clearly described meaning and receives one defined primary type.

• Concept, Method, Tool, and Technology are the four core subject knowledge types.
• Name, definition, purpose, boundaries, examples, sources, and relationships describe the building block.
• Catalog, Explorer, Overview, Learn, Explain, and other perspectives use the same subject identity.
• The subject identity of the building block remains stable in every presentation context.

The content building block carries reusable subject knowledge. Structure building blocks give it a subject location. Relationships connect it semantically to other nodes. Perspective data adds a particular reading direction, assessment, or action. These layers work together and each serves a distinct job.

• The content building block answers: what is this subject unit?
• Structure answers: in which knowledge area and topic space does it sit?
• The relationship answers: how does it connect to another building block?
• The perspective answers: how does the same building block help with a concrete user question?
• Definitions, examples, and sources belong to the content of their building block.

The classification level describes the subject altitude of a content building block. It complements the content type: the type explains what a building block is; the classification level explains how foundational, organizing, or concrete it acts inside the larger knowledge context.

• Foundation: knowledge you need to understand before you can reason meaningfully about a domain, such as core principles, terms, and mental models.
• Structure: knowledge that organizes, connects, or makes relationships decidable, such as architecture approaches, organizing models, and broader operating frames.
• Element: a concrete, clearly bounded cog in the system that acts inside larger relationships, such as a specific tool, technology, or executable method.
• The levels are not a quality or maturity ranking. They help readers place building blocks at the right altitude and connect them meaningfully.

A Concept is a durable mental model, paradigm, principle, or architectural understanding. It creates orientation in a problem space, explains motivation and mechanisms, and connects several possible methods, tools, and technologies. Its form is an orientation frame of principles, relationships, and target states.

• Core question: which model, principle, or target picture helps explain the problem space?
• Typical content: core principles, characteristics, variants, trade-offs, system effects, and boundaries.
• Examples: Domain-Driven Design, DevOps, CI/CD, Observability, Cloud Computing, and Event-Driven Architecture.
• Rule of thumb: it could remain a durable chapter in a strategy or architecture book.

A Method is a structured approach people use to analyze, decide, or solve a task. It can be taught and repeated and has recognizable rules, steps, phases, or loops. It often processes inputs and produces outcomes, decisions, or artifacts.

• Core question: how is the task performed concretely and traceably?
• Typical content: objective, prerequisites, roles, steps, inputs, outputs, success criteria, and pitfalls.
• Examples: Event Storming, Incident Management, Root Cause Analysis, Impact Mapping, and ATAM.
• Rule of thumb: it can be performed as a workshop, technique, or process with a recognizable result.

Concept and Method often sit close together because a method usually operates within a broader mental model. Classification follows the meaning of the node: an orientation framework is modeled as Concept; a concrete repeatable execution is modeled as Method.

• Domain-Driven Design is the Concept; Event Storming is a matching Method.
• Observability is the Concept; Incident Review or Root Cause Analysis are Methods for concrete investigation.
• Product Discovery is the Concept; Impact Mapping is a Method inside that mental frame.
• Principles, relationships, and target states point to Concept. Steps, roles, and outputs point to Method.

A Technology is a technical standard, protocol, runtime, framework, infrastructure component, or platform. It determines what systems build on, how they run or integrate, and which architectural and operational consequences follow.

• Core question: which technical foundation is implemented, integrated, operated, or used as an execution environment?
• Typical content: technical principle, interfaces, standards, integration mechanisms, runtime, scaling, and operational risks.
• Examples: REST, OAuth 2.0, Kubernetes, Docker, Neo4j, and React.
• A Technology may have a concrete name and maintainer. Its role as technical foundation in the system determines the classification.

A Tool is a concrete instrument or software product that people operate directly to support a task. It bundles functions in a usable interface or command line, provides integrations, and usually belongs to a vendor or product ecosystem.

• Core question: which concrete work instrument does a person use for analysis, planning, development, collaboration, or operations?
• Typical content: functionality, operation, integrations, APIs, user roles, licensing, limitations, and misuse.
• Examples: Jira, Miro, Postman, Docker Desktop, Grafana, and GitHub Actions.
• A Tool supports ways of working and uses technologies; its primary role is direct operational use.

Tool and Technology are easily confused because many products combine an interface with technical components. Nexonoma classifies the subject role described by the node: the directly used work instrument is Tool; the technical foundation or standard is Technology.

• REST is Technology; Postman is a Tool for designing and testing APIs.
• Docker is Technology for containerized execution; Docker Desktop is the directly operated Tool for local work.
• OpenTelemetry is Technology for telemetry instrumentation and exchange; Grafana is a Tool for analysis and visualization.
• Kubernetes is Technology for orchestration; a management interface built on top of it is treated as a Tool.

A term can carry several meanings in practice. Nexonoma determines the primary type from the durable subject statement represented by the node. This type remains stable across views and perspectives.

• Kanban can describe a durable organizational principle as a Concept; a concretely described Kanban procedure with rules and flow is modeled as a Method.
• CI/CD is always a Concept in Nexonoma. It describes the durable delivery and automation model; concrete pipelines and individual workflows are technical implementations of this Concept.
• REST remains Technology because its technical constraints and implementation are central, even though it is often called an architectural style.
• When one name denotes two independent meanings, Nexonoma creates two clearly named, connected nodes with a stable type for each.

Read the questions from top to bottom and decide which primary meaning the node should explain over time. The first question that clearly matches determines the type. If several questions match, the intended meaning is still too broad and should be described more precisely first.

• 1. Does the node describe a technical standard, foundation, or execution environment? Then Technology.
• 2. Does it describe a concrete work instrument used directly? Then Tool.
• 3. Does it describe a repeatable approach with rules, steps, or outputs? Then Method.
• 4. Does it describe a durable mental model, principle, or why? Then Concept.

The types become clearest when read as a connected system. Around Domain-Driven Design, Nexonoma connects four independent nodes that each retain their clear meaning.

• Domain-Driven Design – Concept: organizes thinking about business domains and models.
• Event Storming – Method: describes a performable approach to collaborative modeling.
• Miro – Tool: supports the workshop as directly used collaboration software.
• Neo4j – Technology: can provide a technical graph foundation for connected domain information.
• Relationships then explain which Method supports the Concept, which Tool enables the Method, and which Technology supports a technical implementation.