RFC-005 — Profile system

Status: ratified. Source: atomprd/specs/rfcs/RFC-005-profile-system.md.

Summary

A project carries a profile_key that names which atom kinds + relations are expected. The default profile is atomprd-v1 (all 26 kinds). Tools may ship narrower profiles for specialised flows.

Why profiles

A PM-tier tool focused on vision + persona + module + feature + criterion shouldn’t have to display the 6 DevOps block kinds.
A DevOps-only tool focused on services + envs + deploys shouldn’t have to display product atoms.
A vertical-specific tool (e.g. spa booking) may have an opinionated default kind set.

The profile narrows the surface; it doesn’t extend it. New kinds still require a spec RFC.

Built-in profiles

Profile key	Kinds included
`atomprd-v1`	All 26 (default).
`atomprd-pm`	`vision`, `persona`, `module`, `feature`, `criterion`, `description`, `note`, `decision`, `out_of_scope`.
`atomprd-devops`	`service`, `env_var`, `vendor`, `host_domain`, `build_step`, `deploy_target`, `decision`, `note`.
`atomprd-runtime`	All except DevOps blocks B12-B17.

Tools MAY define custom profile keys. The cloud authoring UI ships atomprd-v1 by default; vertical templates (post-launch) ship narrower profiles.

Storage

decomposition_nodes.profile_key records which profile the atom was created under. The validator uses the profile to gate which kinds are valid in that project.

Migration between profiles

Switching a project from atomprd-pm to atomprd-v1 is purely additive — the existing atoms stay valid, and new kinds become available. Switching the other way requires deleting (or hiding) atoms of kinds the narrower profile excludes.