---
phase: dataModel
kind: level
level: identify
---

# Aspect — IDENTIFY entities

Discover **all entities** the current module needs, from its `use-case.md` and
`règles-métier.md` only. You do NOT ask the user which entities to keep — you
deduce them and present them for review. **Every entity needs a verbatim trace**
to ≥1 UC/BR of this module; non-traceable entities are forbidden.

## Read first (the only entity sources)

| Source | What to extract |
|--------|-----------------|
| `index.md` (module) | scope + `## Hors-périmètre` — all work is limited to this module |
| `use-case.md` | nouns in main/alternative flows + pre/postconditions → candidate entities; verbs and actors are NOT entities |
| `règles-métier.md` | the rule's target concept → entity; PascalCase tokens in the expression (skip primitives) → referenced entities |
| `entité.md` (if present) | existing entities — enrich alongside, don't duplicate |

Web search, "domain knowledge", "best practices" and analogy with other apps are
**NOT sources**. If a candidate has no verbatim trace in this module's UC/BR,
defer to `/ba-create-use-case` or `/ba-create-business-rules` — never invent.

## Deduction rules

**From use cases** — for each step of the main flow, identify the nouns (objects
acted upon) → entities; ignore verbs (rules/steps) and UI words (button, page,
dialog). Each precondition/postcondition that asserts a thing exists ("the order
exists" → Order; "the audit log has an entry" → AuditLog). A UC's primary actor
often has a domain counterpart entity (`Employee` for an EMPLOYEE actor) — model
the counterpart, not the actor.

**From business rules** — the rule's target concept is the entity it constrains;
its condition hints at which attributes matter; PascalCase tokens in its
expression name referenced entities. If a rule expression references an entity
you didn't list, add it with a trace to that rule.

**Junctions, lookups, snapshots** — admissible **only when an upstream reference
forces them**:
- N:M junction → only when a UC/BR explicitly implies the cardinality.
- Lookup (`ContractType`, `Country`) → only when a UC/BR references it. A rule
  "contract types: CDI, CDD, STAGE" forces a `ContractType` lookup; absent any
  reference, do NOT invent it.
- Historical snapshot / audit log → only when a UC/BR requires the trace.

Each is forbidden until an upstream reference exists. Surface the gap and defer.

## Scoring grid → classification (drives the `(role)` label)

Score each entity 0-3 on five criteria (total 0-15):

| Criterion | 0 | 1 | 2 | 3 |
|-----------|---|---|---|---|
| Lifecycle (states) | static | simple CRUD | CRUD + 1-3 states | full lifecycle |
| Actors (who interacts) | admin only | 1 role | 2-3 roles | 4+ / public |
| Relations (FK count) | 0-1 | 1-3 | 3-5 | 5+ |
| Volume (rows) | < 50 | 50-500 | 500-5 000 | 5 000+ |
| Autonomy | no sense alone | context-dependent | stands alone | independent domain |

| Total | Classification | Role hint for the `entité.md` heading |
|-------|----------------|----------------------------------------|
| 0-3 | `lookup` | `lookup` — admin-managed reference table |
| 4-6 | `component` | `composant` — sub-entity managed inside a parent |
| 7-10 | `lightweight-module` | own list section |
| 11-15 | `full-module` | `agrégat racine` — rich lifecycle, own section tree |

The classification drives downstream UI decisions (a `lookup` needs only an admin
page; a `full-module` deserves its own section tree).

**`technical` (special, score 0-3).** When a 0-3 entity is infrastructure — an
outbox, an integration journal, an audit-only log — rather than admin-managed
business reference data, label it `technical` (not `lookup`). It is isolated by
nature (no business relationship), so add an
`- **Isolation** : by-design — <reason>` line to its `entité.md` heading block:
that records the intent in the model and exempts it from audit DM-009. It gets
no list/admin UI by default.

**A code allocator is NEVER one of them.** A sequence/counter table handing out
reference numbers — `DemandeSequence`, `OpportunityCompteur`, a `nextValue:int`
row keyed `{tenantId, year}` — must NOT be modelled: it is a platform capability,
not client data. The socle allocates every business code atomically and
**gaplessly** at insert (`core.seq_Sequences`, UPDLOCK/SERIALIZABLE inside the
insert transaction) and exposes the pattern in **Administration → Configuration →
Code patterns**, where an admin retunes the format without a migration. Declare
the `codePattern` on the entity that CARRIES the code (see `attributes.md`
§ Code pattern) and stop there — a re-modelled allocator is flagged by DM-017 and
by the `code-generation` platform capability (C-6 / CODE-006).

## Quality checks (per entity, before proposing)

- Has a business identity (a user would refer to it by name)?
- Persistent (survives across sessions)?
- **Traceable** verbatim to ≥1 UC step / pre-postcondition or BR target /
  expression token **of this module**? *(blocking — a concept traceable only to
  ANOTHER module is not an entity here; reference it via a cross-module / core FK
  relationship instead)*
- Classification consistent with its score?
- `person` mode unambiguous (mandatory / optional / none) **and persisted as
  the `- **Personne**` line** in the entity heading block (see SKILL.md)? For a
  C-4-triggered entity the line is MANDATORY — `none` only as the explicit
  client override `none — décision client : <raison>` (DM-018c errs on silence)?
- name/alias does NOT collide with the SmartStack Core catalogue (C-1 tables
  in SKILL.md — e.g. "Organisation" duplicates Core `TenantOrganisation`/`tenant_TenantOrganisations`)?
- Description understandable by a developer with no context?

If any answer is "no" → drop the candidate or surface the gap and defer to the
upstream phase. Then move on to attributes (`./attributes.md`).