> ## 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.

# Worked Example: Northbridge Consulting

> One fictional implementation from kickoff to handover, showing how every workshop output fits together

Every workshop page has a Northbridge section. This page puts them together in one place. Use it to see how a decision in one workshop shows up in the next. You can also use it as a model answer when preparing your own client's documents.

<Note>
  Northbridge Consulting is fictional. The names, figures and files are illustrative. The product behaviour described is real.
</Note>

## The client

Northbridge Consulting is a management and technology consulting firm of about 650 people, based in Chicago. It has three practices (Strategy, Technology and Operations) and serves healthcare, financial services and public sector clients.

| Person | Role in the implementation |
| - | - |
| Priya Shah, COO | Executive sponsor |
| Marcus Lee, Knowledge Manager | Super user and future owner of the configuration |
| Dana Ortiz, BD Director | SME for UC1, proposals and past performance |
| Sam Whitfield, Resource Manager | SME for UC2, staffing and expertise |
| Helen Park, Contracts Counsel | SME for UC3, contract obligations; Legal for access control |
| Raj Mehta, IT | SharePoint and Box admin; SSO |
| Laura Chen, PMO Lead | Client project manager |
| Experio FFE | Leads the implementation and is Experio's project lead |
| Experio SMEs | Data-modeling and integration specialists who joined the ontology and data-mapping workshops |

The pilot ran over ten weeks.

```mermaid theme={null}
flowchart LR
    P0["Phase 0<br/>Prepare"] --> P1["Phase 1<br/>Discover<br/>WS1 x3, WS2"]
    P1 --> P2["Phase 2<br/>Model<br/>WS3 to WS7"]
    P2 --> P3["Phase 3<br/>Pilot ingest<br/>WS8"]
    P3 --> P4["Phase 4<br/>Validate<br/>WS9"]
    P4 --> P5["Phase 5<br/>Consume<br/>WS10, UAT"]
    P5 --> P6["Phase 6<br/>Launch and hand over"]
```

## Phase 0: Prepare

* Raj requested the SharePoint connector app at contract signature. It was the longest lead-time item, and it was approved in week 2.
* The FFE created admin accounts in the staff admin. Marcus got write access on Graph, Data Source, Process and AI, read access on Monitoring, and staff status, so that he could build agent flows and templates later. See [Roles & Permissions](/implementation/roles-and-permissions).
* Priya named three use cases and one SME for each.

## Phase 1: Discover

### WS1 Questions & Agents, run three times

[Workshop 1](/implementation/ws-questions-and-agents) ran once per use case, each time with that use case's SME. The FFE and Marcus merged the three sessions into one `questions.md` of 45 golden questions. These are the anchor questions used on every page of this guide:

| ID | Use case | Question | Expected answer |
| - | - | - | - |
| Q1 | UC1 | Which cloud migration projects did we deliver for healthcare clients since 2023, and who led each? | 4 projects, including Lakeshore Health EHR Cloud Migration (`NB-2024-117`), each with its engagement lead |
| Q2 | UC1 | Draft a past-performance summary for our work with Lakeshore Health. | One page covering 3 projects, every claim cited |
| Q3 | UC1 | Which proposals did we submit to financial-services clients in 2025 and which were won? | 7 proposals, 3 won (Meridian Bank ×2, Harbor Mutual) |
| Q4 | UC2 | Who has Azure data platform experience and has worked in healthcare? | 6 named consultants |
| Q5 | UC2 | Who has worked with Meridian Bank, in what roles? | 11 people with roles |
| Q6 | UC2 | Which senior consultants in the Technology practice report to Alex Romero? | 5 names |
| Q7 | UC3 | Which SOWs expire in the next 90 days, and for which clients? | List from SOW end dates |
| Q8 | UC3 | What reporting obligations do we have under the Lakeshore Health MSA? | Monthly status report; quarterly executive review |
| Q9 | UC3 | Which contracts have a limitation-of-liability cap below \$1M? | 4 MSAs |
| Q10 | UC1 | What case studies do we have for supply chain work? | 3 case studies |
| Q11 | UC1 | How many Technology practice projects did we deliver for public-sector clients in 2025? | 9 |

Three agent candidates came out of the sessions:

* **Past-performance write-up** (UC1): a DOCX built from a template, approved by Dana.
* **Staffing shortlist** (UC2): a ranked list with reasons, reviewed by Sam.
* **Contract renewal digest** (UC3): a monthly summary, reviewed by Helen.

