RFC007 — L2 AudienceModel Nomenclature: suite/ becomes horizontal/

1. Summary

Rename the L2 Area products/suite/ to products/horizontal/, completing the symmetry of the audience-model criterion in the products/ Domain. After this RFC, the three Areas inside products/ are:

products/
├── horizontal/      ← any user, any industry (B2C horizontal)
├── vertical/        ← industry specialist (B2B vertical)
└── dev/             ← developer / technical operator (B2D)

This RFC also documents the analysis of an alternative naming proposal — using b2c/, b2b/, b2d/ directly — and the reasons that proposal was rejected. The analysis is preserved here so that future reviewers (human or AI) can audit the reasoning behind the rename.

2. Problem

RFC004 §3.1 named the audiencemodel criterion explicitly: the three Areas inside products/ are split by *ow the product reaches its audience*— B2C horizontal, B2B vertical, B2D. But the folder names did not reflect this consistently:

The asymmetry is small but real: a reader scanning products/ saw two category names (vertical/, dev/) and one product-family name (suite/). The criterion of L2 (audience model) was clear inside RFC-004 but invisible in the directory tree itself.

3. Proposed alternatives

Two alternative naming schemes were analyzed before settling on the rename.

3.1 Alternative A — horizontal/, vertical/, dev/ (chosen)

Rename suite/ to horizontal/. The full L2 of products/ becomes symmetric and self-documenting: the folder name is the criterion.

*ros:*

1. *ymmetry.*horizontal/ ↔ vertical/ is a canonical pair in SaaS

   vocabulary.

2. *elfdocumentation.*The folder name is the audiencemodel criterion;

   no need to consult the RFC to understand the split.

3. *o collision.*No other folder in the monorepo uses "horizontal".
4. *oherence with RFC-004.*The spec already uses "B2C horizontal" as

   the descriptor for this Area.

5. *educes marketing baggage.*The marketing brand "Koder Suite" (if

   adopted) is independent of the folder name and can live at the marketing layer (landing pages, product family naming) without dictating the directory taxonomy.

*ons:*

1. *igration cost.*All references to suite/ in docs, READMEs, landing

   pages, and CI pipelines must be updated. Mitigated by the fact that the RFC-003 migration (suite/ → products/suite/) is already pending and not yet executed; the rename to horizontal/ can be folded into the same sweep.

2. *oss of the "trio identity"*suite/, vertical/, dev/ formed a

   recognizable internal triplet. The new triplet horizontal/, vertical/, dev/ is equally cohesive but visibly different.

3.2 Alternative B — b2c/, b2b/, b2d/ (rejected)

Use the customer-relationship vocabulary directly as folder names. The L2 of products/ becomes b2c/, b2b/, b2d/.

*ros:*

1. *anonical commercial vocabulary.*B2CB2BB2D is universal in SaaS;

   any market reader recognizes it instantly.

2. *isual symmetry.*All three share the b2* prefix, marking them as

   a set.

3. *elf-documenting if the criterion is "customer relationship".*The

   folder names directly match the criterion vocabulary.

4. *oncise.*Three lowercase characters per name.

*ons (decisive):*

1. *ixes two orthogonal axes.*B2C/B2B describes the *customer

   relationship* axis; horizontal/vertical describes the industry scope axis. They are independent — a product can be any combination:

