Fragment types

A fragment type describes the role a memory fragment plays. It helps readers understand what to expect and gives authors and AI agents a consistent way to classify knowledge.

A title tells you what a fragment is about. Its type tells you what kind of material it is: an explanation, a procedure, a verified fix, a reusable starting point, or a workspace-specific category.

Common fragment types

A workspace normally begins with one or more default types. The types available can vary by workspace, but common examples include:

• Knowledge for concepts, documentation, and reference material.
• Recipe for repeatable, step-by-step procedures.
• Solution for a verified resolution to a specific problem.
• Template for reusable structures, examples, or starting points.
• Skill or instruction-oriented types where a workspace stores executable guidance for AI agents.

Choose based on the fragment’s purpose, not its formatting. A document with numbered steps is not necessarily a Recipe if it is mainly explaining a concept. A Solution should describe a problem and a resolution that has actually been validated.

Types are scoped to a workspace

Fragment types belong to a workspace. Two workspaces may use different types or use similarly named types with different descriptions.

This lets a workspace model its own knowledge. A support workspace might add Known issue; a research workspace might use Finding and Experiment; a product workspace might define Decision.

Because types are workspace-specific, integrations should retrieve the available type identifiers from the target workspace rather than reusing an identifier from somewhere else.

Why descriptions matter

A useful type has a clear name and description. The description tells authors what belongs in the type and helps AI-supported workflows classify new material.

For example:

Decision — A choice that has been made, including context, alternatives considered, rationale, and consequences.

That description is more useful than “For decisions” because it defines the expected content and distinguishes the type from general Knowledge.

When to create a custom type

Create a custom type when your workspace repeatedly produces a recognizable kind of knowledge that has a distinct structure or lifecycle.

A good custom type:

• represents a durable category, not one project name;
• has a meaning that does not significantly overlap another type;
• gives authors clear expectations about what to include;
• improves filtering, retrieval, or automation.

Do not create a type merely to group a handful of related documents. A collection or tag is usually better for a topic, release, initiative, or audience.

Type, tag, or collection?

Use a type for what a fragment is: a Recipe, Decision, or Solution.

Use a tag for a reusable attribute: authentication, api, or beginner.

Use a collection for a curated set: “Getting started”, “Version 2 migration”, or “Support onboarding”.

A fragment has one type but may have multiple tags and belong to multiple collections. Keeping those jobs separate makes the workspace easier to understand.

Example: documenting a recurring failure

Suppose a team investigates an intermittent login error.

• While the cause is unknown, notes may remain in a research-oriented fragment.
• Once the cause and remediation are verified, create or update a Solution.
• Tag it authentication and the affected product.
• Add it to a “Login troubleshooting” collection if that curated guide exists.

The type communicates that the fix is verified; the tags describe the subject; the collection places it in a reader journey.

Good practices

• Start with existing types before adding custom ones.
• Give custom types precise, non-overlapping descriptions.
• Name types as singular concepts (Decision, not Decisions).
• Avoid encoding temporary projects or status values as types.
• Review unused and overlapping types as the workspace evolves.
• Do not assume another workspace has the same type identifiers.

Related concepts

• Memory fragments are classified by fragment type.
• Tags and summaries add descriptive retrieval signals without changing a fragment’s role.
• Collections curate groups of related fragments.