An open specification for engineering education built around demonstrable capability.
Open Engineering Education (OEE) defines how engineering courses are structured, how learning is demonstrated, and how claims about course readiness are supported by evidence. It combines a public specification with a curriculum designed to follow that specification.
OEE emphasizes underlying mechanisms, practical engineering work, reproducible results, and transparent claims about what learners can demonstrate.
Project status: v0.0.1 — draft. The specification is evolving and is not a finalized standard. Course status labels describe the evidence available for each course.
- Steward: 0xBUFF
- Author: Christopher S. Aondona
- Licensing: CC BY 4.0 for specification and curriculum text; MIT for code and scripts.
OEE establishes:
- Principles: the expectations that govern the specification and its curriculum.
- Course format: the required structure and metadata for course definitions.
- Evidence rules: what counts as demonstrated learning and completed engineering work.
- Status labels: the evidence required to describe a course as
draft,tested, orverified. - Conformance: the requirements for evaluating whether a course, program, or implementation follows the specification.
- Governance: how the specification evolves and how significant changes are proposed and reviewed.
Start with the specification overview.
The OEE curriculum is organized into five engineering programs:
| Code | Program |
|---|---|
SEF |
Software Engineering Foundations |
APP |
Application Engineering |
SYS |
Systems Engineering |
AI |
AI Engineering |
SEC |
Security Engineering |
The curriculum directory contains the program definitions and their course structures.
A course is complete when its required outcomes are demonstrated and its required work is supported by appropriate evidence. Time spent, material consumed, and unchecked claims are not substitutes for demonstrated capability.
Learners should understand the underlying mechanisms before relying on abstractions, frameworks, or managed services. Engineering decisions must be explainable rather than based solely on familiarity with an interface.
Course status, assessment results, benchmarks, and project outcomes must state what the evidence supports and what it does not establish. No course should be described as tested or verified without meeting the corresponding requirements.
The public specification and curriculum are published under their declared licenses. Optional commercial products may provide additional services, but they do not change the requirements of the public specification.
Read the full principles.
0xBUFF stewards OEE and oversees the development of its public specification.
0xNAND is the paid reference implementation developed under 0xBUFF. It may implement OEE concepts and provide additional tooling or services, but using 0xNAND is not required to study, teach, or implement OEE.
The public specification remains distinct from any individual implementation. Product features, commercial arrangements, and implementation choices do not change the specification unless the relevant change is formally adopted through the OEE governance process.
An implementation's relationship to OEE does not, by itself, establish that it conforms to the specification.
OEE distinguishes between completing activities and demonstrating engineering capability.
Depending on the course, completion may require conceptual checkpoints, implementation exercises, practical labs, tests or evaluations, explained design decisions, and a technical retrospective. Project-based courses also require their specified deliverables and evaluation.
Evidence should make it possible for a reviewer to understand what was done, how the result was produced, whether it can be reproduced, and what limitations remain.
Read Evidence Rules and Status Labels.
Learner work belongs in a workspace controlled by the learner, not in the OEE specification repository.
The OEE Workspace repository provides the reusable structure, templates, and generation scripts for practical learning and evidence. Use it as the starting point for a personal or group workspace, where you keep your actual implementations, labs, exercises, notes, projects, progress records, and supporting evidence.
| Path | Purpose |
|---|---|
spec/ |
Normative documents that define OEE |
curriculum/ |
Programs and course definitions |
scripts/ |
Repository checks for the specification and curriculum |
GOVERNANCE.md |
Stewardship, contribution policy, conduct, and decision-making |
rfcs/ |
Proposals for significant changes to the specification |
.github/ |
Repository automation and contribution templates |
The specification defines the common requirements. Curriculum files apply those requirements to particular programs and courses. Workspace templates, generation scripts, and implementations may support the process, but must not silently redefine the specification.
Contributions should improve clarity, correctness, reproducibility, or consistency with the specification.
Before submitting a change:
- Read the principles.
- Review the contribution guidelines.
- Search existing issues and RFCs.
- Follow the repository's sign-off, review, and validation requirements.
Changes to normative requirements should be proposed through the RFC process rather than introduced indirectly through a course or implementation.
Specification and curriculum text are licensed under Creative Commons Attribution 4.0 International. Code and scripts covered by the repository's software license are licensed under the MIT License.
Contributors must have the rights needed to submit their work under the applicable license. See the repository's contribution and attribution documents for additional details.
OEE is a draft specification. Its requirements may change through the documented governance process.
A published course, program, or implementation must not be described as verified, conforming, accredited, or certified unless the applicable criteria and documented review support that claim. OEE does not, by itself, guarantee employment outcomes, professional accreditation, or mastery of every subject associated with a course.
0xBUFF offers optional paid mentorship for learners who want personalized guidance, technical feedback, project reviews, and accountability while working through engineering material.
Mentorship is a separate service. It is not required to access or use the public OEE specification and curriculum, and it does not affect course status or conformance requirements.
See 0xBUFF Mentorship for plans, pricing, eligibility, and application details.