EriX Meta Repository

This repository contains shared governance, contribution rules, and process documents for the EriX operating system project.

EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.

All technical requirements are defined in:

• Requirements & Conventions Document
• Self-Hosting Milestones

See:

• docs for design documents, specifications, and development plans.
• Architecture repositories (kernel, bootloader, etc.)

Purpose of This Repository

This repository implements the EriX meta-governance repository. Its purpose in EriX is to define shared repository governance, contribution, review, and clean-room policy.

Functionally, it records organization-wide rules that component repositories follow. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• define shared contribution, review, licensing, and clean-room policy
• provide shared repository standards and governance material used across EriX
• keep project-wide process expectations independent of component code

Clean-Room Policy

EriX follows a strict clean-room philosophy:

• No external source code may be copied.
• No external Rust crates are allowed.
• No code generation tools that embed third-party code.
• All code must be authored within the project.

Violations will result in rejection of the contribution.

License

All EriX repositories are licensed under the ISC License.

Development Model

EriX development is:

• Modular (one repo per major component)
• Deterministic
• Reproducible
• Authority-explicit
• Security-first
• Self-hosting oriented

See docs/phases/README.md for the system development phase structure.

Governance Principles

meta governance is scoped to shared repository standards and clean-room contribution policy.

The scoped governance rules are:

• It defines organization-wide expectations without replacing component-specific governance.
• Templates must stay generic enough to be specialized by each repository.
• Contribution, licensing, and review policy must remain clear, auditable, and clean-room compatible.
• Project-wide policy changes require documented rationale before component repositories adopt them.
• CI runs markdownlint-cli2 across every Markdown policy, template, and workflow-support document in the repository.

Policy Boundaries

• meta owns shared process policy; implementation policy stays with the component repositories.
• Template text must not be copied into components without being specialized for that component scope.

Contact

Development occurs in EriX organization and discussions happen in issues and design documents.

Discussions should occur via issues or design documents.

No decisions are considered valid without documented rationale.

You can also reach out to maintainers via email: admin@erikinkinen.fi.