Introducing MIF - Memory Interchange Format

[zircote]

What is MIF?

MIF (Memory Interchange Format) is an open standard for representing AI memory as portable, plain-text files.

AI assistants accumulate knowledge over time: user preferences, technical decisions, project context, operational procedures. Today, that knowledge is locked inside whichever system captured it. If you switch tools or want to share context across assistants, you're starting from zero.

MIF defines a common data model for this knowledge so it can move freely between systems.

The Problem

Every AI memory system stores knowledge differently. No shared vocabulary exists for what a "memory" contains, how memories relate, or how to organize them. The consequences:

• Knowledge captured in one system can't be read by another
• Switching providers means losing accumulated context
• There is no way to back up or version-control AI memories using standard tools
• Teams can't share institutional knowledge between different AI tools

This is roughly where web syndication was before RSS and Atom, or where container images were before OCI. The technology works, but the formats are siloed.

What MIF Defines

Dual Format Representation

MIF memories can be written as Markdown files (.memory.md) or JSON-LD documents (.memory.json). Both formats are losslessly convertible.

Markdown files are valid Obsidian notes. They work in any text editor, any Markdown processor, any version control system. JSON-LD files are machine-processable and compatible with semantic web tooling.

---
id: 550e8400-e29b-41d4-a716-446655440000
type: semantic
created: 2026-01-15T10:30:00Z
namespace: _semantic/decisions
title: "Use PostgreSQL for Data Storage"
---

PostgreSQL selected for the analytics service. Strong JSON support,
team familiarity, and proven reliability at our scale.

Three Memory Types

Knowledge breaks down into three base types, modeled on how human cognition categorizes information:

• Semantic - facts, concepts, decisions, preferences. "We use PostgreSQL." "The API rate limit is 1000 req/min."
• Episodic - events, experiences, incidents. "Production went down on Tuesday because of a connection pool leak."
• Procedural - processes, patterns, how-to knowledge. "To deploy to staging, run these three commands."

These aren't arbitrary categories. They map to well-studied cognitive science models of how memory works, and they turn out to be a natural fit for how AI-captured knowledge actually breaks down in practice.

Namespace Hierarchy

Within each memory type, namespaces provide finer organization:

_semantic/decisions      # Architectural choices with rationale
_semantic/knowledge      # APIs, learnings, factual knowledge
_episodic/incidents      # Production issues, postmortems
_episodic/sessions       # Debug sessions, work sessions
_procedural/runbooks     # Operational procedures
_procedural/patterns     # Code conventions, best practices

Typed Relationships and Entities

Memories don't exist in isolation. Relationship types (relates_to, supersedes, derived_from) and entity types (Person, Organization, Technology, Concept) make connections between memories explicit and queryable.

When a new decision supersedes an old one, that relationship is recorded in the memory itself. When a runbook references specific technologies, those references are typed and can be traversed.

Ontology System

Different industries and use cases need different vocabulary. A regenerative agriculture operation tracks soil tests, crop rotations, and carbon credits. A software engineering team tracks services, deployments, and incidents.

The ontology system handles this. A base ontology (mif-base) defines the core memory types and traits. A shared traits library (shared-traits) adds cross-domain patterns like lifecycle tracking, compliance auditing, and geographic data. Domain-specific ontologies extend these with industry vocabulary.

The inheritance chain:

mif-base                   # core: timestamped, confidence, provenance
  -> shared-traits         # cross-domain: lifecycle, auditable, located, measured
    -> your-domain         # industry-specific entity types and namespaces

Ontologies are YAML files validated against a JSON Schema. They define entity types, traits (reusable field groups), and custom namespaces. They also define discovery patterns -- rules that help tooling suggest the right namespace when you capture a new memory.

Conformance Levels

Not every implementation needs every feature. Three conformance levels:

• Level 1 (Core) - id, type, content, created. Four fields. That's it.
• Level 2 (Standard) - adds namespaces, entities, relationships, and timestamps.
• Level 3 (Full) - adds bi-temporal metadata, memory decay modeling, provenance tracking, embeddings, and citations.

A simple tool can implement Level 1 in an afternoon. A production system can go to Level 3 for decay curves and audit trails.

Temporal Model and Memory Decay

Memories aren't all equally relevant. A decision made last week matters more than a preference stated two years ago. The temporal model tracks both when a fact was recorded and when it was actually true (bi-temporal), plus a decay model inspired by Ebbinghaus's forgetting curve research.

Implementations can age out stale memories automatically. Users decide how long different knowledge types stick around.

Provenance

Where did a memory come from? Which agent captured it, what's the confidence level, did the user state it explicitly or was it inferred? Provenance tracking answers these questions. A memory explicitly confirmed by a user is more reliable than one inferred from a passing comment.

Design Principles

A few things that guided the format:

Local-first. MIF files are plain text on your filesystem. No cloud dependency, no database required. They work with Git, with rsync, with any backup tool you already have.

Human-readable. The Markdown format is something a person can open, read, and edit directly. Not a binary format or a database dump -- a note with structured metadata.

Machine-processable. The JSON-LD format gives machines everything they need: semantic types, standard URIs, and a schema for validation. The two formats convert losslessly.

Extensible without breaking. Custom properties, custom ontologies, and custom namespaces all work without modifying the core spec. A Level 1 tool can read a Level 3 file (it just ignores what it doesn't understand).

Current Status

MIF is at version 0.1.0-draft. The specification and schemas are published, along with the base ontology, shared traits, and example ontologies for a few domains (software engineering, agriculture, education, biology research).

The spec includes migration guidance for moving existing memories into MIF format from other representations.

We're actively working on extension packaging, distribution, and discovery for community ontologies. Feedback on the specification, the ontology system, and the overall direction is welcome.

Get Involved

• Read the specification
• Browse the ontology examples
• Try the getting started guide
• Open an issue or start a discussion