Skip to main content
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.
Northbridge Consulting is fictional. The names, figures and files are illustrative. The product behaviour described is real.

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. The pilot ran over ten weeks.

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.
  • Priya named three use cases and one SME for each.

Phase 1: Discover

WS1 Questions & Agents, run three times

Workshop 1 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: 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: “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 traced every must-have question to a source. 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 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. 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, three of the four taxonomies were imported from other systems. Only one was designed in the room.

WS5 Artifact Types

Workshop 5 defined six artifact types, plus “None” for everything else. Each was tested on 3–5 real files with Test Ingestion. 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, each export got a mapping. Auto-Map with AI drafted each one, and the team corrected the result. Relationship mappings never create their endpoints, so the load order in D-006 matters.

WS7 Identity & Matching

Workshop 7 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 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 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 scored all 45 questions twice. Each failure in round 1 was traced to one root cause and fixed: 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 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:
  • 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:
  • 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.

Implementation Roadmap

The phases and exit criteria this example follows.

Templates

The worksheets, logs and checklists used above.