> ## 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.
# Go-Live & Handover
> Run user acceptance, ingest the full corpus, roll out in waves, support hypercare, and hand the configuration to the client's super user
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
| | |
| - | - |
| **Purpose** | Get sign-off from real users, load everything, launch safely, and leave the client able to run and change Experio |
| **When** | Phase 5 (weeks 7–8): user acceptance, after Workshop 10. Phase 6 (weeks 9–10): full ingestion, rollout, training, hypercare, handover. |
| **Who** | FFE (full ingestion, hypercare fixes), PM (plan, waves, comms, sign-off), super user (acceptance lead, future owner), sponsor (go/no-go), pilot users, client IT admin |
| **Inputs** | Accuracy validation met the success criteria ([Accuracy Validation](/implementation/accuracy-validation)). Assistants and agent flows are configured. |
| **Outputs** | UAT sign-off, full corpus ingested, users onboarded, support model agreed, handover pack, operating cadence in calendars |
| **Admin pages** | Process > Jobs, Process > Flows, Process > Conflict Resolution, Process > Graph Evaluation, Model & Define > Compatibility, Observe > Usage Statistics, Observe > Logs, Administer > User Profile Management |
## 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](/implementation/accuracy-validation#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".
Pilot users' own questions are the best source of new golden questions. Add the good ones to the golden list.
## 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.
| Batch | Contents | Check before the next batch |
| - | - | - |
| 0 | Refresh structured master data in load order | Counts match the exports |
| 1 | The largest and most valuable document library, filtered to the in-scope date range | Failures explained, conflict queues cleared, Graph Evaluation on a fresh sample |
| 2 | Remaining document libraries, one per job | Same checks |
| 3 | Low-value, high-volume content (status reports, exports) on light extraction policies | Cost within the estimate |
* **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](/admin-guide/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](/implementation/key-concepts#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
| Wave | Who | Gate to the next wave |
| - | - | - |
| 1 | Pilot users plus their immediate teams | One week with no blocking issues |
| 2 | The full use-case groups (for example, all of BD, Resourcing, Legal) | Support volume manageable, no access-control surprises |
| 3 | Rest of the firm, or further practices | Sponsor approval |
Before each wave, confirm that users exist with the right roles (**Administer > User Profile Management**, or SSO). If [access control](/implementation/key-concepts#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:
First login and the basics
Asking questions and reading answers
Choosing the right assistant
Checking where an answer came from
Managing chat history
Organising conversations
Sharing and exporting results
Using Experio from other AI tools
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.
| Level | Who | Handles |
| - | - | - |
| 1 | Super user (and delegates) | "How do I…", wrong-answer triage with the decision tree, conflict queues, access requests |
| 2 | Experio FFE, with Experio SMEs as needed | Configuration fixes the super user can't make yet, tuning, reprocessing |
| 3 | Experio engineering | Product defects, platform incidents, performance |
**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
| Area | What the super user does | Where |
| - | - | - |
| Taxonomy refresh | Re-import changed picklists and skills (CSV merge), add synonyms, retire values | Model & Define > Taxonomies |
| New artifact types | Add a type, write classification and extraction instructions, use Test Ingestion, assign it to folder filters | Model & Define > Artifact Types |
| Conflict queue | Resolve classification and match reviews, and turn repeated patterns into fixes | Process > Conflict Resolution |
| New data sources | Add a data source on an existing connector, set filters, run the first scan | Connect > Data Sources |
| Assistant tweaks | Adjust instructions, Cypher and entity-resolution guidance, and prompt extensions | AI & Agents > Agent Configuration, AI & Agents > AI Instructions |
| Golden questions | Keep the list current and re-run it on the cadence below | Shared scoring sheet |
| Ontology change requests | Propose and run changes through the change process below | Model & Define > Ontology, Compatibility |
### 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](/implementation/key-concepts#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](/implementation/key-concepts#ontology-compatibility)). Run every change through the same five steps.
```mermaid theme={null}
flowchart LR
A[Propose change
with the question
it serves] --> B[Save and check impact
in Compatibility]
B --> C[Fix invalid first,
then review stale
and pending]
C --> D[Re-validate and
Test Ingestion]
D --> E[Re-scan or requeue
affected data]
E --> F[Re-run affected
golden questions]
```
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.
If a change goes wrong, roll back from **Revision History** (on the Ontology page) and re-validate. Make changes outside scheduled flow runs so that an invalid config doesn't silently block a nightly load.
## Operating cadence
| Cadence | Activity | Owner |
| - | - | - |
| Weekly | Clear the Conflict Resolution queues. Review failed and skipped files from scheduled flows. | Super user |
| Weekly | Check Compatibility is all valid | Super user |
| Monthly | Re-run the golden questions and compare with the last score | Super user, with FFE support in the first quarter |
| Monthly | Refresh taxonomies that change often (skills, service lines) | Super user with the taxonomy owners |
| Quarterly | Model review: cost per document, model tiers, new models, Graph Evaluation on a fresh sample | Experio and super user |
| Quarterly | Use-case review with the sponsor: usage, new questions, new data sources | PM and sponsor |
## 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](/implementation/worked-example) for the full Northbridge Consulting implementation end to end, and [Templates](/implementation/templates) for the scoring sheet, tuning log and handover pack.