Guided walkthrough: your first engagement

Allow 60–90 minutes for this walkthrough. A facilitator can extend it into the half-day workshop in the Training workbook. All Northstar Parts names and measurements are fictional. The example is a learning exercise, not evidence of business results.

Before you begin

Open the local application at http://localhost:4317. To inspect the supplied demonstration, open Settings › Workspace → Explore a fictional company → Open my sample company. Use the company switcher at the top of the company sidebar to open the clearly labeled Cobalt sample or the generated Northstar Parts — Advisor Training company. If Northstar is absent, ask the operator to run npm run training from the repository; that creates a new synthetic company and regenerates the example files. It does not replace Cobalt.

To practice writing records, add a separate company: on Home, select Add a company (it opens Companies › Add account), choose Already engaged in DutyGraph so Discovery opens, and select Add account. Name it “Northstar practice — your initials.” Do not edit the completed example while a class is using it. In a hosted client engagement, setup, identity assurance, data policy, and deployment acceptance would need to be completed first; this walkthrough uses the local training installation.

Page names in this walkthrough

This exercise uses the record tools directly. The current app places them here:

The Company Repo shows the same records as files. After each step, open Repo to see the file and its state change.

1. Understand the assignment

The fictional client sells parts through one depot. Standard orders go from intake to credit review to release. The sponsor wants fewer delays without weaker credit controls. The advisor must determine whether incomplete intake is responsible for waiting, or whether credit-review capacity is the better explanation.

Payment execution, changes to customer credit limits, production credentials, and automatic release are outside this exercise.

Expected result: a bounded engagement with an unresolved hypothesis, a measurement plan, explicit work ownership, and a client-ready explanation of what is known and what remains uncertain.

2. Create the engagement and roster

1. Open Discovery, then select Engagement scope.
2. Create the engagement plan. Enter the outcome, dates, systems, locations, in-scope work, exclusions, source policy, visibility, retention expectation, review cadence, and timezone.
3. Save, inspect the record, and record your review rationale.
4. In Discovery’s people view, add the four people below. Add managers before their direct reports, or use the CSV preview and import flow.
5. Return to the engagement record and select Alex as sponsor if the roster did not exist when you created it.

Use unique fictional email addresses when practicing enrollment. Local participant accounts are linked to one company and person; do not reuse a participant email from another training run. Use an address at training.invalid for a manual exercise and avoid sending messages to real people.

Checkpoint: the roster has four unique people. A total fictional headcount of 24 does not change the engagement coverage denominator of four.

3. Capture the sponsor’s account

Before collecting the account, open the Company Research step and review what research would cover. For this fictional exercise, do not search for Northstar or spend provider credits: use the workbook exhibits as manual sources. For a real authorized engagement, collect and inspect public context first, draft your questions, and ask the sponsor to correct the initial picture during kickoff.

1. In Discovery, use the saved business snapshot and choose Alex as the contact, with a due date and four or five kickoff questions. The default five cover customer value, output, demand, flow, and authority.
2. Save the reviewed request and open Preview response form. Review the notice and questions before sending.
3. Choose the link-issuance action. No email is sent by issuing a link. Copy the URL only into the approved training browser session.
4. Open the link in a separate browser profile. The current kickoff form needs no account or password. Keep the advisor session open in the original profile.
5. Enter this fictional account: customers value complete orders arriving on time; output is a released standard order; demand is sufficient for the exercise; work sometimes waits for missing fields and a credit-check handoff; exceptions require Jamie’s review.
6. Submit. Back in the advisor session, refresh Discovery, open the returned response, inspect it, and accept it.

Checkpoint: the original response remains visible. Acceptance creates an evidence record tied to that submission. It does not confirm any task or authorize automation.

4. Review two more sources

Add an evidence record named “Training order checklist,” classified as a policy document. Its text says that intake must contain the item, quantity, and customer reference; credit review records a result; release requires a complete checked packet. Use locator “Training workbook, exhibit A, steps 1–3.” Accept it after inspection.

Add “Training queue observations” as an execution record. Its fictional baseline is a median of 10 hours for 20 standard orders; a practice cohort of 20 has a median of 8 hours. Credit review remains under one hour. Use locator “Training workbook, exhibit B, rows 1–40.” State that these are invented training aggregates with different product mix and small samples. Accept the source.

Keep the two source origins independent. Copying the checklist into a second evidence record would not create a second independent source.

5. Describe three task cards

This exercise teaches manual task creation and exact-version company confirmation. For the newer participant-first interview flow, use Review your task cards before sending or the interactive discovery demo.

Open Work Map › Task Cards and add the following work. Use Jamie as accountable owner for all three; use Sam as performer for intake and release, and Robin for credit review.

For every card, enter a concrete purpose, instructions, systems, described actions, denied actions, human checkpoint, supporting evidence, review date, and reason. Use duty “Prepare standard orders for fulfillment.” Use human-only mode in this exercise. Deny automatic release, credit-limit changes, and use of production credentials.

