DUTY GRAPH · ADVISOR ENABLEMENT

Release 0.3 · Hosted advisor pilot · September 2026

Advisor starter program: practice, review, then lead

This is the initial DutyGraph training curriculum. It is available for self-study and supervised practice. It is not an accredited certification. A completed lesson does not establish that an advisor is ready to work independently with client data.

What a trained advisor should be able to do

Run a bounded discovery engagement from research through a client readout. Explain the difference between a participant's account, a reviewed company work record, and permission to delegate work to an agent. Preserve disagreements and missing evidence instead of filling them with plausible guesses.

Use the fictional participant walkthrough and participant guide before the exercises. The sample does not send invitations or issue live agents.

Module 1: qualify the engagement

Practice: an executive asks to automate the entire business. Write a one-sentence scope for one workflow, name the decision the work should support, and identify the sponsor and day-to-day work owner.

Required output: scope, exclusions, participant estimate, agreed data sources, success measures, and unresolved setup requirements. Before real collection, the operator and client must agree data handling, provider use, access, and retention.

Pass condition: another advisor can explain what is in scope and what would require a new agreement. Do not start with a promise of savings or a predetermined automation solution.

Module 2: prepare and lead the kickoff

Practice: separate public research into supported facts, inferences, and questions. Draft an invitation to the point of contact asking for executive participants, a roster, departmental responsibilities, goals, and concerns.

Run a 20-minute role-play with a sponsor. Ask for a recent example. Clarify the desired outcome, current measures, and constraints. Ask permission before recording a real meeting.

Required output: meeting guide, corrected business context, agreed roster, and open questions. Public research must not silently establish internal reporting lines or task ownership.

Module 3: prepare the team questions

Practice: review two people in the roster. Check department, role, and proposed duties against the kickoff account. Correct errors before generating individual questions.

A useful prompt asks: what arrives, what you do, what leaves, where it goes, which software you use, and what makes the work difficult. Ask for exceptions and an actual recent example. Prefer voice, while preserving a typed option.

Required output: reviewed questions and a private invitation draft. Demonstrate which action prepares a request and which action sends it. Do not use a real participant's email during practice.

Module 4: review returned task cards

Practice: a participant explains a task, edits the extracted cards, marks one uncertain, and submits. Find the original account and the reviewed card in the advisor view.

Explain that the participant has confirmed their understanding of the input, action, output, destination, and software. This does not assign company authority or resolve a conflict with another person.

Required output: two reviewed cards and an issue log with the source, disagreement, decision owner, and next question. Keep original accounts intact. Do not claim that automatic cross-team conflict detection has resolved the issue.

Module 5: diagnose and deliver

Practice: compare two accounts of the same handoff. One person thinks an order is ready when stock is reserved; the other expects a confirmed delivery date. State the mismatch and ask the work owner which condition is required.

Create a hypothesis about delay, identify the evidence needed to test it, and name a measure with a baseline period. Use a framework only when its inputs are available. Missing data should remain visible.

Required output: an evidence-linked work map, unresolved-issues log, and short readout with one recommended next step. Show what would change your conclusion. Obtain the required review before distributing a deliverable.

Module 6: hand off and maintain

Practice: teach an internal owner how to review a changed task and identify affected handoffs. Ask them to do it back without your help.

Required output: named internal owner, review cadence, open actions, change process, and support contacts. A 6–12 month support period is a possible commercial model, not a required or proven duration.

Practical review rubric

Score each item 0 (missing), 1 (needs help), or 2 (independent and evidenced).

SkillEvidence to inspect
ScopeOne workflow and explicit exclusions
KickoffQuestions address gaps rather than assume answers
RosterPeople and duties trace to leadership input
Participant flowCorrectly demonstrates prepare, send, answer, review, submit
Evidence handlingPreserves original accounts and sources
Task reviewDistinguishes personal understanding from company authority
DiagnosisStates uncertainty and a way to test the finding
DeliveryReadout has a decision, owner, and next step

Suggested internal threshold: at least 13 of 16, with no zero in evidence handling or task review. This is a proposed quality threshold to calibrate during the first cohort. Two reviewers should compare scores on the first three exercises.

Critical failures require retraining regardless of the total: exposing another participant's private data, fabricating evidence, treating a demo issuance as live, or sending an invitation without the agreed recipient and scope.

Supervised pilot and release to independent work

The delivery lead observes one kickoff, samples returned cards, and reviews the final readout. Record advisor hours, correction rate, sponsor usefulness feedback, and issues requiring help. A reviewer records the decision and any limits; the app does not automatically certify advisors.

The first cohort should remain small enough for this review. Training more advisors than the delivery team can supervise would reduce quality before the method is proven.