Assignment
Use the support pilot to demonstrate one successful draft, one unsupported question, one permission denial, and one corrected error.
Build sequence
- Write a ten-minute operator training flow with hands-on tasks.
- Create a feedback form with distinct failure categories and request IDs.
- Prepare a one-page sponsor update with outcomes, limitations, and decisions needed.
- Ask a peer to explain the system’s boundaries after the session.
Acceptance checks
- The peer knows how to inspect evidence, reject a draft, and return to manual work.
- The demo includes failure and recovery without hiding them.
- Reported improvements are linked to measured pilot cases.
Evidence to keep
Submit the working artifact or decision document described above, the inputs used, and the observed results for every acceptance check. Include one failed attempt and the change you made after investigating it. Label fixture-based outcomes separately from live-system measurements. These artifacts become part of your final portfolio review.
Guided workshop: demonstrate value and limitations together
A customer demo should follow an actual workflow: open a ticket, find permitted evidence, draft a response, inspect citations, and decide whether to use it. Use Northstar's synthetic tickets and label the environment clearly.
Prepare three demonstrations: a successful ordinary ticket, an unsupported policy exception, and a denied cross-tenant request. The latter two teach users when to stop and inspect. Hiding them encourages overtrust and leaves the customer unprepared for normal failure modes.
Role-play: the sponsor asks, “Can it send replies automatically next week?” The operator asks, “What happens when the policy is wrong?” The security reviewer asks, “How do I know another tenant's data was not included?” Answer each with evidence and ownership, not a feature promise.
Worked responses: automatic sending is a separate scope decision requiring action authorization and additional evaluation; a disputed policy routes to its owner and stays out of automatic answers; the access matrix and captured retrieval IDs provide evidence of the tested isolation boundaries. Explain remaining limitations instead of implying a test proves all possible cases.
Exercise: deliver a five-minute walkthrough and a one-page operator guide. The guide should cover eligible tasks, citation inspection, editing or rejecting drafts, reporting an error, fallback use, and escalation. Ask the peer to perform a task afterward without coaching and record where they hesitate.
Adoption measurement: distinguish enabled users, active users, repeated use, accepted drafts, corrected drafts, and completed support tasks. A high login count does not prove useful adoption. Collect reasons for rejection and compare handling time with the agreed baseline while accounting for task difficulty.
Executive readout: state the problem, what was tested, observed results, unresolved issues, and the decision requested. Technical detail belongs in an appendix when it supports a decision. If results are simulated, say so in the first paragraph.
Assessment: include one objection you could not resolve and the next validation action. A strong customer engineer can say “we do not yet have evidence for that” and propose a bounded experiment instead of committing the team to an unsupported deadline.