Astrid RFCs
Design proposals for changes to Astrid's kernel-to-user-space contract.
RFCs govern any substantial change to the contract surface between the kernel and user-space: the host ABI, IPC protocol, capability model, manifest schema, VFS semantics, capsule interface standards, and SDK public API. They are the authoritative specification - implementations conform to them, not the other way around.
When you need an RFC
- Adding or changing a host function in the syscall table (
astrid-sys) - Changing IPC topic conventions or payload schemas
- Modifying the capability token format or validation semantics
- Changing
Capsule.tomlmanifest schema or dependency resolution - Changing VFS path resolution rules or overlay behavior
- Defining a new capsule interface standard (tool schemas, cross-capsule contracts)
- Breaking changes to
astrid-sdkpublic API
Process
- Fork this repo and copy
0000-template.mdtotext/0000-my-feature.md. - Fill in the RFC. Focus on motivation and the reference-level spec.
- Open a pull request. Use the filename
0000-my-feature.mdin the PR. - Discussion happens on the PR. Revise as needed.
- When consensus is reached, a maintainer assigns the next sequential RFC
number, renames the file to
text/NNNN-my-feature.md, and merges. - Implementation proceeds in
astrid-sdk(types behind feature flags) and reference capsules.
Lifecycle
- Draft - PR open, under discussion.
- Active - Merged. Types being implemented in
astrid-sdk. - Final - Implemented and stable. Breaking changes require a new RFC.
- Withdrawn - Closed without merge.
- Superseded - Replaced by a newer RFC (noted in header).
SDK integration
Each RFC maps to an astrid-sdk feature flag:
# Individual RFC types
astrid-sdk = { version = "0.2", features = ["rfc-1"] }
# All RFC types
astrid-sdk = { version = "0.2", features = ["all-rfcs"] }Index
| RFC | Title | Status |
|---|---|---|
| 0001 | RFC Process | Active |
License
Dual-licensed under MIT and Apache 2.0.
Copyright (c) 2025-2026 Joshua J. Bouw and Unicity Labs.
