# Business Domain — Deals

> How "deal"/pipeline behavior is represented today. **There is no dedicated Deal entity.**

_Verified against the codebase on 2026-07-23._

---

## Current reality

**No `Deal` model exists in the codebase.** Deal- and pipeline-like behavior is represented indirectly through existing primitives:

| Concept | Represented by |
|---------|----------------|
| Pipeline stage | **`Group`** — each Investor/Startup belongs to one group (New, Pipeline, Pool, Archive, Rejected, …). |
| Stage transition | **`action` `LabelOption`** applied via the canonical `Startup/InvestorLabelActionService` (moves group + side effects). |
| Deal-relevant attributes | **`LabelOption` FKs** on Startup (investmentStage, roundType, offered_equity_pct, asking_fund_sar, computed `valuation`) and Investor (averageTicket, category). |
| Deal progression events | **`ActivityLog` / `EntityNote`** and notification history. |
| Investment decision | **`Committee`** evaluations (Pass/Fail per member × startup). |

So a "deal" is currently an **emergent view** over Groups + Labels + Actions + Committee outcomes, not a first-class record.

## Future domain (not decided)

A dedicated `Deal` entity (e.g. linking an investor, a startup, terms, and a lifecycle) is a **potential future domain**. It does not exist today and must not be assumed.

- Whether to introduce a `Deal` model, its fields, and its relationship to Groups/Committees: **Unknown - requires confirmation.**
- Any mapping from the current Group/Action model to a future Deal lifecycle: **Unknown - requires confirmation.**

**Do not invent a Deal entity in code or docs.** Update this file only after an explicit product decision is recorded in [`../06-history/decisions-log.md`](../06-history/decisions-log.md).