Forcing b2c/ to mean "horizontal" silently collapses the two axes. A B2B horizontal product (Koder's Slack-killer) would have no clean home; placing it under b2b/ would mix it with B2B vertical products that have completely different sales motion and regulatory exposure.

2. *ngine + product pairs already handle B2C/B2B at L4.*The

   engine + product pattern (RFC002 / `engineproduct-pattern.md) places the consumer product and its B2B brand variant inside the **same Sector**: kmail (B2C webmail) and kmailraven` (B2B engine). The B2CB2B duality is solved at L4, not at L2. Using b2c/ at L2 creates redundancy and forces an arbitrary primary classification ("Is Kmail a B2C product or a B2B product?" — it's both, by design).

3. *ndustry scope is more stable than customer relationship.*A product

   rarely migrates from horizontal to vertical (the audience never widens like that), but it commonly grows a B2B variant alongside a B2C original (Kmail → +Raven). Using horizontal/vertical at L2 means the folder classification doesn't change as the product matures.

4. *ocks the taxonomy into commercial framing.*B2CB2BB2D is sales

   vocabulary — it presupposes a paying customer. Free/open-source products, internal tools, and friendsandfamily products don't fit cleanly. The monorepo taxonomy should describe what the products are, not *how they are sold*.

5. *2D is the least canonical.*B2C and B2B are universal; B2D is used

   but inconsistently (some say "developer-focused", "devtools", "B2D"). Using b2d/ adopts a less-stable convention.

6. *cronyms compromise readability.*products/b2c/kmail/ reads like a

   spreadsheet code; products/horizontal/kmail/ reads like a semantic path.

7. *iolates the Linnaean rule of single criterion per level.*If L2's

   criterion is "audience model", and audience model has two orthogonal axes, B2X picks one axis and silently discards the other. Industry scope becomes invisible metadata. This degrades the taxonomy's expressive power.

3.3 Alternative C — Hybrid (rejected)

A hypothetical hybrid would mix axes: horizontal/, vertical/, dev/, plus b2c/ for non-categorizable products. This was rejected on principle: the Linnaean rule (single criterion per level) is non-negotiable, and the hybrid degenerates into "everything that didn't fit elsewhere goes into b2c/", which is the worst of both worlds.

4. Decision

*dopt Alternative A.*The L2 of products/ is named:

products/
├── horizontal/      ← B2C horizontal — any user, any industry
├── vertical/        ← B2B vertical — industry specialist
└── dev/             ← B2D — developer / technical operator

The criterion documented in RFC-004 §3.1 is preserved verbatim. Only the folder name suite/ changes to horizontal/.

Why dev/ remains a third category

dev/ is not strictly horizontal or vertical — developers are an audience type that cuts across industry. The third folder reflects this: B2D is its own audience model, qualitatively distinct from B2C horizontal (who needs no technical context) and B2B vertical (who is identified by industry, not by technical role). Forcing dev/ into a binary horizontal/vertical split would break the audience-model criterion.

Why the engine + product pattern is unaffected

The engine + product pattern (RFC-002) handles the B2C/B2B duality *nside each Sector*through L4 brand variants. This RFC's rename has no impact on that pattern: the consumer Kmail product remains at products/horizontal/kmail/ (post-migration), and the Raven engine remains at products/horizontal/kmail/raven/. The B2C/B2B information is fully preserved in the L4 layer.

5. Migration

5.1 Path renames

This rename can be executed in the same sweep as the RFC-003 migration (L1 Domain restructure), avoiding a separate disruption.

5.2 References to update

• docs/stack/areas.md — replace "Suite" / suite/ with "Horizontal" /

  horizontal/ where the term refers to the L2 Area, preserving the marketing brand "Koder Suite" if it is adopted at the product-family level.

• docs/stack/vocabulary.md — update the Area entry to use horizontal/.
• docs/stack/engine-product-pattern.md — update path examples.
• docs/stack/rfcs/monorepo-RFC-003-l1-domain-taxonomy.md — §5.1 and §8

  references (handled as an addendum below).

• docs/stack/rfcs/monorepo-RFC-004-l2-area-definition.md — §3.1 table and

  prose (handled as an addendum below).

• Landing pages: any site explicitly referencing suite/ paths.
• Tooling: /k-housekeep, /k-parity, and any script that walks

  products/<area>/ should pick up horizontal/ automatically because the walk is structural, not name-keyed.

5.3 Brand independence

The marketing brand *oder Suite*— if used to bundle the horizontal products commercially (analogous to Microsoft Office or Google Workspace) — is independent of this RFC. The folder rename does not require dropping the brand name; the brand can live at the marketing layer:

• Landing page: meta/sites/areas/horizontal/ may still serve a site that

  brands the offering as "Koder Suite".

• Product family naming: a sales sheet may say "Get the Koder Suite"

  meaning all products in products/horizontal/.

• App naming: individual apps retain their own brands (Kmail, Cal, Drive)

  regardless of folder name.

The folder name is internal taxonomy, not customer-facing copy.

6. Addenda to prior RFCs

6.1 Addendum to RFC-003

In monorepo-RFC-003-l1-domain-taxonomy.md §5.1 and §8, all references to suite/ as the L2 Area inside products/ are superseded by horizontal/ per this RFC. The Domain (products/), criterion (form of consumption), and structural placement are unchanged.

6.2 Addendum to RFC-004

In monorepo-RFC-004-l2-area-definition.md §3.1, the table row for suite/ is read as horizontal/ per this RFC. The audience-model criterion and prose explanation are unchanged.

7. Future-proofing

If a future product appears that is *2B horizontal*(a Koder-built Slackkiller or Notionkiller for enterprise teams across industries), it belongs in products/horizontal/ because its industry scope is horizontal. Its B2B/enterprise dimension is captured at L4 through:

• A <brand>/ variant for the enterprise edition (if it has a separate

  brand).

• An app/web/ admin console distinct from the consumer experience.
• Pricing/distribution channel handled by the engine + product pattern.

If the Stack ever decides to track B2C/B2B explicitly per product, that information should live as *etadata in koder.toml* not as a folder split. Example:

[product]
audience = ["b2c", "b2b"]   # Kmail serves both
industry_scope = "horizontal"

This keeps the orthogonal axes orthogonal and queryable, without polluting the directory taxonomy.

8. Acknowledgement

This RFC was triggered by the question, *"shouldn't vertical/ have a counterpart called horizontal/?"* The question exposed a small but real asymmetry in the L2 naming. The follow-up question, *"why not B2CB2BB2D directly?"*, exposed the deeper orthogonality between industry scope and customer relationship and led to the analysis preserved in §3. Both questions are characteristic of the iterative-clarification process by which the L1–L4 taxonomy was developed (RFCs 003 → 004 → 005 → 006 → 007).