Marcus also captured the firm's identity for [Client Configuration](/implementation/key-concepts#client-configuration): "Northbridge Consulting", with the synonyms "Northbridge", "NBC" and "Northbridge Consulting Group".

The sponsor signed off the success criterion: **80% of must-have golden questions pass, with correct citations, by the end of week 7.**

### WS2 Data Inventory

[Workshop 2](/implementation/ws-data-inventory) traced every must-have question to a source.

| Source | System | Type | Key |
| - | - | - | - |
| Employees | Workday `employees.csv` | Structured | `employee_id`, `work_email` |
| Clients and opportunities | Salesforce `accounts.csv`, `opportunities.csv` | Structured | `account_id`, account name |
| Projects and staffing | Deltek `projects.csv`, `assignments.csv` | Structured | `project_code` (`NB-2024-117`) |
| Proposals, SOWs, MSAs, case studies, status reports | SharePoint "Engagements", one folder per client | Documents | Client folder name; project code in SOW headers |
| Resumes | SharePoint "Resumes" | Documents | Employee name in the document |

Decisions logged:

* **D-006**: load order is employees, then accounts, then projects, then assignments, then documents.
* **D-007**: Finance adds the Salesforce account name as a column in `projects.csv`, so that Project FOR\_CLIENT Client can match exactly.
* **D-008**: `manager_email` is added to `employees.csv`. It previously held the manager's name only.
* **D-009**: compensation columns are removed from the Workday export at source.

The pilot sample was the full structured exports, plus the folders `Engagements/Lakeshore Health`, `Engagements/Meridian Bank` and `Engagements/State of Illinois DHS`. Together they contain every artifact type.

## Phase 2: Model

### WS3 Ontology

[Workshop 3](/implementation/ws-ontology) started from the default ontology. The team kept Client, Employee, Project, Proposal, Contract, Skill and Obligation, renamed Division to Practice, and deleted the rest. The result has eight entity types.

```mermaid theme={null}
flowchart LR
    Employee -->|"WORKS_ON_PROJECT<br/>role, dates, hours"| Project
    Employee -->|"HAS_SKILL"| Skill
    Employee -->|"MEMBER_OF"| Practice
    Employee -->|"REPORTS_TO"| Employee
    Project -->|"FOR_CLIENT"| Client
    Project -->|"DELIVERED_BY"| Practice
    Project -->|"USED_SKILL<br/>enrichment"| Skill
    Proposal -->|"SUBMITTED_TO"| Client
    Proposal -->|"RESULTED_IN"| Project
    Contract -->|"WITH_CLIENT"| Client
    Contract -->|"GOVERNS"| Project
    Contract -->|"AMENDS"| Contract
    Contract -->|"IMPOSES"| Obligation
```

| Entity type | Key attributes | Match key | Vector index |
| - | - | - | - |
| Client | name, account\_id, industry (`@Industry`), region, synonyms (list, added in WS7) | `name` (canonical Salesforce name) | Yes |
| Project | name, project\_code, start\_date, end\_date, contract\_value, service\_line (`@ServiceLine`), description, industry (added in WS8) | `project_code` | Yes |
| Employee | name, employee\_id, email, title, level, location | `email` | Yes |
| Practice | name | `name` | No |
| Skill | name (`@Skills`), category | `name` | Yes |
| Proposal | name, submitted\_date, outcome (won / lost / pending), value | `name` | No |
| Contract | name, contract\_type (MSA / SOW / amendment), effective\_date, expiration\_date, liability\_cap | `name` | Yes |
| Obligation | name, description, obligation\_type (`@ObligationType`), due\_date, frequency | None; always created under its Contract | Optional |

Each type traces to at least one golden question. For example, Q1 needs Project, Client and Employee, the FOR\_CLIENT and WORKS\_ON\_PROJECT relationships, and the `role` attribute on WORKS\_ON\_PROJECT.

### WS4 Taxonomies

In [Workshop 4](/implementation/ws-taxonomies), three of the four taxonomies were **imported** from other systems. Only one was designed in the room.

| Taxonomy | Source | Owner | Example |
| - | - | - | - |
| Industry | Salesforce Industry picklist, exported to CSV | Sales ops | Healthcare > Providers |
| ServiceLine | Finance service-line codes | Finance | Technology > Cloud Migration |
| Skills | Workday skills library (about 180 skills) | HR | Cloud > Azure > Azure Data Platform |
| ObligationType | Designed with Helen | Legal | Reporting, Insurance, Confidentiality, Staffing, Service Levels, Data Protection |

