Go-Live & Handover

Go-live turns a validated pilot into a service the client runs. That happens in two phases. In Phase 5 pilot users accept the assistants and agent flows. In Phase 6 the full corpus is ingested, users are rolled out in waves, and ownership passes to the client’s super user. The model you built is only as good as the team that maintains it, so treat the handover as a deliverable, not a farewell meeting.

​

At a glance

​

Step 1: User acceptance with pilot users

Pick 5–10 pilot users across the use cases, including at least one sceptic. Give them two weeks of real work, not a scripted demo.

1. Brief them on what’s in scope (which libraries, which date range) and what isn’t yet loaded.
2. Ask each user to try at least five of their own real questions, plus two golden questions from their use case.
3. Collect feedback in one place: the question, the answer, whether it was useful, and whether the citations were right.
4. Triage the feedback with the root-cause decision tree. Fix the cheap items before rollout, and log the rest.
5. Hold a go/no-go meeting with the sponsor. Acceptance means “useful and trustworthy for the scoped use cases”, not “perfect”.

​

Step 2: Full-corpus ingestion plan

Do not start one giant scan. Batch by library (or by data source), watch each batch, and keep an eye on cost.

• Monitor. Watch each job in Process > Jobs for failed and skipped files. Watch Process > Conflict Resolution, because a new library often brings new name variants. Scale workers if needed (Observe > Scaling, see Service Scaling).
• Cost. Multiply the pilot’s cost per document by the file count of each batch before you start it. Confirm the extraction policy for each artifact type. The cost guard downgrades very large files to metadata-only. That saves money but can hide a large contract, so check the skipped and downgraded list.
• Automate. Once the full load is done, switch the recurring load to the flow built in the pilot: structured scans, then an Incremental Scan of the documents, then enrichment rules. Put it on a schedule.

​

Step 3: Rollout waves

Before each wave, confirm that users exist with the right roles (Administer > User Profile Management, or SSO). If access control is used, confirm it is in enforce mode and that it was tested with Preview as user for a sample of the new wave.

​

Step 4: User training

Keep it short and task-based: 45 minutes per use-case group, built around that group’s golden questions. Point users to the user guide rather than writing new material: Teach every user one habit: check the citation before you reuse an answer.

​

Step 5: Support model and hypercare

Agree who handles what before wave 1. Hypercare lasts two weeks after wave 1. During hypercare:

• The FFE and super user hold a daily 15-minute check: new issues, conflict queue size, failed files, usage.
• Wrong-answer reports get a root cause within one working day.
• Observe > Usage Statistics shows messages and conversations over time. Use it to spot teams that aren’t adopting.
• Observe > Logs and Process > Jobs are checked daily for failures.

​

Step 6: Handover to the super user

​

What the client owns

​

What Experio owns

• Platform operation, upgrades, backups and uptime
• Model provider configuration and model upgrades (in agreement with the client)
• New connector types and product defects
• Agent flows and document templates, unless the super user has staff access and has been trained
• Level 2 and 3 support as agreed in the contract

​

Handover pack

Hand over the ontology diagram, the data inventory with load order and key formats, the artifact type list with folder filters, the matching decisions, the tuning log, the golden list with the latest scores, and the support contacts. Walk through each item live and have the super user make one real change of each kind while you watch.

​

Ontology change management after go-live

The ontology will keep changing: a new attribute, a renamed type, a new relationship. Each save creates a revision and re-checks every dependent configuration (see ontology compatibility). Run every change through the same five steps.

1. Propose. Write down the change and the business question it enables. If no question needs it, don’t make it.
2. Impact. Save the change, then open Model & Define > Compatibility. Renames mark dependents stale (names auto-updated). Deletes mark them invalid, which blocks their scans and rules.
3. Fix. Fix invalid items first, then review stale and pending review items. Use Mark as reviewed where an auto-update is already correct.
4. Re-validate. Click Re-validate on each fixed item, then try one or two files with Test Ingestion on the affected artifact types.
5. Re-scan. Existing nodes don’t change by themselves. Requeue or re-scan the affected files, reload affected structured sources, and re-run affected enrichment rules. Then re-run the golden questions that touch the change.

​

Operating cadence

​

Worked example: Northbridge Consulting

• UAT. Eight pilot users (three from BD, three from Resourcing, two from Legal) used Experio for two weeks. Dana’s team flagged that “past performance” answers ignored case studies older than 2021. This was a folder filter date range from the pilot, and it was widened for the full load.
• Full ingestion. Batch 0 refreshed the four structured exports. Batch 1 was the Engagements library (about 9,400 files), batch 2 was Resumes (650 files) and batch 3 was status reports on metadata_and_snippet. Batch 1 produced 140 new match reviews for client name variants, and Marcus cleared them in two days.
• Waves. Wave 1 was the pilot users and their teams (60 people). Wave 2 was all of BD, Resourcing and Legal (180). Wave 3 was the firm (650), after Priya’s approval.
• Hypercare. Most issues were training (“ask about the client, not the folder name”). One real defect went to engineering.
• Handover. Marcus now owns the taxonomies, the conflict queue and assistant tweaks. His first solo ontology change added renewal_notice_days to Contract for Helen. Compatibility flagged the MSA artifact type as stale, Marcus reviewed it and added an extraction instruction, requeued the MSAs from Ingest, and re-ran Q7 and Q8.

​

Common pitfalls

• One giant full scan. Failures and review queues pile up faster than anyone can triage them.
• Skipping the cost estimate. A 10x corpus at pilot settings is a 10x bill.
• Rolling out before access control is enforced. Users see content they shouldn’t, and trust is hard to win back.
• Handover as a slide deck. The super user must make real changes before hypercare ends.
• Ontology edits on a Friday. An invalid config blocks the weekend’s scheduled flow.
• No monthly re-score. Accuracy drifts as new document styles arrive, and nobody notices until a user does.

​

Go-live readiness checklist

• UAT completed, feedback triaged, go decision recorded by the sponsor
• Full ingestion plan agreed, with batches, cost estimate and owners
• All batches ingested, failures explained, conflict queues cleared
• Graph Evaluation re-run on a fresh sample of the full corpus
• Golden questions re-scored on the full corpus at or above the success criteria
• Recurring flow scheduled (structured scans, then incremental document scan, then enrichment)
• Access control in enforce mode (if used) and tested for each wave
• Users provisioned for wave 1, and training sessions booked
• Support model and escalation contacts published
• Hypercare dates and daily check agreed
• Handover pack delivered. The super user has made one change of each owned kind.
• Operating cadence booked in calendars

​

Next

See the Worked Example for the full Northbridge Consulting implementation end to end, and Templates for the scoring sheet, tuning log and handover pack.