> ## Documentation Index > Fetch the complete documentation index at: https://docs.experio.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Implementation Playbook > When a deployment needs a workshop, which business rules to capture, and which admin page each rule belongs on ## Overview Use this page before the [Onboarding Checklist](/admin-guide/onboarding-checklist). The checklist is the click path through a new deployment. This page says when that step needs a workshop, the business rule you should leave with, and the admin page where the rule is entered. Work the decisions in the order below. A mapping written before the ontology exists has to be rebuilt. Taxonomies and artifact types come before mapping because a column only means something once you know the entity it becomes and the documents you expect. A workshop is for a decision Experio cannot read out of a file: what exists, which links are legal, which lists the firm already uses, which documents matter, which columns become which entities, which rules are true but unwritten, and when two records are the same thing. Connecting storage, watching a job, and checking startup health come after those rules are agreed. ## Decision order | Decision | Workshop when | Business rule to capture | Admin place | | - | - | - | - | | Who the firm is | The legal name and aliases are unsettled | Canonical name, synonyms, branding | [Client Configuration](/admin-guide/client-configuration) — Administer | | What exists in the graph | Entity types or legal links are not agreed | Node types, and which relationships are allowed | [Ontology](/admin-guide/ontology) — Model & Define | | How work is classified | The firm already has controlled lists | Hierarchical vocabularies used for tagging | [Taxonomies](/admin-guide/taxonomies) — Model & Define | | What documents mean | Document families are not defined | Which files to extract, and which fields come out | [Artifact Types](/admin-guide/content-types) — Model & Define | | How tables become the graph | Source columns are ambiguous | Each field mapped to an entity or relationship | [Data Mapping](/admin-guide/data-mapping) — Model & Define | | Rules the documents do not state | Inferences must be applied after ingest | Prompts that add attributes, nodes, or links | [Enrichment Rules](/admin-guide/enrichment-rules) — Model & Define | | When two records are the same | Identity rules differ by source | Match, AI-review, and human-review thresholds | [Matching Strategies](/admin-guide/matching-strategies) — Process | | Where the files live | The model above is agreed | Which provider, and which folders to scan | [Connectors](/admin-guide/connectors), then [Data Sources](/admin-guide/data-sources) — Connect | ## Who the firm is Run this workshop when people use several names for the same organization: a legal name, a short name, and old brand names. Leave with one canonical name and the synonyms that must resolve to it. Enter that on **Administer > Client Configuration**. The name is how the firm is recognized in the graph. Synonyms stop the same organization from being created once per spelling. ## What exists in the graph Run this workshop when the team has not agreed the objects in the business or which links between them are allowed. Typical objects are people, projects, clients, and skills. A link is a business rule: a person may work on a project, and a project may not report to another project. Leave with the entity types, the attributes each one carries, and the relationships that are legal. Enter them on **Model & Define > Ontology**. Later screens — artifact types, mappings, enrichment rules, and matching — all point at this schema. Changing it afterward marks those configs stale. Check **Model & Define > Compatibility** before ingestion. That check is an operation, not its own workshop. See [Ontology Compatibility](/admin-guide/ontology-compatibility). ## How work is classified Run this workshop when the firm already sorts work with lists: industries, service lines, contract types, or clearance levels. Leave with the list names, the parent-child nesting, and the synonyms for each term. Enter them on **Model & Define > Taxonomies**. Enrichment rules can require the model to pick from a taxonomy (`@TaxonomyName` in a prompt), so the lists need to exist before those rules are written. ## What documents mean Run this workshop when you cannot yet say which files are worth extracting. Group the corpus into families — proposals, resumes, contracts, status reports — and decide, for each family, which ontology entities and relationships should come out of it. Leave with a name, classification instructions (how to recognize the family), and the entity and relationship types to extract. Enter that on **Model & Define > Artifact Types**. Depth is part of the same decision. A large spreadsheet export often should not get full extraction. Set that on the artifact type, under **Ingestion extraction**. See [Extraction Policy](/admin-guide/extraction-policy). That is a cost rule agreed in the document workshop, not a separate meeting. ## How tables become the graph Run this workshop when a spreadsheet, export, or database has columns whose meaning is not obvious from the header. The ontology and the artifact types should already exist. A column is mapped onto an entity or relationship you have already named. Leave with one mapping per source: which fields become which nodes, which fields become attributes, and which fields become links. Enter it on **Model & Define > Data Mapping**. The [Onboarding Checklist](/admin-guide/onboarding-checklist) lists data mapping before taxonomies and artifact types. Follow this playbook for workshop order. Use the checklist when you are clicking through a deployment whose rules are already decided. ## Rules the documents do not state Run this workshop when the business applies a rule that is not written in the source file. Examples: tag a project with an industry from its description, create an obligation from a contract clause, or link an employee to skills found in a resume. Leave with the target entity, the graph data the rule may see, the instruction in plain language, and what it is allowed to write back (an attribute, a node, a relationship, or both). Enter each rule on **Model & Define > Enrichment Rules**. These run after ingestion, so they cannot stand in for a missing ontology. ## When two records are the same Run this workshop when the same person, project, or company shows up under different names across sources. The rule is different per entity type: a project code may need an exact match, while a person name may allow a fuzzy one. Leave with the default strategy and any entity-specific overrides: what counts as an automatic merge, what goes to AI review, and what a person must confirm. Enter them on **Process > Matching Strategies**. ## Where the files live Run this only after the model above is agreed. It is usually a working session with whoever administers the file store, not a modeling workshop. Authorize the provider, then name the folders to scan and how those files should be processed. Enter the authorization on **Connect > Connectors**, and the folder selection on **Connect > Data Sources**. ## After the rules are agreed These pages are operations. Open them when the workshops above are done. * **Model & Define > Compatibility** — after an ontology change, confirm artifact types, mappings, enrichment rules, and matching strategies still match the schema. Red blocks ingestion. See [Ontology Compatibility](/admin-guide/ontology-compatibility). * **Process > Conflict Resolution** — review low-confidence classifications and matches the strategies sent to a person. See [Conflict Resolution](/admin-guide/conflict-resolution). * **Process > Jobs** — watch scan and ingestion results. See [Jobs & Monitoring](/admin-guide/jobs-monitoring). * **Observe > Startup Health** — after first deploy or a graph rebuild, confirm seeds and indexes. See [Startup Health](/admin-guide/startup-health). * **Administer > Access Control** — when the firm has ethical walls or record-level visibility rules. That can be its own workshop, and it comes after the ontology exists, because the policy names entity types. See [Graph Access Control](/admin-guide/graph-access-control).