### WS5 Artifact Types

[Workshop 5](/implementation/ws-artifact-types) defined six artifact types, plus "None" for everything else. Each was tested on 3–5 real files with **Test Ingestion**.

| Artifact type | Entities (processing type) | Extraction policy |
| - | - | - |
| Proposal | Proposal (Create or Match, Attach), Client (Create or Match) | full |
| Statement of Work | Project (**Match Only**, Attach), Client (Create or Match), Contract (Create or Match) | full, large |
| Master Services Agreement | Contract (Create or Match, Attach), Client (Create or Match), Obligation (Create Only); IMPOSES is required upstream | full, large, validation on |
| Resume | Employee (Create or Match, Attach), Skill (Create or Match) | full |
| Case Study | Project (Match Only), Client (Create or Match) | full |
| Status Report | Project (Match Only) | `metadata_and_snippet` |

Folder filters: the "Resumes" library allows only Resume. "Engagements" allows the other five.

`Contract IMPOSES Obligation` is marked required upstream. The Contract is the relationship's source, so it is resolved first, and each obligation is matched only among that contract's obligations. Contract has a vector index, which the option needs.

### WS6 Data Mapping

In [Workshop 6](/implementation/ws-data-mapping), each export got a mapping. **Auto-Map with AI** drafted each one, and the team corrected the result.

| File | Creates or updates | Relationships |
| - | - | - |
| `employees.csv` | Employee (create-or-match on `email`), Practice | REPORTS\_TO (by `manager_email`), MEMBER\_OF |
| `accounts.csv` | Client (create-or-match on `name`), with `account_id`, `industry` and `synonyms` (from the `aliases` column) | |
| `projects.csv` | Project (create-or-match on `project_code`) | FOR\_CLIENT (by account name, D-007), DELIVERED\_BY |
| `assignments.csv` | | WORKS\_ON\_PROJECT {role, start_date, end_date, hours}, found by email and project code |
| `legal_coverage.csv` (added in WS9) | | COUNSEL\_FOR, found by email and client name |

Relationship mappings never create their endpoints, so the load order in D-006 matters.

### WS7 Identity & Matching

[Workshop 7](/implementation/ws-identity-and-matching) set matching per entity type:

* **Default:** Exact + Vector Similarity; thresholds 0.9 / 0.7 / 0.5.
* **Client:** Exact + Fuzzy + Synonym, with company suffixes removed. "Lakeshore Health, Inc." matches "Lakeshore Health". To make Synonym work, a `synonyms` list attribute was added to Client and loaded from Salesforce aliases such as "LSH".
* **Employee:** Exact + Fuzzy + Phonetic, with the human-review band kept. Resumes say "Bob Chen"; HR says "Robert Chen".
* **Project:** documents are set to Match Only (**D-012**), so a status report can never create a project that Finance doesn't know about.

Compatibility showed no invalid items at the end of Phase 2.

## Phase 3: Pilot ingest

[Pilot Ingestion](/implementation/pilot-ingestion) ran over two weeks.

1. **Master data.** 652 rows in `employees.csv` produced 652 Employee nodes. `assignments.csv` created only 1,890 of 2,140 relationships, because 250 rows had uppercase emails. The export was fixed and the rerun was complete.
2. **Documents.** 240 files from the three pilot folders plus 40 resumes.
3. **Reviews.** There were 31 classification reviews, mostly SOW amendments scoring 0.6–0.7, and 18 match reviews ("LSH", "Bob Chen").
4. **Tuning.** A classification instruction for amendments, plus the "LSH" synonym, brought the classification reviews down to 4 after requeueing. Graph Evaluation flagged liability caps written in words, which was fixed with an extraction instruction on `liability_cap`. Each change went into the tuning log.

### WS8 Enrichment Rules

With real data loaded, Q1 and Q4 were returning partial answers: projects had no industry, and skills lived only on people. [Workshop 8](/implementation/ws-enrichment-rules) produced:

* **Rule 1, Tag project industry.** Reads `{related.Client.industry}` and the project description, and writes a new `Project.industry` attribute, chosen from `@Industry`.
* **Rule 2, Infer skills used.** Reads the project description and SOW scope, and writes Project USED\_SKILL Skill, chosen from `@Skills`. The relationship only links to Skill nodes that already exist.
* **Rule 3, Obligation due soon flag.** Not adopted. Chat can compute "due in the next 90 days" from `due_date`, so a stored flag would only go stale.

