Maturity — the OMM dashboard

OMIR grades the stability of each resource type with the OMIR Maturity Model (OMM), an integer 0–5 surfaced in meta.maturity. Maturity is a promise about change, not a quality score — and we grade honestly. We never overclaim.

The scale

OMMMeaning
0Draft — shape may change without notice.
1Early — implemented, but the field set is volatile.
2Trial use — implemented in more than one system; breaking changes possible.
3Stabilizing — widely implemented; changes require deprecation.
4Mature — broadly implemented, battle-tested; backwards-compatible evolution only.
5Normative — locked; changes only via a new release.

R1 resource grades

ResourceOMMRationale
MemoryRecord OMM-4 The atomic unit; the most exercised and stable shape in the reference implementation.
Entity OMM-3 Widely implemented; changes require deprecation.
Relationship OMM-3 Stable graph-edge shape; Hebbian strength + temporal validity.
Episode OMM-3 The episodic backbone; event-time vs ingestion-time well established.
Bundle envelope The document container, not a graded memory resource — it carries no OMM level.

Honesty is a feature: a consumer SHOULD treat lower-OMM resources as more likely to change between releases. New resources introduced later start lower and earn their level through real, independent implementation.

What's still earning its level

Candidate generalizations that would move OMIR from a Veld-seeded core toward a global standard enter at OMM-0/1 and earn maturity through independent implementation — for example open vocabularies (CodeableConcept), cross-system entity identifiers, a privacy/retention block, and multi-agent identity. See Toward a Global Standard for the full roadmap and its priority order.

The single most important input to maturity is a second implementer. A resource cannot honestly reach OMM-2 until more than one system implements it. Tell us what you've built on Implementations, or push on a specific part via Feedback.