Open, verifiable memory design + documentation ecosystem
Making memory systems explainable, reviewable, and reproducible.
Principle: No black boxes. If it can't be inspected, it can't be trusted.
✅ 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 that could violate IP boundaries
- A "trust me bro" spec dump — we prefer evidence, references, and clear assumptions
| Resource | Description | |
|---|---|---|
| ⭐ | omi core repository | Start from START_HERE.md — beginner-friendly entry points and tracks |
| 💬 | Discussions | Questions, proposals, and design RFCs |
| 🎯 | Issues | Actionable tasks, review findings, and validation reports |
Not sure which track fits you? Try our interactive Track Finder quiz →
⚡ Track 01 — Developers (tooling + automation + docs)
You can contribute without touching hardware.
| What you'll do |
|---|
| Build linters/checkers (naming rules, consistency checks, schema validation) |
| Improve documentation pipelines (doc generation, CI, templates) |
| Create "spec ↔ schematic ↔ validation" traceability helpers |
Good fit if you like: Python CI GitHub Actions docs engineering automation
🔍 Track 02 — Reviewers (correctness + clarity + scope enforcement)
You help keep OMI coherent.
| What you'll do |
|---|
| Review docs/specs for internal consistency and missing assumptions |
| Check that decisions are justified and scoped properly |
| Turn "vibes" into structured review notes and actionable issues |
Good fit if you like: systems thinking correctness design review documentation quality
🧪 Track 03 — Testers (validation evidence + reproducible reports)
You turn designs into reality checks.
| What you'll do |
|---|
| Run validation steps on real platforms |
| Submit structured test reports (platform details, procedure, results, failures) |
| Help build the validation matrix (what works where, and why) |
Good fit if you like: hardware bring-up debugging measurement discipline reporting
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 1. OPEN │───▶│ 2. READ │───▶│ 3. PICK │───▶│ 4. SUBMIT │
│ omi repo │ │ START_HERE │ │ a task │ │ PR / Issue │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
Task labels to look for:
| Label | Lane |
|---|---|
good-first-issue |
Easy entry |
review-needed |
Review lane |
test-needed |
Validation lane |
Submit either: a PR (docs/tooling) or an Issue using the template (review finding / validation report).
| We optimize for | Not for |
|---|---|
| 🔁 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.
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.
