> ## Documentation Index > Fetch the complete documentation index at: https://labs.laer.ai/llms.txt > Use this file to discover all available pages before exploring further. # Entity Labeling > >- How Entity Labeling turns person and organization tags into privilege decisions, which entities it puts in front of a reviewer, and how it detects names that are one entity spelled two ways. Entity Labeling settles what each participant in your data **is** — attorney, client counsel, opposing party, third party, and so on. The Privilege Classification step that follows settles what being that thing **does** to the documents they appear on. The step runs after Name Normalization, so it works on consolidated entities: one row per unique person and organization, rather than one row per email address. The page has three tabs, plus its own Metrics view: | Tab | What it shows | | ---------------- | ------------------------------------------------------------------------------- | | **Person** | Every consolidated person (Actor), with predicted and accepted tags | | **Organization** | Every consolidated organization (Domain), with predicted and accepted tags | | **Review** | The entities worth a reviewer's attention, plus names that look like one entity | Predicted tags come from the run. Accepted tags come from you. Wherever an entity has both, **your tags win** — the two are not merged, so removing a predicted tag is a decision the pipeline honors rather than something it puts back. *** ### Privilege rules: conferring and breaking Tags on their own do not decide privilege. The **Privilege rules** panel is where you say what each tag does when someone carrying it is on a document. Open it from the **Privilege rules** button in the top right of the Entity Labeling page. Every person and organization tag in the workflow gets one of three settings: | Setting | Meaning | | ----------- | --------------------------------------------------------------------------------------- | | **Confers** | A message with this entity on it is treated as privileged | | **Breaks** | A message with this entity on it is treated as not privileged | | **None** | The tag is still shown to the model as context, but does not decide privilege by itself | A typical setup marks **Attorney**, **Client Counsel**, **Legal Staff**, **Client Law Firm**, and **Client** as conferring, and **Third Party** and **Opposing Party** as breaking. #### Breaking wins If a message has both a conferring and a breaking participant, the message is **not privileged**. One participant outside the privileged relationship decides the message, whatever else is on it, and however many conferring entities are present. This precedence is applied identically everywhere downstream — in thread propagation, in the classification prompt, in the second pass, and in the privilege log — so a rule you set here reads the same way at every later step. #### How rules carry through a thread Privilege rules do not stop at the single message. Within an email thread, the workflow applies them as a light switch, working from the oldest message forward: * When a **conferring** entity is introduced, that message and every later message in the thread are treated as privileged. * When a **breaking** entity is introduced, the run is switched off, and every **earlier** message in the thread is marked not privileged as well — the thread has been forwarded outside the relationship. * Attachments and other family members inherit the same conservative precedence: a breaking parent or thread wins, then a conferring parent or thread, and otherwise the thread's own result stands. Conferring tags do one extra thing that breaking tags do not: entities holding a conferring tag also become search terms against document text, so an attorney named in the body of a document can be found even when they are not on the metadata. A breaking party mentioned in a body does not break privilege — being *on* the document is what does that, and metadata already covers it. #### What the rules cannot change Some behavior is fixed by the classifier and is not editable in the panel: * A third party outside the client–attorney relationship breaks privilege unless they are necessary to give the advice. * Only client-side and internal attorneys are counted as attorneys. * A tag outside the counsel and party vocabulary never reaches the model, however you set it in the panel. #### The Effect column The Person, Organization, and Review tables all carry an **Effect** column immediately after **Tags**. It reads that row's effective tags through your current rules and shows **Confers**, **Breaks**, or **No effect**. It is blank when the workflow has no rules yet or the entity has no tags. The Effect column updates as soon as you save rules. Document-level privilege calls do not — those were decided by the last Privilege Classification run. Re-run Privilege Classification after changing rules if you want the documents to reflect them. *** ### The Review tab: top entities for human review Entity Labeling typically leaves thousands of entities behind, most of them appearing on a handful of documents. Reviewing that list alphabetically spends the day on names that change nothing. The **Review** tab ranks it instead, so the entities that move the most documents come first. #### What goes into the queue | In the queue | Not in the queue | | -------------------------------------------------------------------- | ------------------------------------------------------------------------- | | Entities the run proposed a tag for that you have not accepted yet | Entities you have already accepted, changed, or otherwise ruled on | | Both persons and organizations, ranked together | Entities appearing on fewer documents than everything already listed | | Entities the run settled nothing for, listed with a **Label** action | Nothing else — an unlabeled entity is still a decision waiting to be made | The queue is drawn from the busiest entities on each side, merged, re-ranked by document count, and capped at the top 50. A line under the table tells you exactly how many entities were ranked and how many the workflow holds in total, so you can see what the ranking did and did not look at. #### Columns | Column | What it shows | | ---------------- | ------------------------------------------------------------------------------------------------------------------ | | **Entity** | Name and identifying context — organization or address for a person, domain for an organization | | **Proposed tag** | What the run predicted for this entity | | **Effect** | What accepting that tag would do to privilege, under your current rules | | **Documents** | How many documents the entity appears on | | **Actions** | **Accept** to write the proposed tag, **Change** to open the entity record, or **Label** when nothing was proposed | #### Why organizations are worth doing first An organization's tag is reusable in a way a person's is not: accepting it settles the people the run could not place individually, and any who arrive in a later load. A person's tag settles exactly that person. Where an organization has people associated with it, the queue says so under its name — for example, **tags 128 people with it**. Select that link, or the **Tag 128 people** button that appears after you accept, to open the members drawer, where you can hand the organization's tags down to its people in bulk or tag them individually. A row you have just accepted stays in the queue until you leave the tab, marked **Tagged**, so that its tag can still be handed down. Everything else drops out of the queue as soon as it carries a decided tag. #### How the ranking works Entities are ordered by the volume of documents a decision on them moves. Beyond raw document count, the ranking applies a few adjustments: * An organization is worth more than its own document count alone, because its tag propagates to the people it settles. * An entity the run left undecided ranks above one that already carries a tag — that one is a spot check rather than an open decision. * Shared mail providers (gmail.com and similar) are pushed to the bottom. Tagging one is worse than leaving it alone, since the tag would reach every unrelated person who happens to use that provider. They stay visible only so you can see why a large entity is missing from the top. *** ### Similar name clusters Above the queue, the Review tab surfaces groups of names that look like one entity recorded more than once — **"J. Robert Oppenheimer"** and **"Robert Oppenheimer"**, or **"Doe, Jane"** and **"Jane Doe"**. This is the other half of the same problem the queue solves. One person spelled two ways carries two rows, each deciding its own documents, and no amount of per-entity review surfaces it. #### What is detected * Names are compared within a type only. A person never clusters with an organization — a firm named after its founder is not that person. * Two names group together when they are highly similar, allowing for reversed name order, so `Doe, Jane` matches `Jane Doe`. * Person clusters are additionally checked against first name, last name, and nickname conventions, which is what separates **Jon Smith / John Smith** from **John Smith / John Smyth-Jones**. * Only entities appearing on **2 or more documents** are compared. A name seen once is usually a one-off spelling nobody merges, and leaving those out is what keeps the comparison fast on a large workflow. The count of entities actually compared is shown under the list. #### Tag conflicts come first A cluster whose members carry **different tags** is a defect, not a suggestion — one entity spelled two ways and tagged two ways has been deciding privilege both ways. Those clusters are listed first, with a warning icon, under a heading that counts them, for example **3 names are tagged two ways**. Remaining clusters are merge suggestions and sit behind **Show more clusters**. When nothing disagrees, the suggestions become the list. Select any name in a cluster to open its entity record and correct or align its tags. *** ### Suggested order of work 1. Set your **Privilege rules** first, so the Effect column is meaningful while you review. A decision is much easier to make when you can see that accepting it will confer or break privilege. 2. Clear the **tag conflicts** in the name clusters. These are errors, and they are cheap to fix. 3. Work the **Review** queue from the top, taking organizations as they come and handing their tags down to their people. 4. Spot-check the **Person** and **Organization** tabs for the roles that matter most to the matter — attorney and client counsel identifications, and client versus opposing party. 5. Re-run **Privilege Classification** so document-level calls reflect your corrections. For bulk corrections, export from the Person or Organization tab, correct the file, and import it back rather than editing row by row.