Info
Hi Rust community,
I’m working on an open-source Rust project called **rust-norion**, and I’m looking for contributors, reviewers, and design feedback from people who care about Rust systems engineering, AI infrastructure, local-first agents, memory systems, runtime boundaries, and testable control planes.
Repository:
- GitHub: https://github.com/yanghao1143/rust-norion
- Gitee mirror: https://gitee.com/babalibaba/rust-norion
The short version: **rust-norion is a DNA-inspired Rust inference control-layer / self-evolution control-engine prototype.**
It is not trying to be “another LLM inference engine”. It is not a wrapper around one model provider. It is not a production-ready replacement for mature runtimes.
The project focuses on the layer around inference:
- routing
- memory
- reflection
- runtime boundaries
- hardware/device planning
- evidence gates
- rollback
- experience replay
- self-evolution safety
The goal is to make reasoning behavior more persistent, inspectable, testable, and reversible without silently mutating model weights or trusting an opaque agent loop.
## Why I’m building this
A lot of AI agent systems work like this:
1. send prompt
2. get answer
3. maybe store something
4. maybe call tools
5. hope the next run is better
That is useful, but it becomes hard to reason about when the system runs for a long time.
Questions start to matter:
- Why did the agent choose this memory?
- Which strategy caused the regression?
- Can a routing or memory policy be rolled back?
- Can long-term experience improve behavior without storing raw private prompts?
- Can “self-improvement” be expressed as explicit, reviewable control-plane changes?
- Can Rust give us a better foundation for this kind of local-first, auditable AI system?
rust-norion is my attempt to explore those questions as an engineering project, not just as a paper idea.
## What “DNA-inspired” means here
The DNA analogy is intentionally limited.
This project is **not** biological simulation. It does not try to model biology directly.
Instead, rust-norion treats reasoning strategies as bounded, auditable “genes” in a control layer.
A `ReasoningGene` can represent things like:
- memory retrieval posture
- route threshold bias
- hierarchy weighting
- reflection checklist
- Rust-only tool policy
- validation-gate preference
- budget posture
- safety constraint
A task profile can have a `ReasoningGenome`: a small chain or graph of these strategy atoms.
For example:
- a Rust coding profile can prefer compiler/test evidence
- a long-context profile can prefer chunked memory and synopsis packing
- a local-tool profile can prefer stricter tool and filesystem gates
- a Chinese writing profile can keep its own memory/reflection strategy instead of overwriting a global heuristic
The runtime projection of this genome is an expression trace: what strategy was active, which route changed, what memory policy was applied, what validation gate ran, and whether rollback is possible.
The important part is that these strategy changes should be explicit and inspectable.
## Gene Scissors: controlled strategy editing
One part of the project is called **Gene Scissors**.
Again, this is a software analogy. It means a controlled editor for reasoning-control strategies.
It can propose edits such as:
- relabel a stale strategy
- cut a low-fitness strategy
- splice in a validated strategy
- quarantine a harmful or privacy-risk segment
- repair a malformed reference
- rollback to a known stable state
- regenerate a replacement from stable anchors and validated evidence
But it should not bypass validation.
A durable change needs a mutation plan:
- changed ids
- source evidence
- expected behavior
- validation commands
- rollback target
- admission state
Preview mode is read-only. Persistent writes require gates.
That is one of the central ideas of rust-norion: self-evolution should be boring, explicit, testable infrastructure, not magic.
## Current architecture
The project currently has these rough areas:
- root `src/`: demo control layer, service protocol experiments, CLI gates
- `crates/norion-core`: core control abstractions, runtime boundary, routing, KV, device profile
- `crates/norion-memory`: KV/gist memory, experience, indexing, migration, hygiene
- `crates/norion-agent`: agent workflow, task assignment, reflection, execution, collaboration structures
- `crates/norion-cli`: no-backend CLI/TUI protocol shell
- `docs/architecture`: architecture and boundary docs
- `docs/governance`: writer gates, clean-room rules, contributor governance
- `docs/runbooks`: local/remote model chain and operational verification notes
- `tools/evolution-loop`: unattended evolution-loop tooling and model-pool experiments
The core boundary I care about is:
```text
Prompt / Request
-> Adaptive Router
-> KV / Gist Memory
-> Recursive Scheduler
-> Hardware Planner
-> InferenceBackend / RuntimeBackend
-> Draft Answer
-> Reflection + Process Reward
-> Drift / Writer Gates
-> Experience Replay
The inference backend is deliberately behind a trait boundary. The control layer should be able to work with built-in local runtimes, command runtimes, manifest-backed production runtime boundaries, or remote model chains.
What works today
This is still a research prototype, but it is not just a README.
The repository has runnable pieces for:
local heuristic/demo inference-control flow
state inspection
device profile / execution-plan gates
CLI protocol shell
memory and experience modules
runtime manifest boundaries
test and benchmark gates
docs and runbooks for local/remote model-chain experiments
Example commands:
cargo check -q --workspace
cargo run -- --profile coding "Build a Rust Noiron inference control layer"
cargo run -- --inspect-state --inspect-limit 5
cargo run -- --list-devices
cargo run -- --device-gate
cargo test -q --workspace
The CLI shell can be inspected without starting a model backend:
cargo run -q -p norion-cli -- --help
What this project is not
To avoid wasting people’s time, here are the boundaries clearly:
It is not a production-grade LLM inference kernel.
It is not a polished end-user AI app.
It is not a commercial SaaS product.
It is not an attempt to bypass model/data licenses.
It is not trying to store raw private prompts as “genes”.
It is not safe to treat every self-evolution idea as automatically allowed.
The current maturity is closer to:
a serious Rust research-engineering prototype for inference control, memory, runtime boundaries, and auditable self-evolution gates.
That is exactly why I’m looking for contributors now. The most valuable work is still architectural, test-oriented, documentation-heavy, and systems-facing.
Where contributors can help
I’m especially looking for people who want to own narrow, reviewable lanes.
What kind of PRs are most welcome
Small PRs are much easier to review.
Good first PRs:
a focused failing test
a better error message with a regression test
a runbook command that has been tested locally
a small architecture diagram
a fixture cleanup
a doc that explains one boundary clearly
a trace/schema check
a contributor issue split into concrete tasks
Less useful PRs:
large rewrites
hidden behavior changes
“AI generated” broad refactors
copied code from unclear sources
benchmark claims without commands
memory/genome writes without gates
runtime changes that bypass manifest or rollback assumptions
Contributor credit
I want contributions to be visible.
The repository has a contributor zone with lanes, contributor cards, badges, Hall of Fame entries, release-note credit, and a path toward trusted contributor / reviewer / module collaborator roles.
The point is simple: if someone helps build a serious piece of the system, that work should be easy to point to later.
A PR can include:
Contributor Card
- Name:
- GitHub / Gitee:
- Lane: core | memory | runtime | docs | benchmark | governance | runbook | community | research
- Impact:
- Validation:
- Related issue / doc / demo:
- Showcase request: README | Hall of Fame | release notes | module docs | none
What I would like feedback on
If you do not want to contribute code, design feedback is still useful.
I would especially appreciate review on:
Are the Rust trait boundaries for runtime adapters sane?
Is the control-plane / runtime split too broad or too narrow?
Are the memory and genome concepts over-modeled?
What should be simplified before more contributors join?
Which gates should exist before allowing persistent self-evolution writes?
What would make the project easier for a new Rust contributor to run locally?
Which crates/modules need clearer ownership boundaries?
License
The project is GPL-3.0.
Commercial use is allowed under GPL-3.0 terms, but derivative and redistributed modified versions must follow compatible copyleft obligations. Public issues and pull requests are welcome, but protected branch merges require owner or maintainer review and approval.
Links
GitHub: GitHub - yanghao1143/rust-norion: Rust Noiron/Norion self-evolving local LLM runtime engine for non-commercial research deployment · GitHub
Gitee mirror: https://gitee.com/babalibaba/rust-norion
Contributor Zone: rust-norion/docs/contributor-zone.md at main · yanghao1143/rust-norion · GitHub
Reasoning Genome Chain: rust-norion/docs/architecture/reasoning-genome-chain.md at main · yanghao1143/rust-norion · GitHub
Roadmap: rust-norion/ROADMAP.md at main · yanghao1143/rust-norion · GitHub
If you are interested in Rust AI systems, local-first agents, memory/runtime boundaries, or auditable self-evolution, I would appreciate your feedback or contributions.
1 post - 1 participant
🏷️ Rust_feed