Data Model

Concept

A concept is the atomic element of MIF — a single .md file in a bundle. It contains:

Property	Required	Type	Description
`id`	REQUIRED	UUID	Globally unique identifier (stable across relocation)
`content`	REQUIRED	String	The concept content (Markdown)
`type`	REQUIRED	Enum	Knowledge classification (see below)
`created`	REQUIRED	DateTime	When the memory was created
`modified`	RECOMMENDED	DateTime	When last modified
`ontology`	RECOMMENDED	Object	Reference to applied ontology
`namespace`	RECOMMENDED	String	Hierarchical scope
`tags`	OPTIONAL	Array	Classification tags
`entities`	OPTIONAL	Array	Referenced entities
`relationships`	OPTIONAL	Array	Typed relationships
`temporal`	OPTIONAL	Object	Temporal validity data
`provenance`	OPTIONAL	Object	Source and trust data
`embedding`	OPTIONAL	Object	Embedding reference
`citations`	OPTIONAL	Array	Citation references (Level 3)
`summary`	OPTIONAL	String	Compressed content summary (Level 3)
`compressedAt`	OPTIONAL	DateTime	When compression was applied (Level 3)
`extensions`	OPTIONAL	Object	Provider-specific data

The frontmatter type field holds the base knowledge classification; in the JSON-LD projection produced by scripts/mif_convert.py, this value is surfaced as conceptType.

Knowledge Types

Every concept declares one of three base knowledge types, a general taxonomy of how knowledge is structured:

Type	Description	Namespace Hint
`semantic`	Declarative knowledge: facts, concepts, decisions, schemas	`_semantic/*`
`episodic`	Time-bound records: events, incidents, changelog/deprecation	`_episodic/*`
`procedural`	How-to knowledge: runbooks, processes, patterns, migrations	`_procedural/*`

Base Type Descriptions:

Semantic: Declarative knowledge about the world—facts, concepts, decisions, preferences, and relationships between entities. Examples: architectural decisions, technology choices, schemas, domain knowledge.
Episodic: Time-bound records of events—incidents, deprecations, changelog entries. These concepts have strong temporal context and represent “what happened.”
Procedural: How-to knowledge—runbooks, migration guides, code patterns, and step-by-step processes. These concepts describe “how to do” something.

The cognitive-memory origin of this triad, and its reinterpretation for agent memory, live in the AI Memory profile (profiles/ai-memory/).

Ontology-Extended Types

Ontologies MAY define extended types using namespace prefixes:

# In ontology definition
entity_types:
  - name: decision
    base: semantic
    description: "Architectural or design decision"
  - name: runbook
    base: procedural
    description: "Step-by-step operational guide"
  - name: incident
    base: episodic
    description: "Production incident record"

When using ontology-extended types, the type field uses the base type, while specific categorization is expressed through the namespace:

---
type: semantic
namespace: _semantic/decisions
ontology:
  id: mif-base
---

This allows ontologies to define rich taxonomies while maintaining interoperability through the base type foundation.

Ontology Reference

A concept MAY declare which ontology it conforms to using the ontology field:

Property	Required	Type	Description
`id`	REQUIRED	String	Ontology identifier (matches `ontology.id` in ontology definition)
`version`	OPTIONAL	String	Semantic version (e.g., “1.0.0”)
`uri`	OPTIONAL	URI	URL to the ontology definition file

Example:

ontology:
  id: regenerative-agriculture
  version: "1.0.0"
  uri: https://raw.githubusercontent.com/modeled-information-format/MIF/main/ontologies/examples/regenerative-agriculture.ontology.yaml

The ontology.id MUST match the ontology.id field in the referenced ontology definition file. This enables:

Validation that namespace paths conform to the ontology’s defined namespaces
Discovery pattern matching for entity type suggestions
Schema validation for entity-specific fields