RFC-005 — L3 Sector Definition: the unit of product/service identity

---

1. Summary

Define *ector*as the L3 level of the monorepo taxonomy: the unit of *roduct or service identity*within an Area. A Sector is the first level in the tree that has tangible existence outside the source code — it has a proper name, a backlog, an owner, end users, a DNS domain, an icon. A customer contracts a Sector, not a Domain or an Area.

---

2. Why this criterion

Each level of the taxonomy answers a different question:

The split criterion at L3 is *dentity of product/service* a Sector is what, if it had to be named in the market, would not share that name with anything else inside the same Area. This is the first level where a brand, a customer relationship, or an SLA exists.

---

3. Formal definition

*ector (L3):*a directory inside an Area that represents a single unit of product or service identity, characterized by:

1. * proper name*— distinct from any other Sector in the same Area.
2. *n independent lifecycle*— it can be launched, paused, or discontinued

   without forcing the same outcome on sibling Sectors.

3. *t least one form of distribution (L4)*— concrete or firmly planned

   (backend service, mobile app, desktop app, CLI, library, landing page).

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

---

4. Examples

The following confirm the criterion across all five Domains:

---

5. Edge cases

5.1 Can a Sector contain a single component?

*es.*services/ai/gateway/ is a Sector with only one deployable component (the gateway server), but it has autonomous identity — its own name, SLA, endpoint, and customer-facing role. The minimum is identity, not plurality.

5.2 What separates two Sectors in the same Area?

You could not merge them without creating identity confusion in the market. suite/kmail/ and suite/cal/ do completely different things; merging them would force one product to inherit the other's name, breaking the brand.

By contrast, suite/kmail/raven/ and suite/kmail/backend/ (under the future L4 split) are *he same Sector*— both are the email product, just packaged differently for different audiences (B2B engine vs. B2C webmail). They share identity at the Sector level; the split between them is L4 (distribution form).

5.3 Engine + Product pairs and Sector boundaries

In the engine + product pattern (see engine-product-pattern.md), the engine and the product share a Sector when they target the same market problem with two distribution forms (B2B engine + B2C product). The Sector takes the *onsumer product's*name, and the engine sits inside as a brand sub-folder.

When the consumer product has not been built yet but the engine has shipped (e.g., observe/wire, observe/apm), the engine name is the Sector name until a flagship product splits off and inherits the consumer relationship.

5.4 What is *ot*a Sector?

• A *eature*of an existing Sector (e.g., "dark mode in Kmail") — this lives

  in the Sector's backlog or source code, never as a sibling directory.

• A *istribution form*of an existing Sector (mobile app, desktop app, CLI,

  backend) — this is L4, inside the Sector.

• A *rand sub-name*of an engine + product pair — the brand sits inside its

  Sector as a sub-folder, not as its own Sector.

• A *hared library*that exists only to be reused by other Sectors in the

  same Area — this lives at the Area level (<area>/lib/) or under the primary consumer Sector.

---

6. Rules for creating a new Sector

A new Sector should be created when:

1. The product/service has (or will have) a *roper market name* distinct

   from every existing Sector in the Area, *ND*

2. It has an *ndependent lifecycle*— its launch, pause, or discontinuation

   can be decided without entangling sibling Sectors, *ND*

3. It has *t least one concrete or firmly planned distribution form (L4)*—

   a backend service, an app, a CLI, a library, or a landing page.

*o not*create a Sector for a feature, an experiment, or a subcomponent of another Sector. Those belong inside the existing Sector at L4 or below.

*ingle-Sector Areas are valid*— when an Area has only one Sector and the two share a name (e.g., engines/kodec/kodec/, meta/docs/stack/), the nesting is intentional: it preserves the level invariant (every Sector is inside an Area) and leaves room for the Area to grow without restructuring.

---

7. Vocabulary impact

Before RFC003 / RFC004 / RFC-005, "Sector" referred to L2 directories. With the introduction of Domains at L1 and the redefinition of Areas at L2, Sector shifts to L3. The full mapping is now:

vocabulary.md is updated separately to reflect the formal definition of Sector (L3). Existing references to "Sector" as L2 in older documents are historical and should be migrated when those documents are revised.

---

8. Relationship to L4

Sectors are heterogeneous in their internal structure: a B2C consumer product typically has backend/, app/mobile/, app/desktop/, app/tv/, site/; a B2B engine has backend/, <brand>/, site/; an embeddable engine has <brand>/ and language-specific subfolders; a documentation Sector has only markdown files. RFC-006 will define L4 (distribution form) as the next level and codify which sub-folders are valid inside each kind of Sector.

This RFC does *ot*mandate a uniform internal layout for Sectors — that is deliberately deferred to L4. What this RFC mandates is the boundary: every component lives inside exactly one Sector, and every Sector has identity in the sense defined in §3.