RFC-004 — L2 Area Definition: thematic grouping within a Domain

---

1. Summary

Define *rea*(Área) as the L2 level of the monorepo taxonomy: the grouping of Sectors that share the same purpose or theme within a Domain. The grouping criterion varies by Domain (audience, functional theme, or artifact type), which is consistent with the Linnaean model where each branch of the tree can apply the level criterion differently.

---

2. Why the criterion can differ between Domains

In biology, the criterion used to split a Phylum into Classes is not the same across all Phyla — the split criterion is local to each branch. What is constant is the level of abstraction: Classes always represent a finer subdivision of a Phylum, and every Class belongs to exactly one Phylum.

The same principle applies here. What is constant at L2 is:

*n Area groups Sectors that share the same purpose or theme within a Domain.*

What varies is the type of theme: in products/ it is the audience model; in services/, engines/, and infra/ it is the functional domain; in meta/ it is the artifact type. This variation is expected and acceptable — it does not break the taxonomy.

---

3. Why each Domain has its current Areas

3.1 products/ — split by audience model

The three Areas inside products/ are distinguished by who the end user is and how the product reaches them:

*ote (RFC-007):*the Area previously named suite/ was renamed to horizontal/ for symmetry with vertical/ and to make the audience-model criterion self-documenting in the directory tree. The marketing brand "Koder Suite" remains independent of this folder name. See RFC-007 for the full analysis, including why b2c/ / b2b/ / b2d/ was rejected.

*hy this criterion:*within the products Domain, all components have end users with UX. The meaningful distinction at L2 is which kind of user and *what gotomarket motion* — because these determine product design, pricing, sales channel, and regulatory exposure. A healthcare EHR (vertical/clinic) and a calendar app (horizontal/cal) are both products consumed by direct interaction, but they require fundamentally different strategies at every level. The audience model is the only criterion that captures this cleanly at L2.

3.2 services/ — split by functional domain

*hy this criterion:*within the services Domain, all components are consumed via API with no direct end-user UX. The meaningful distinction at L2 is *what capability the service provides* — because this determines which teams own it, which products depend on it, and how it is scaled and operated.

3.3 engines/ — split by functional domain

*hy this criterion:*within the engines Domain, all components are consumed by embedding. The meaningful distinction at L2 is *what domain of computation the engine addresses* — codec, language execution, or API client abstraction.

3.4 infra/ — split by infrastructure function

*hy this criterion:*within the infra Domain, all components are consumed by operation (deploy and configure). The meaningful distinction at L2 is *what infrastructure function the components perform* — because this maps directly to operational ownership, failure domains, and scaling characteristics.

3.5 meta/ — split by artifact type

*hy this criterion:*within the meta Domain, all components are consumed by reading. The meaningful distinction at L2 is what type of artifact it is — because this determines who produces it, who reads it, and how it is maintained.

---

4. Formal definition

*rea (L2):*a directory inside a Domain that groups Sectors sharing the same purpose or theme. The grouping criterion is local to each Domain:

• In products/: audience model (B2C horizontal, B2B vertical, B2D)
• In services/ and engines/: functional domain
• In infra/: infrastructure function
• In meta/: artifact type

Every Sector belongs to exactly one Area. Every Area belongs to exactly one Domain.

---

5. Rules for creating new Areas

A new Area should be created when:

1. A set of Sectors shares a purpose distinct enough from existing Areas to warrant

   its own grouping, AND

2. That purpose cannot be captured by adding a Sector to an existing Area, AND
3. At least two Sectors already exist (or are firmly planned) that would populate it

*o not*create an Area for a single Sector — the Sector can live directly under the Domain until a second related Sector emerges.

*xample:*if a new type of engine (e.g., a cryptography engine) is added to engines/, it becomes engines/crypto/ — a new Area — only if it has multiple Sectors under it (engines/crypto/krypt/, engines/crypto/tls/, etc.). A single component goes directly at the appropriate level without a new Area wrapper.

---

6. Relationship to previous vocabulary

Before RFC003 and RFC004, "Area" referred to the current L1 directories (e.g., suite/, ai/, infra/). With the introduction of Domains at L1, "Area" shifts to L2. The table below shows the mapping: