Atom IDs

Every atom carries an immutable string ID:

<prefix>_<slug>_<hash4>

Pattern: /^[a-z]{2,4}_[a-z0-9_]+_[a-z0-9]{4}$/

Part	Rule
prefix	2–4 lowercase letters from the kind table (e.g. feat, cri, vis, dom).
slug	Lowercase letters + digits + underscore. Freely chosen.
hash4	4-char [a-z0-9] disambiguator (collision-resistant for hand-authored docs).

Examples

feat_create_habit_h14a
cri_initial_load_h31a
ent_habit_h7h8
ui_habits_screen_a1b2
fix_empty_state_z9z9
env_database_url_q4q4

Generation

The cloud authoring UI generates IDs for you. The hash4 is sampled from [a-z0-9]^4 and re-rolled on collision within the project.

If you hand-author atoms in a file, you can pick any 4-char hash — just keep it stable across edits. The hash is the foreign key for:

• Relations (from, to)
• Provenance entries (per-atom)
• Source-map sidecars (RFC-0009 SenLang map)
• Audit logs

Renaming the slug after IDs are referenced breaks edges silently if you don’t update every reference. The cloud UI prevents this; hand-authoring requires discipline.

Forbidden patterns

• Prefix outside the 26 kinds (validator rejects).
• Uppercase letters anywhere (validator rejects).
• Trailing whitespace (validator strips).
• IDs longer than 64 characters (no hard limit yet, but tooling assumes ≤ 64).

Migration

If you have legacy v0.1 / v0.2 atoms, see the migration guide (TBD — file an issue if you have legacy data). The kind set was extended additively in v0.2; existing v0.1 IDs remain valid.

See also

• Atom model — why IDs are stable.
• The 26 atom kinds — kind ↔ prefix mapping.
• Relations — IDs are the foreign keys.