Review each task after resolving required information. The state becomes Awaiting confirmation. Editing a reviewed task creates another version and requires renewed review; do that before sending confirmation requests.

6. Confirm the exact work

1. In Discovery, create a confirmation request for Jamie covering all three reviewed tasks.
2. Create a request for Sam covering intake and release, and another for Robin covering credit review.
3. Issue each private link. In the participant sessions, inspect every task and choose Correct only if the card describes that fictional role accurately.
4. Submit each request. In the advisor session, inspect and accept each returned response.
5. Refresh Work Map › Task Cards and check the confirmation history.

Checkpoint: all three tasks show Human confirmed. This requires current accepted “correct” responses from the owner and performer; where the same person holds both roles, one matching response suffices. A facilitator playing fictional roles is acceptable for training, but those scripted decisions are never evidence of real customer confirmation.

Try choosing Needs change in a separate practice request. Accepting that response opens a conflict on the current task. Resolve the wording with the participant, revise the task, review it, and request confirmation of the new version. Do not relabel disagreement as agreement.

7. Inspect the company views

Open Work Map › Value chain. Select a business stream and stage, then select Jamie in the highlighted organization. Inspect Jamie’s duties and tasks. Use Assign stages to place a duty or task explicitly; a task’s own assignment overrides inherited duty stages. Open Work flows for recorded handoffs and Task Cards for detailed cards and source records.

The Work map reporting chart places Alex above Jamie and Robin, with Sam under Jamie, using the roster relationships you entered. These are not inferred from titles. Missing manager relationships remain unlinked. Open Reports for the Client Brief to see coverage and prepare a reviewed report from the saved work.

8. Define the duty and handoffs

On Work Map › Task Cards, create the explicit duty record “Prepare standard orders for fulfillment.” Name Jamie, connect the three tasks and the accepted checklist, and review the claim. This duty review is separate from task confirmation.

Create two handoffs: Intake to credit review, and Credit result to release. Select the source and receiving tasks. Specify the condition, output mapping, required input, receiving acceptance check, exception owner, timeout, retry ceiling, and failure action. Use Jamie as exception owner, 24 hours as the escalation period, and one retry in the handoff description. Attach the checklist and review each handoff.

Checkpoint: a receiving person can explain exactly what arrives and when to reject it. A title such as “handoff to Finance” alone is insufficient.

9. Observe two manual cases

On Work Map › Work flows, select Create workflow. Create “Standard order review and release,” select the three tasks and two handoffs, use All for joining selected routes, a 24-hour step timeout, and two maximum attempts. Review the definition.

Open the workflow record and select Start case for TRAIN-001 with the fictional order reference. Only intake is initially ready. Record the human observation, select the outgoing route whose condition was met, and complete the step. Repeat for credit review and release. The case becomes Complete.

Start TRAIN-002. Record a failure at intake because the customer reference is missing. It should need attention while downstream work stays blocked. An advisor can record a bounded retry after the missing information is resolved, or close the case with a reason. No order is changed in an external system by these controls.

10. Record a testable explanation

In Strategy, create a constraint hypothesis: “Incomplete intake may delay order release.” Record the competing explanation that credit capacity is the constraint. The discriminator is a comparison of intake waiting and credit-review duration in matched cohorts. The global counterfactual concerns end-to-end release time and total released orders, not merely faster data entry.

Define a metric: median release timestamp minus intake timestamp, measured in hours for the specified cohort. Enter baseline 10, target 7, source, owner, window, and a guardrail against incorrect release. Record a dated observation of 8 with its synthetic source locator.

Create an intervention for a complete-intake checklist. Preserve the prediction “10 hours to at most 7 hours without more credit exceptions.” Create an Outcome review with Inconclusive: the invented result misses the target, the groups differ, and causation is unproven. Review it and assign the next measurement action.

Checkpoint: the report does not claim a proven 20% improvement for a real client. It explains the arithmetic as an invented training observation and keeps the original prediction intact.

11. Run the review and prepare delivery

Open Outcomes for the weekly review. Discuss returned evidence, stale or conflicting work, missing baselines, workflow exceptions, and outstanding commitments. Record Jamie’s next action and due date.

Open Reports, then choose Prepare client report in the Client Brief, and name Alex and Jamie as the fictional audience. Review and refine the suggested purpose, summary, decisions, next steps, limitations and selected records. Save the frozen draft, open its preview, and inspect every section.

Approve the exact current content and audience with a rationale, then download the ZIP. Open client-report.html; print it to PDF if desired. Inspect record-register.csv and checksums.json. The package omits original response text and recordings. Delivery remains manual.

12. Finish the handoff

Record who owns the next review, the outstanding evidence questions, and the limits of the current result. Store the approved package using the engagement’s agreed policy. Ask the operator to take an encrypted backup and perform the documented restore drill before any important installation change.

You have now practiced the entire supported advisor journey. Repeat it with the adverse scenarios in the Training workbook before moving to an accepted customer environment.