Assignments are relationships here, class-level rules carry a dollar sign, and the tags and the manifest disagree on the version number

An assignment states a relationship, so nothing goes stale

The difference from an ordinary language shows up in four lines:

a = 1
b = a + 2

a = 3

assert(b, 5)

In a conventional runtime the third line would leave `b` holding the value three from the moment it was computed. Here an assignment is not an instruction that runs once and finishes, it is a relationship the runtime records and maintains, so `b` is the sum of `a` and two, and changing `a` brings it up to date. The crate description in Cargo.toml says the same thing in engineering terms: statements are tracked in a dependency graph and re-evaluated when what they depend on changes. The claim extends past local variables to properties, class-level rules and everything else the language reference covers, and the reference states that every example in it is executable, with `tests/reference.md` as the executable form that runs under `cargo test`.

The manifest says 0.1.0 and the newest tag says v0.7.10

The version numbers in this repository do not agree. Cargo.toml declares `version = "0.1.0"`, and every workspace dependency line in that file is absent because there is one crate. The release list tells a different story: v0.7.8, v0.7.9 and v0.7.10, all published in June 2024, with v0.7.10 dated 2024-06-14. The last push to the repository is dated 2026-09-11, more than two years after the newest tag. So the tags describe a line that reached 0.7.10 and stopped, while the manifest describes a crate that starts again at 0.1.0, and neither number is dated in the file that a user would read first. The default branch is named `rust`, not `main`, which tells you the language port is where the work happens. Nothing in the README explains the gap, and the npm package linked at the top of the file gives no version either.

Class-level rules are written with a dollar sign and cover every instance

The first program in the file is four statements and one assertion, and its title says what it proves: Socrates is mortal without being told so.

# There is a Human type with a name
class Human(name: str):
    this.name = name

# Every human is mortal
$Human.mortal = true

# Socrates is a Human
socrates = Human("Socrates")

# Therefore, Socrates is mortal
assert(socrates.mortal, true)

Three things are worth naming. A class declares its parameters in the header and assigns them to `this` in the body. A property can be written with a leading dollar sign on the type itself, which is how `mortal` becomes true for every `Human` rather than for one object. And the assertion takes the expected value as a second argument, so it reads as a statement about the world rather than as a boolean test. The language reference covers the surrounding machinery by name: statements and state, variables and dependencies, expressions, types and instances, properties, class-level rules, blocks and scope, control flow, functions, transactions, built-in objects, and error messages.

Two runtimes come out of one specification, and the second one is fine-tuned

The runtime story is laid out as a two column table. The Rust runtime lives in this repository and implements the language specification by executing declarative statements. The LLM runtime is a fine-tuned model trained on synthesized datasets derived from that same specification, with its weights hosted at huggingface.co/nucleoid. The synthesis pipeline is visible in the tree rather than described: `dataset/`, `synth/` and `ref/` sit next to `src/`, and `dataset/` is what the manifest's dev-dependency comment refers to when it explains that field-ordered serialization stays out of the published dependencies because only the dataset rendering tooling needs it. An npm package named `nucleoidai` is linked from the top of the README. The stated motivation for the whole split sits in the opening: the claim is that pattern engines reason more reliably over structured entities and relationships than over unstructured natural language.

The specification at the root outranks the reference next to it

Language governance is done with numbered documents. `docs/README.md` is the language reference, assembled from the NUC documents in `docs/`, indexed by NUC 0 with the conventions set out in NUC 1. `nucleoid.spec.md` sits at the repository root and is called normative, with an explicit tie-break rule: where the two disagree, the specification wins. `docs/examples.md` covers the same ground as complete programs, each one runnable as written. So a reader has three entry points with a stated priority order, and one of them is a file in the root that the README does not summarise. The tree also carries `CLAUDE.md`, `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md`, and the README's final section is a quoted note from a contributor that runs into a claim about world models and then stops mid sentence, with the rest of the argument about the runtime keeping a logic graph true not present in the file.

The dependency list is annotated with the reason for each choice

The manifest reads like a design note. `logos = "0.15"` is the lexer generator, called the mainstream Rust choice for token definitions. `indexmap = "2"` is there because object properties, class instance lists and graph edges are all order-sensitive in the specification, so an unordered map would change observable behaviour. `chrono` is taken with default features off and only std, now and alloc enabled, with the comment that this keeps the crate free of platform time-zone bindings and the runtime works in UTC, which is a real constraint on a language with a date built-in. `clap` is trimmed the same way, with std, derive, help, usage and error-context but no defaults. `thiserror` derives the error enum, `regex` handles regular expression literals, and `serde_json` covers JSON literals and value rendering. Unsafe code is forbidden outright through `[lints.rust] unsafe_code = "forbid"`, and the library and the binary share the name `nucleoid`.

Three example programs, a build script and an agent instruction file

The repository is laid out so the language is testable from inside itself. `examples/` holds three files named `_snippet.rs`, `dependencies.rs` and `scaling.rs`, which between them cover the snippet form used in documentation, dependency tracking and scale. `build.rs` at the root suggests some codegen or asset step happens before compilation, though the file's contents are not part of what is visible here. `tests/` holds the executable reference. Beyond code, the tree ships `docs/`, `examples/`, `nucleoid.spec.md`, `ref/`, `src/`, `synth/`, `tests/` and `dataset/`, plus a `CLAUDE.md` at the root, which is a notable thing to find in a project whose argument is that language models reason better when the structure is explicit rather than left to prose. The package declares `edition = "2024"` and `rust-version = "1.85"`, and its categories are compilers and development tools.

Editorial conclusion

Nucleoid is interesting to read for its dependency graph semantics and its split between a deterministic runtime and a fine-tuned one, and both halves are documented from the same specification file. Do not depend on it as a package yet: the manifest version is 0.1.0, the release tags stopped at v0.7.10 in June 2024, the default branch is rust rather than main, and the specification is normative while most of the prose sits in generated documents under docs. Before building anything on it, read nucleoid.spec.md rather than the README, confirm the runtime you want is the Rust crate and not the fine-tuned model, and check what the example programs under examples/ actually execute, since the reference claims every snippet is runnable under cargo test.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. NucleoidAI/Nucleoid on GitHub
3. Project website
4. README
5. Releases