## Phase 4: Validate

[Accuracy Validation](/implementation/accuracy-validation) scored all 45 questions twice.

| Round | Pass | Partial | Fail | Pass rate |
| - | - | - | - | - |
| 1 | 28 | 9 | 8 | 62% |
| 2 | 38 | 5 | 2 | **84%** |

Each failure in round 1 was traced to one root cause and fixed:

| Question | Result | Root cause | Fix |
| - | - | - | - |
| Q1 | Partial: every team member listed as a lead | Retrieval | Cypher instruction: "Engagement lead = WORKS\_ON\_PROJECT role 'Engagement Lead'" |
| Q4 | Fail: resume people didn't meet HR people | Matching | Phonetic matching for Employee, cleared match reviews, reprocessed resumes |
| Q7 | Fail: amendments misclassified | Classification | Amendment instruction on the SOW artifact type |
| Q9 | Fail: caps in words not extracted | Extraction | `liability_cap` extraction instruction, MSAs requeued from Ingest |

Round 2 met the 80% criterion. The two remaining fails needed `opportunities.csv`, which wasn't loaded yet, and Priya accepted them as a known gap.

### WS9 Access Control

[Workshop 9](/implementation/ws-access-control) was needed because contracts are confidential.

* Contracts are private: visible to the project team (through WORKS\_ON\_PROJECT) and to Legal. Clients, Projects and Employees are public read.
* Helen's team is never staffed on projects, so the ontology gained **Employee COUNSEL\_FOR → Client**, loaded from `legal_coverage.csv`.
* The policy ran in shadow mode first. Diagnostics showed that Sales users would lose Q8's citations in enforce mode. Helen confirmed that was intended, and Q8 was re-scoped to Legal users.

## Phase 5: Consume

In [Workshop 10](/implementation/ws-assistants-and-flows):

* **Assistant** "Northbridge Knowledge", with AI Instructions naming the practices and the house style, and the engagement-lead Cypher instruction from Phase 4.
* **Document template** "Past Performance (DOCX)", in the Case Study category.
* **Agent flow** "Staffing shortlist": inputs role, skills and client; a knowledge-graph data block; an LLM ranking step; a human review by Sam; a DOCX output.

Eight pilot users (three from BD, three from Resourcing, two from Legal) ran acceptance for two weeks. Their one real finding was that past-performance answers ignored case studies older than 2021, which was caused by a pilot folder filter. It was widened for the full load.

## Phase 6: Launch & hand over

[Go-Live & Handover](/implementation/go-live):

* **Full ingestion** in batches: the structured exports first, then the Engagements library (about 9,400 files), then Resumes (650), then status reports on `metadata_and_snippet`. The Engagements batch produced 140 match reviews for client name variants, and Marcus cleared them in two days.
* **Waves**: pilot users and their teams (60 people), then all of BD, Resourcing and Legal (180), then the whole firm (650) after Priya's approval.
* **Access control** switched from shadow to enforce before wave 1, after Helen signed off.
* **Handover.** Marcus owns the taxonomies, the review queues and assistant changes. His first change on his own added `renewal_notice_days` to Contract for Helen. He saved the ontology, reviewed the stale MSA artifact type on Compatibility, added an extraction instruction, requeued the MSAs from Ingest, and re-ran Q7 and Q8.

## What made it work

* **Questions first.** Every entity type, taxonomy and rule traces back to a golden question, so scope stayed at eight entity types.
* **Tables before documents.** Clean master data with stable keys meant that document mentions matched existing records instead of creating duplicates.
* **Imported taxonomies.** Industry, service lines and skills came from the systems that already owned them, with named owners for refreshes.
* **One root cause per failure.** Fixing the first break in the chain, then reprocessing, moved the pass rate from 62% to 84% in one round.
* **The super user did the work.** Marcus entered changes from Phase 2 on, so handover was a formality.

## Related

<CardGroup cols={2}>
  <Card title="Implementation Roadmap" icon="map" href="/implementation/roadmap">
    The phases and exit criteria this example follows.
  </Card>

  <Card title="Templates" icon="clipboard-list" href="/implementation/templates">
    The worksheets, logs and checklists used above.
  </Card>
</CardGroup>