Open Memory Initiative

No black boxes.
If it can't be inspected,
it can't be trusted.

Building an open, verifiable memory design & documentation ecosystem — making memory systems explainable, reviewable, and reproducible.

OMI is +
✓ A community effort to document and design memory systems with auditability and repeatable validation
✓ A place where assumptions are explicit, decisions are documented, and review is structured
✓ A collaboration between developers, reviewers, and testers — not just PCB designers
OMI is not +
✗ A place to share NDA/proprietary vendor material, leaked docs, or anything violating IP boundaries
✗ A "trust me bro" spec dump — we prefer evidence, references, and clear assumptions

Where to start

⭐ Main Project
OMI Core Repository
START_HERE.md
Beginner-friendly entry points and contribution tracks
💬 Community
Communication Channels
→ GitHub Discussions — Questions, proposals, design RFCs
→ Issues — Actionable tasks, review findings, validation reports
Track Finder
1. What excites you most?
2. Preferred tools?
3. Your superpower?

Pick a track

Click a track to explore what you'll be doing.

You can contribute without touching hardware.

What you'll do
[01] Build linters/checkers (naming rules, consistency checks, schema validation)
[02] Improve documentation pipelines (doc generation, CI, templates)
[03] Create "spec ↔ schematic ↔ validation" traceability helpers
GOOD FIT IF YOU LIKE:
Python, CI, GitHub Actions, docs engineering, automation.

You help keep OMI coherent.

What you'll do
[01] Review docs/specs for internal consistency and missing assumptions
[02] Check that decisions are justified and scoped properly
[03] Turn "vibes" into structured review notes and actionable issues
GOOD FIT IF YOU LIKE:
Systems thinking, correctness, design review, documentation quality.

You turn designs into reality checks.

What you'll do
[01] Run validation steps on real platforms
[02] Submit structured test reports (platform details, procedure, results, failures)
[03] Help build the validation matrix (what works where, and why)
GOOD FIT IF YOU LIKE:
Hardware bring-up, debugging, measurement discipline, reporting.

How contributions work

Fast path — click each step

$ Open the main omi repository ▌

Contribution standards

Reproducibility>cleverness
Explicit assumptions>hidden context
Structured review>subjective debate
Evidence & traceability>"it seems right"

If something feels ambiguous, open a Discussion or issue first — we'd rather clarify early than merge confusion.

⚠ Licensing & Safety
Each repo may have its own LICENSE. If a repo has no license file, assume contributions shouldn't be reused externally until licensing is clarified — and open an issue to fix it.

Want to help but unsure where?

Open a Discussion titled "I want to contribute — help me pick a starter task"

Include: your skills, available time, and whether you can test on hardware.
Welcome aboard.
→ Go to OMI Repository