# Hosted pilot: start here

Release 0.3 adds Vercel hosting, a private sample company, encrypted account API-key settings, OpenAI discovery drafts and Resend invitation sending. The earlier guides explain the underlying advisor workflow; this chapter supersedes their local-only and manual-email setup notes. This remains a pilot, with the production gaps listed below.

## First visit

1. Open https://dutygraph-v2.vercel.app and create your advisor account. Choose a strong password and keep it in your password manager; password recovery and email verification are not implemented yet.
2. Open Workspace settings → Explore a fictional company → Open my sample company. Cobalt is private to your account. Loading it does not send email or call AI/search providers. Reopening returns the same sample, preserving your edits.
3. Use Company graph to inspect connected evidence, workflow, teams and duties. Reporting lines appear only where recorded. PostgreSQL holds the authoritative records. Optional Neo4j Aura can project the graph, with current PostgreSQL records available when Aura is absent or behind.
4. Use the company selector → New company workspace for your own business. Keep real records separate from the fictional sample.

## Connect your services

Open Workspace settings → API keys & connections. Enter the provider key and save while signed in to your advisor account. No account password is requested. Keys are encrypted with AES-256-GCM on the server, bound to the account/provider, and never returned to the browser. They apply to all companies in your account. Saving does not make a provider call or verify that a key works. Hosted accounts never share an operator's paid key.

| Service | What to enter | Where to try it |
| --- | --- | --- |
| Exa | Exa project API key | Discovery → Business research |
| OpenAI | OpenAI project API key, model and reasoning effort | Discovery and Strategy |
| Resend | Resend API key and an email address on a domain verified in Resend | Open a participant request → Send invitation email |

Provider billing and account spending limits are managed with each provider. Removing a saved key stops subsequent calls using it; an already-started provider request may finish. The OpenAI connection used by the development assistant is separate from your application's credentials. Do not send API keys through chat or put them in repository files.

The separate **Neo4j company graph** section accepts your Aura URI, database username, database name and database password. Use the `neo4j+s://…databases.neo4j.io` address from Aura. Saving enables metadata sync for companies in your advisor account. **Test connection** verifies the database, and **Build company graph** requests a current projection. Original records remain in PostgreSQL; full evidence text and recordings are not copied. Removing the connection stops later access without deleting copies already in Aura. The pilot advisor account's connection and projection were verified on September 6, 2026. New accounts must save and test their own connection.

## Research a real business before the first meeting

Open Discovery and follow its five steps: **Research & contact**, **Leadership meeting**, **Review the team**, **Team interviews**, and **Review task cards**. The app carries the relevant sources forward. You do not select evidence checkboxes in this journey.

Start with all four public research areas. Draft the preparation email to your one point of contact. Save and preview it, then send the private response link. Use the contact's reply to prepare the live meeting guide. Save the kickoff notes, review the resulting team dossiers, create the personal interviews, and send them to the reviewed team. Participants can review extracted task descriptions before sending their answers. The advisor then resolves gaps and ownership.

Read [From business research to confirmed work](23-discovery-to-confirmed-work.md) for each button and handoff. Research has a ten-request allowance per account per day; the guided discovery AI has a separate thirty-run allowance. Provider charges apply. Failed or uncertain attempts count and do not retry automatically.

## Invite someone to answer questions

1. Add the participant with their correct email address. Use a separate participant address when testing; the current pilot does not let one email hold both advisor and participant accounts. Prepare a work-capture or exact-task confirmation request in Discovery.
2. Review the questions, recipient, due date and privacy notice. Configure Resend's verified sender in Settings first.
3. Open the request and click Send invitation email. This is the action that sends email; preparing a request or generating a manual link does not send one.
4. A successful API response appears as Accepted by Resend. Inbox delivery, bounce tracking and reminders are not implemented yet. If the outcome is unknown, check the Resend dashboard before sending again. There are at most fifty attempts per account per rolling 24 hours.
5. The recipient clicks their private seven-day link, creates a participant password (or uses their existing password), reads the notice and opens their assigned questions. They can type answers or record up to 20 minutes. **Save recording** uploads and verifies the clip. If OpenAI is configured, **Create transcript** produces editable text. The participant checks the transcript, adds it to the written answer, then chooses **Create my task cards** for a work interview. They edit and check each description before choosing **Send my response**. If drafting is unavailable, they can explicitly send the answer without cards. The recording remains attached. Text drafts save on the same device. A failed transcription keeps the recording and offers an explicit retry or a typed answer.
6. After submission, the advisor sees the returned request in Discovery and reviews it. A participant reply alone does not confirm current task ownership; the existing exact-version confirmation and advisor-review rules still apply.

You can also generate a private link and share it yourself. Every replacement link revokes previous unused links for that request. Withdrawing a request revokes unused invitations and blocks new replies. Links are bearer secrets; do not forward them to someone else. Use **Preview email** to inspect the branded HTML invitation before sending. The email includes the company, the recipient's role, the actual request questions, preparation instructions and a private response link. Replies and full task records are not included in invitation emails.

## What is still unfinished

Firecrawl, email delivery webhooks/reminders, password recovery, verified identity/SSO/MFA, full production retention/deletion, external authority integrations and governed customer-system execution remain open. The graph uses a custom SVG view, with an optional current Neo4j Aura projection and PostgreSQL fallback. The pilot advisor account's live Aura projection and repeat rebuild were verified. Hosted operation and passing tests do not certify the full original production specification.

Provider adapters have automated simulated-response tests. Actual AI quality, Exa results and email receipt require live acceptance with your configured accounts. No live paid AI/search calls or real invitation emails were made during this release verification.

## Current model choices

New OpenAI configurations default to GPT-5.6 Sol with medium reasoning. GPT-6 Astra, GPT-5.6 Terra and GPT-5.6 Luna are also available; legacy configurations remain selectable. The chosen model and reasoning effort apply to meeting briefs, task drafts and hypothesis drafts. Exa performs source collection separately. Modern model calls allow up to 12,000 output tokens including reasoning, with a 105-second provider timeout. High reasoning can take longer and cost more; no automatic model downgrade or retry occurs. Model access depends on your OpenAI project.

API IDs and reasoning support were checked against the [official OpenAI model catalog](https://developers.openai.com/api/docs/models) on September 5, 2026. This update is verified with adapter contract tests, not a claim of live output quality from your key.


### Audio transcription

Transcription uses the advisor account’s encrypted OpenAI key and the `gpt-4o-transcribe` speech model. It is separate from the reasoning model chosen for Discovery. Recordings can be up to 25 MB. The app permits up to three transcription attempts per recording and fifty per account in 24 hours. Completed jobs are reused. Failed or uncertain attempts do not retry automatically. Review the text for names and numbers before submitting. Provider response text is bounded; audio content and provider diagnostics never appear in application errors.

The original clip keeps its checksum and request/person link. The unedited machine transcript is retained with its source recording; retention clears that job result when the recording expires. A participant’s submitted, reviewed text becomes part of the response and can be accepted into evidence. Browser microphone behavior, paid transcription quality and inbox delivery still require acceptance with the configured accounts. Automated tests use synthetic providers and send no email.


If a participant sends audio without written text, open the returned response and create its transcript. Compare it with the recording, correct any errors, then choose **Save reviewed transcript as evidence**. Discovery can now use that text to prepare the next step. The original response and recording remain unchanged. A second copy is not created when the same review is saved again.


# Start here: what Duty Graph does

Duty Graph helps an advisor turn conversations and source material into a reviewable description of how a company works. The advisor connects evidence to people, tasks, handoffs, problems, measurements, and decisions. A client receives a report that states what was learned, what remains uncertain, and who owns the next action.

Release 0.2 is a working local advisor application with PostgreSQL persistence. It supports a complete human-led engagement and manual workflow observation. External AI, email, enterprise identity, customer-system authority, and execution adapters are unconfigured. The application will not perform business actions in those systems.

## The problem it helps solve

People often describe the same process differently. A manager may say that Finance approves a supplier while Finance says it only checks bank details. Drawing an arrow between the two teams does not resolve that difference. The advisor needs to preserve both accounts, find the governing evidence, and ask the right people to confirm a precise description of their work.

Duty Graph keeps those distinctions visible. A source can be accepted into the record without proving every assertion in it. A task can be reviewed by an advisor without being confirmed by its owner and performer. A confirmed task can be proposed for assistance without granting an agent permission to execute it.

## The engagement in eight moves

1. **Prepare and bound the work.** Research public context, prepare a draft for the team to correct, and name the outcome, scope, sponsor, source policy and review cadence. Exa source collection is optional and requires operator configuration; the advisor writes the initial synthesis.
2. **Gather accounts.** Add people, issue private requests, and collect typed or recorded responses.
3. **Review evidence.** Check the original, its locator, its origin, and the limits of what it supports.
4. **Describe the work.** Write task cards, identify accountability and performance, define duties and receiving checks.
5. **Confirm and connect.** Ask the named people to review exact task versions; use the graph to follow relationships.
6. **Test the explanation.** Record a constraint hypothesis, competing explanation, metric, intervention, and outcome.
7. **Review progress.** Observe manual cases, resolve exceptions, and assign the next useful action.
8. **Deliver a reviewed record.** Freeze a client report, review its audience and contents, download it, and arrange delivery through your approved channel.

These moves may repeat. Discovery often reveals a missing owner or contradictory source. That is useful information to resolve, not a reason to fill in a convenient answer.

## The main records

| Record | The question it answers | Example |
| --- | --- | --- |
| Engagement | What are we here to understand and improve? | Standard order intake through release |
| Person | Who is in the engagement roster? | Jamie Park, fulfillment lead |
| Evidence | Where did this account or observation come from? | Order checklist, exhibit A, steps 1–3 |
| Task | What happens when a trigger occurs? | Check the incoming order |
| Duty | What continuing responsibility groups this work? | Prepare standard orders for fulfillment |
| Handoff | What must be true before the next task accepts work? | Complete intake checklist received by credit reviewer |
| Workflow | Which reviewed tasks and handoffs form the sequence? | Standard order review and release |
| Case | What happened to one instance of that workflow? | TRAIN-002 is missing a customer reference |
| Constraint hypothesis | What might limit the overall result? | Incomplete intake may create the longest wait |
| Metric | How will we observe the result? | Median hours from intake to release |
| Intervention | What change and prediction will we test? | Try a complete-intake checklist |
| Outcome review | How did observations compare with the prediction? | Inconclusive after one small practice cohort |
| Agent proposal | What assistance could be considered for specific work? | Draft a completeness checklist for human review |
| Client report | What should this named audience receive? | Executive findings and next actions |

## Why there are three company views

**Connected** follows evidence, people, work, and hypotheses. Select a card to highlight its immediate relationships and read the connection labels. Use Focus connections for a smaller neighborhood. This view helps answer, “What supports this claim, and what depends on it?”

**Work flow** emphasizes recorded task order. Handoff records supply source-to-target connections. A handoff describes the receiving condition; an arrow alone is insufficient to establish it.

**Org & duties** answers, “Who owns and performs this work?” By team groups the roster and shows responsibilities. Reporting chart shows managers above direct reports only where a manager relationship was recorded. If those relationships are absent, the application explains that instead of inventing an org chart. The roster remains a reported structure, not verified authority.

The graph is a way to inspect the record. It is not the place where truth, authorization, or causation is created. Open the underlying record to inspect its evidence and state.

## Four distinctions to teach every participant

| Distinction | Practical meaning |
| --- | --- |
| Account and fact | A person’s statement is evidence that they reported something. Corroboration may still be needed. |
| Review and confirmation | The advisor reviews completeness. Named participants confirm their exact described work. |
| Work and permission | Describing an action does not authorize a person or an agent to take it. |
| Observation and cause | A better metric after a change does not, on its own, prove that the change caused it. |

The labels Known, Inferred, Assumed, and Missing help explain the advisor’s basis. Use Known for what the cited source directly establishes. Use Inferred when connecting observations. Use Assumed when an untested premise is necessary. Use Missing when the needed information has not been collected. These are review labels, not automated truth scores.

## What the client sees

A normal delivery is a readable executive or weekly report with scope, coverage, findings, decisions, next steps, limitations, and selected work records. It includes version and source identifiers so the advisor can trace it back to the workspace. The report ZIP also includes structured JSON, a CSV register, a read-me, and file checksums.

Raw interview text, recordings, participant credentials, invitation links, and person email addresses are excluded from client-report fields. Free-text findings are still written by the advisor, who must check them for unnecessary sensitive material before approval.

Internal workspace snapshots, confirmed-work packets, and agent proposals serve different audiences. They are implementation and review artifacts. The advisor should not send an internal package to a client simply because it downloaded successfully.

## How to learn the product

Start with the Guided walkthrough in this help center. Use the Northstar Parts training company to inspect completed examples. Use a separate blank training company for practice. Then complete the Training workbook and compare your reasoning with the Facilitator guide. The Full user manual is the reference for screens, fields, states, recovery steps, and limits.

For technical installation, backup, recovery, and release acceptance, use the repository’s OPERATIONS, ARCHITECTURE, SECURITY, and VERIFICATION documents. These operational checks remain distinct from an advisor’s review of the business record.


# 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. Choose Open sample workspace if you are inspecting the supplied demonstration. Use the company selector to open Northstar Parts — Advisor Training. If it 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, create a separate workspace using the company selector. 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.

## 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 **Engagement & kickoff**.
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.

| Person | Role | Team | Reports to |
| --- | --- | --- | --- |
| Alex Morgan | Executive sponsor | Leadership | Not recorded |
| Jamie Park | Fulfillment lead | Fulfillment | Alex Morgan |
| Sam Rivera | Order specialist | Fulfillment | Jamie Park |
| Robin Ellis | Credit reviewer | Finance | Alex Morgan |

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 Business research and review its six preparation topics. 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. On Engagement & kickoff, choose Alex, a due date, and four or five kickoff questions. The default five cover customer value, output, demand, flow, and authority.
2. Create the request and open it. Review the notice and questions before issuing the private link.
3. Choose the link-issuance action. No email is sent. Copy the URL only into the approved training participant browser session.
4. In a separate browser profile, open the link, acknowledge the notice, and set a participant 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](25-participant-review.md) or the [interactive discovery demo](/?demo=discovery).

Open **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.

| Task | Trigger | Required input | Output |
| --- | --- | --- | --- |
| Check the incoming order | A standard order arrives | Item, quantity, customer reference | Complete intake checklist |
| Record the credit-check result | Intake is complete | Checklist and customer reference | Recorded pass or exception |
| Release the checked order | Passing result is recorded | Complete checked packet | Human-recorded release |

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 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 **Company graph**. In Connected, choose Jamie in Explore and inspect accountability arrows. Select a task and follow its source links. Use Focus connections to center the picture on that record; open Register for the broader record index. Use Readable when Fit makes a large graph too small. Pan to follow cards outside the viewport.

Open Org & duties. By team shows the four people and their responsibilities. Reporting chart places Alex above Jamie and Robin, with Sam under Jamie. These are the roster relationships you entered. They are not inferred from titles. The original Cobalt example has no recorded managers and therefore explains why it cannot draw a reporting hierarchy.

## 8. Define the duty and handoffs

On 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

Open **Workflows & cases**. 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.

Start case 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 **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 **Deliverables**, create an executive client report, and name Alex and Jamie as the fictional audience. Write the purpose, summary, decisions, next steps, and limitations. Select relevant records. Create the frozen draft, open the 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.


# Full user manual

This manual describes Duty Graph 0.2, the local advisor pilot. It covers the advisor workspace, participant capture, record lifecycle, graph, strategy, workflow observation, reporting, and recovery. The generated record-field reference and operator runbooks accompany it in the portable handbook.

## 1. Accounts and access

**Advisor accounts** can manage companies in their own tenant, inspect the company’s records, issue participant requests, review evidence and work, and generate deliverables. An advisor is an application role; it does not establish authority over a client’s business systems.

**Participant accounts** can access their assigned company and requests. The participant view omits the general workspace, other participants’ accounts, raw advisor evidence, and administration. Task snapshots sent for confirmation include only the fields needed to review the described work.

Create your own workspace from the sign-in screen using your name, email, a password of at least ten characters, company name, scope, and desired outcome. Registration creates a separate tenant. The local pilot does not verify email ownership, provide SSO/MFA, or implement self-service password recovery. A private invitation is a bearer link and must be handled accordingly.

Sessions expire after twelve hours. On expiry, sign in again and refresh before retrying a save. The application stores session tokens in HttpOnly, SameSite cookies and requires a session-bound token on authenticated changes. Do not share a browser profile across real participants.

The sample entry is available only when the operator enables the demo. It opens a shared synthetic advisor account. Use it only for fictional information. The company selector switches among companies belonging to that account. New workspace creates another bounded company; it does not erase the current one.

## 2. Navigation and common controls

| Navigation item | Use it for |
| --- | --- |
| Overview | Scope, progress indicators, recent activity and next steps |
| Discovery | Requests, responses, sources, people and engagement kickoff |
| Company graph | Connected relationships, work flow, teams and reporting structure |
| Task cards | Detailed work descriptions, confirmation state, duties and handoffs |
| Workflows & cases | Reviewed task sequences and manual case progress |
| Strategy | Framework analyses, hypotheses, metrics, interventions and outcomes |
| Agent governance | Version-bound assistance proposals and explicit integration gaps |
| Weekly review | Current exceptions, decisions, commitments and follow-up |
| Deliverables | Audience-reviewed client reports and internal export packets |
| System & connections | Actual integration coverage, projection status and audit events |
| Workspace settings | Company scope, outcome and collection notice |
| Help & training | This manual, guided tutorial, workshop and examples |

Use the top search control or Ctrl/Cmd+K to find a record by title or content. The search runs over the current loaded company record. Use page-specific filters to narrow lists. Open a row to inspect details; edit controls appear only for directly editable kinds. Close a dialog with its close button or Escape. The modal keeps keyboard focus within it and returns focus when closed.

The theme button switches between graphite and light mode. The preference is saved in this browser. At narrower widths the sidebar becomes a menu. Graphs and wide reference tables may scroll within their panels; they should not force the whole page wider than the screen.

Changes are server-backed. A successful save means the API committed the record and associated audit/outbox data. A toast or error remains visible when a command fails. Refresh after a version conflict and compare current content before retrying; do not repeatedly submit an old form.

## 3. Engagement setup

Discovery’s Engagement & kickoff view records the scope of one review effort. Enter a meaningful title, sponsor, desired outcome, start/end dates, systems, locations, in-scope and out-of-scope activities, source policy, visibility expectation, retention expectation, cadence, timezone, and success criteria.

The sponsor may initially be unresolved. Add the person to the roster and revise the engagement when identified. Headcount is optional and distinct from the engagement roster. The end date must not precede the start date. Timezone uses an IANA name such as America/New_York.

Review the engagement with a rationale. The reviewed state records the advisor’s assessment. It does not establish a signed contract, consent from every participant, or enforce all policy fields. In particular, the engagement’s retention field records the agreement you intend to use; it does not reconfigure the current 30-day audio retention worker or create a legal hold. The operator must implement any different retention requirement before collection.

Coverage shows unique roster participants, unique people who returned or completed a request, confirmed tasks, and unresolved ownership/performance. Multiple requests to one person do not increase the unique respondent count. These measures describe this engagement, not company-wide representativeness.

The kickoff builder offers eight stable question topics. Choose four or five to keep the first conversation bounded. Request records preserve the selected question IDs and plan version. The operator should not treat these questions as a diagnostic verdict; they identify evidence and follow-up needs.

## 4. People and roster import

Each person has a name, email, role, team, optional manager, and optional external ID. Names and titles are descriptive. Manager fields drive the reporting chart. A person cannot report to themselves, and edits that introduce a reporting cycle are rejected.

Use **Import roster CSV** to preview before applying. The preview identifies missing values, invalid addresses, duplicates, unresolved managers, and cycles. Invalid rows are quarantined and shown with reasons. Correct the CSV or proceed only with the valid rows the preview identifies. Existing people are not silently merged by a matching display name.

The sample CSV shape is:

```csv
name,email,role,team,manager_email,external_id
Alex Morgan,alex@practice.invalid,Executive sponsor,Leadership,,TRAIN-ALEX
Jamie Park,jamie@practice.invalid,Fulfillment lead,Fulfillment,alex@practice.invalid,TRAIN-JAMIE
```

Review names and reporting lines after import. A duplicate email within a company is rejected by record creation. An external identifier is a reference value, not a login credential or proof of identity. The pilot has no automatic directory synchronization, alias reconciliation, or employee lifecycle integration.

## 5. Discovery requests

### Before the first meeting: Business research

Start at Discovery → Business research. Review the displayed public business name and optional official website. A website restricts results to that domain; leaving it blank permits broader public context. The exact query is visible before collection. Confirm that the name and website are public and within scope. With Exa configured by the operator, Collect public sources requests up to five pages. Without a key, add a source manually using type Public research.

Inspect each original link and its captured text before choosing Import as unreviewed evidence. Imported sources retain URL, retrieval time, content digest and research-run locator. Snapshots are limited to the first 6,000 characters per result. The import starts at Needs review; it does not confirm facts, tasks or authority. Research history is saved, and Refresh research retrieves the recorded result after an interrupted browser session. This browser also retains an unfinished request in session storage. Resume saved request reuses its original key, so a recorded provider call is not repeated. After closing the browser or clearing its storage, check saved research history before starting another request.

The application allows ten requests per tenant account across all companies in a rolling 24-hour window. Failed or uncertain requests count. Replaying the same command does not repeat the provider call, and there are no automatic retries. A request left unresolved by a server interruption is marked unknown after five minutes when history is refreshed. Consult the operator before deliberately starting another request if the provider outcome is uncertain.

The guided journey automatically carries research into a contact email and a leadership meeting guide. The contact reply and kickoff notes then supply the reviewed team roster and personalized interviews. Read [the five discovery steps](23-discovery-to-confirmed-work.md) for the current flow. Earlier manual source selection is no longer part of the main discovery journey.

### Request and response workflow

Requests are immutable assignments to one person. Choose Work account, Leadership, or Confirmation. Enter a title, questions, due date, notice, and—when confirming work—the exact reviewed tasks belonging to that person as owner or performer.

Save the draft, review it, then issue a private link. Link issuance changes the displayed state to Link ready. The underlying transport state is `sent`, but **no email has been sent**. The UI returns a manual URL. Give it to the intended person through the engagement’s approved channel. This build does not send reminders.

Invitation links expire after seven days and are single-use for enrollment. Reissuing an open request rotates its unused invitation. Used or expired links do not enroll another person. Once enrolled, a participant signs in to see their assigned requests; they do not need to reuse the original URL.

Request due dates are evaluated through 23:59:59 UTC on the selected date. A request past its due date cannot be submitted. The engagement timezone is descriptive for planning in this release; it does not alter this enforcement or schedule messages. Set dates accordingly and create a fresh request when an extension is required.

If the questions or selected task version change, create a new request. Withdraw an obsolete open request with the available action. Its unused invitations are revoked. The record and historical response remain available for review; withdrawal is not erasure.

## 6. Participant capture

The participant opens an invitation, reads the notice, acknowledges it, and creates a password or uses their existing password when applicable. The assigned page shows request questions and, for confirmation, the exact task snapshots.

A participant can type an account or record audio. Recording requires the browser’s microphone permission. Use record, pause/resume, stop, and playback to inspect the clip. Upload/resume sends chunks; the server validates the completed size and checksum before submission. If upload is interrupted, keep the local clip and resume from acknowledged chunks. Do not close the browser or clear storage until the response is safely submitted.

Typed and recording drafts may remain in local browser storage until submitted or explicitly discarded. A shared device therefore needs careful sign-out and draft handling. Server audio expires after 30 days under the current local policy; the worker removes stored chunks after expiry. Retained metadata and typed evidence have a different lifecycle. There is no comprehensive erasure or legal-hold workflow in this pilot.

Audio is stored as unscanned local database content. No transcript is automatically created. The advisor can listen to a recording, but must not cite an invented transcript or treat the upload checksum as malware scanning. Use typed responses for training environments without microphone access.

For confirmation requests, every assigned task needs a decision: Correct, Needs change, Not mine, or Unsure. Add an explanatory note for disagreement. Submit only after inspecting the exact text. Submission records the participant decision; advisor acceptance follows separately.

## 7. Responses and evidence

Returned responses appear in Discovery. Inspect the original text or available audio, the participant, request, and notice. Accepting a work/leadership response creates an accepted evidence record tied to that original submission. Accepting a confirmation response applies the recorded participant decisions to their exact task versions.

To add a source directly, record its title, type, content, person where relevant, source date, locator, origin, classification, and source bucket. Supported types include employee, leadership and customer accounts; policy documents; system configuration; execution records; public research; and other documents.

The four source buckets organize information: business, leadership, calls, and organization. Use the source’s actual function. A manager’s opinion about permissions is not equivalent to a current policy or application configuration.

A locator should let a reviewer find the supporting passage or observation. Good examples include “policy section 4.2, paragraph 3” or “training register, rows 21–40.” “Interview” alone is usually insufficient. Origins identify independent sources; copies of the same original must retain a common origin when used in diagnosis.

Original evidence is immutable. If it is wrong or superseded, create a corrected source and retract the old one with a reason. Retraction preserves history, marks dependent records stale, and blocks affected client downloads. Review dependencies and generate fresh artifacts. A previously downloaded copy cannot be recalled by the application; follow the engagement’s distribution procedure.

Acceptance means the source has been reviewed for use. Known labels and accepted state do not automatically prove an allegation, establish authority, or resolve a conflicting account. Preserve competing evidence until the question is resolved.

## 8. Task cards and confirmation

A task describes one bounded piece of work. Enter the title, duty label, accountable owner, performer, purpose, trigger, inputs, instructions, output, systems, described allowed actions, denied actions, human checkpoint, stop conditions, evidence, mode, classification, review date, and change reason.

An incomplete proposed task can be saved while owner or performer is unknown. Review requires both people, supporting accepted evidence, no unresolved conflict, and a current review date. Do not invent a person to satisfy the form. Use the unresolved state as a discovery question.

| Displayed state | Meaning | Next action |
| --- | --- | --- |
| Proposed | Definition has not completed advisor review | Resolve fields and evidence; review |
| Awaiting confirmation | Advisor reviewed the current content | Ask current owner and performer |
| Human confirmed | Both required roles have accepted correct responses for this exact version/hash | Use the current description within its scope |
| Conflict open | A conflicting claim or participant objection remains | Clarify, revise, and request fresh confirmation |
| Needs fresh review | Source, version, or review date is no longer current | Refresh supporting information and review again |

Content edits create immutable versions. Confirmation includes record ID, version, content hash, person, decision, and advisor acceptance. Old confirmations remain in history and do not silently transfer to new text. An advisor cannot click a task directly into Human confirmed on behalf of a real participant.

If one person is both owner and performer, one valid current response satisfies both roles. If either role changes, the revised card needs the new required people. The roles concern accountability and performance of described work; a task’s allowed-actions list is not an enforced permission policy.

Work modes include human only, AI assist, AI draft, AI recommend, execute with approval, bounded execution, and prohibited. These modes describe a proposal for the work. Selecting an execution mode does not connect or authorize a runtime. The governance screen will continue to report unconfigured execution.

## 9. Duties and handoffs

The free-text duty label on a task helps group work. An explicit duty record adds its own owner claim, purpose, scope, task membership, sources, review date, reason, version and review state. Create and inspect explicit duties at the bottom of Task cards. A duty review does not inherit task confirmations or confirm every responsibility held by a person.

A handoff connects two different tasks. Enter the condition for transfer, exact output mapping, required receiving input, acceptance check, exception owner, timeout, maximum retries, failure action, sources and rationale. Review it against current task versions. An edit to a linked task or handoff can make the downstream workflow stale.

Handoff timeout and retry fields describe the receiving contract. The manual case engine uses the workflow’s step timeout and maximum-attempt settings. It does not independently run a handoff timer or trigger an external notification. Set both consistently and make the distinction clear in the engagement.

## 10. Graph and organization views

Connected shows responsibility from left to right: People → Duties → Tasks. Explore a duty or task to see its recorded owner and up to three related tasks. A person selection opens one of their duties. To see a task outside this view, select it in Explore. The task card shows its performer, which can differ from the accountable owner. Missing owners and unmapped duties remain visible as gaps. Human, AI, and AI + human review labels describe the recorded work mode; AI modes are proposals, not proof that an agent is running. Select a card for its human checkpoint, evidence, and other connections. The register retains records outside the picture.

Work flow shows the actual handoffs between task cards. It can span several duties and people. A task can contain a human checkpoint in its instructions; DutyGraph does not invent separate substeps from those instructions. The initial zoom keeps cards readable. Pan horizontally to continue along a long workflow, or select Fit to see the whole path.

Work flow follows actual recorded task-to-task handoffs. Choose a workflow to scope its steps; alternate paths sit below the first path at the same stage. This position is a layout choice, not a claim about which branch is usual. Select a connection label to open its full condition and handoff contract. Dashed connections need review. No execution order is invented where handoffs are absent.

Org & duties opens on a team-to-duty map. Select a team to see work it owns or performs. Task groups are labeled separately from explicit duty records. A complete expandable list sits below the map. By team shows person cards; Reporting chart uses the recorded manager hierarchy. The register is the text alternative to visual navigation.

The default camera frames the focused picture. Fit shows the whole bounded graph and may make a large graph small; Readable restores the default scale. Use plus/minus, Ctrl/Cmd+scroll, and drag-to-pan. Expand gives the canvas more space. Select a card to highlight adjacent arrows and inspect relationship labels. Explore or Focus connections changes the central record; the register remains the broader index.

The API allows a maximum of 150 returned nodes and depth four; the UI uses depth two for focus. It caps the source scan at 5,000 records and reports truncation. A partial graph is not a complete company map. The application falls back to authoritative records while the derived projection catches up, and displays pending events. There is no free-form graph query execution.

Reporting chart uses recorded manager relationships. Missing relationships remain unlinked. Team membership, task accountability, and reporting hierarchy answer different questions. In the original Cobalt scenario, no manager data was supplied, so the chart displays an explanation and the team view remains useful.

## 11. Workflows and manual cases

A workflow selects reviewed tasks and handoffs, an owner, purpose, join policy, step timeout, maximum attempts, and reason. The definition rejects cycles, duplicate paths, isolated tasks in multi-step flows, missing references, and invalid handoff conditions. This release models acyclic work; bounded retries happen on a step, not through a loop in the graph.

Review the workflow after its task and handoff dependencies are current. Review requires reviewed task descriptions and reviewed handoffs; it does not require participant-confirmed tasks to observe a manual case. Check the underlying task state when participant confirmation matters to your engagement.

Start a case with a title and input reference. The case pins the workflow version/hash and stores a copy of the definition. Root tasks become Ready; dependent tasks remain Blocked. Each step keeps attempt count, deadline, route choice and observer notes.

| Case action | What it records |
| --- | --- |
| Complete step | An advisor’s observation that the human work completed, with the routes whose conditions were met |
| Record failure | A failed or incomplete step and the reason; the case needs attention |
| Retry | Another manual attempt within the workflow ceiling; resets that step’s deadline |
| Close case | Cancellation with a reason; preserves the event history |

When completing a step with outgoing handoffs, choose at least one valid route. Unselected routes are skipped. An All join waits until incoming branches resolve and at least one active selected route exists. An Any join can proceed when one active selected route arrives. Use these deliberately: an Any join does not assert that every predecessor completed.

Past-deadline ready steps display escalation and cannot be marked completed without a permitted retry. Deadlines are derived from persisted timestamps, so application restart does not restart the clock. There is no background email escalation. A workflow or pinned work change blocks further progress until the definition is reconciled; an obsolete case can be closed with a reason and a fresh case started.

All case actions record human observations. They do not call an order system, release a supplier, execute an agent, or verify that an external side effect occurred.

## 12. Strategy and measurement

The framework registry defines the available analyses, source buckets, and upstream dependencies. In this release, the advisor writes the analysis, selects accepted evidence, saves it, and reviews it. The application pins exact source and upstream versions. Missing prerequisites block completion; changed inputs make downstream analyses stale. No provider-generated answer is represented as a completed analysis.

A constraint hypothesis records the pressure in one flow, a competing explanation, a global-throughput counterfactual, a discriminating test, supporting and disconfirming evidence, an owner, and a throughput unit. Record a test result before requesting diagnosis review. Readiness requires two independent accepted origins, a tested alternative, a discriminator result, and a measured baseline owned by the named owner. These are structural checks; the advisor must still judge test quality and causal strength.

The UI’s Reviewed diagnosis represents human review. The internal state name `signed_constraint` is not a managed cryptographic signature, permission grant, or proof of causation. Continue collecting disconfirming observations.

A metric defines the question, formula, unit, population, source, owner, baseline, target, observation window, missing-data reason, and guardrail. Unknown baseline is null with a reason, not zero. Record observations with a numeric value, timestamp and source locator. Observations are appended in new content versions.

An intervention links one candidate, owner and metric to a proposed change, prediction, stop conditions, and review date. Preserve the prediction before observing results. An outcome record freezes the intervention prediction and current measurement snapshot, then adds supported/falsified/inconclusive, window, coverage, confounders, interpretation, next action and sources.

Supported or falsified conclusions require observations. Inconclusive is appropriate when coverage or attribution is insufficient. Reviewing a falsified outcome returns the linked candidate to review-required state. The application does not rewrite the original prediction to match a result.

## 13. Agent governance

Create an agent proposal for named tasks under one accountable human. Tasks must share the selected owner. The proposal pins exact task versions and starts as Draft with empty requested, approved, provisioned and observed scope, and no runtime deployment.

Inspect the gap between the work description and actual customer authority. A title, reviewed task, org chart, application administrator account, or approved report does not supply business permission. Runtime preflight fails closed while identity, policy sources, signing and a tested target adapter are absent.

An agent package is a review artifact containing task instructions, constraints, exclusions, setup requirements and hashes. It does not contain usable grants or credentials, and cannot deploy an agent from this UI. Use the technical integration plan to scope a separately accepted connection.

## 14. Weekly review

Use the derived agenda to inspect returned responses, stale/conflicting tasks, missing baselines and manual cases needing attention. Check the broader record even when the exception list is empty: no recorded exception is not proof that every source or observation is current.

Create a decision/commitment with title, owner, decision, next action and due date. Open it later to mark completion after checking the result. Meeting decisions create follow-up work. They do not issue permission grants or send tasks to an external project-management system.

Bring the previous prediction, new observations, changed sources, open cases, and last commitments to each review. Write what changed, why the interpretation changed, and the next test. Generate the weekly client report after that review.

## 15. Client reports and internal exports

Client reports are Executive, Weekly or Audit packets. Enter the title, explicit audience, purpose, summary, decisions, next steps, limitations and selected records. Creation freezes the current contents and bindings in a Draft report. Draft preview is available for review; delivery download is blocked until approval.

Open the preview and check every selected record, state, date, statement, audience and limitation. Record an approval rationale for the exact version/hash. The server checks current bindings before approval and again before download. If a selected record or evidence changes, create and review a fresh report. Withdraw approval if the report should no longer be distributed.

An approved download is a ZIP containing a printable HTML report, structured JSON, CSV register, read-me and SHA-256 file checksums. HTML escapes source text and CSV protects against formula prefixes. This does not excuse review of free-text content for private or inappropriate material.

The audit report includes up to the latest 500 application events for the selected company. It does not include complete external execution logs, independently signed ledger checkpoints or provisioning receipts. Its explicit coverage statement must remain with the report.

Internal workspace snapshots include described tasks and their current states. Confirmed-work packets include only qualifying current confirmed tasks and explain exclusions. Agent packages include the selected proposal and its work bindings. These internal packets have different review and staleness behavior: they are historical frozen exports, not audience-approved client reports. Source retraction blocks their download; routine later task edits do not retroactively change their frozen contents. Generate a fresh packet when current work is needed.

No report action emails or publishes a packet. Download and use the approved delivery channel yourself. Log recipient, version, date, and distribution decision in the engagement’s agreed system. Downloaded files cannot be remotely revoked.

## 16. System status, retention and recovery

System & connections reports the local database, derived graph, audio storage, and unconfigured integrations. The projection can be repaired from authoritative records. Rebuilding it does not replay business actions. The operator uses the migration and encrypted backup tools described in OPERATIONS.

Typed content, record history and audit metadata persist until an operator executes a separately designed retention/deletion process. Raw audio is access-expired and purged by the local worker. The pilot does not implement comprehensive deletion, legal hold, customer-managed keys, or production object storage. Do not assume the displayed engagement retention statement changes these mechanisms.

If the application is unavailable, preserve local unsent drafts and ask the operator to inspect the server/database. Do not reset Docker volumes or delete the environment file as a troubleshooting shortcut. Recovery uses an authenticated encrypted backup and a separately retained encryption key.

## 17. Common recovery paths

| Symptom | Likely cause | What to do |
| --- | --- | --- |
| Save says version conflict | Someone changed the record or company revision | Refresh, compare, and save against the current version |
| Task cannot be reviewed | Missing owner, performer, accepted source, date or unresolved conflict | Open the task and resolve the named gap |
| Task stays awaiting confirmation | One required role, acceptance, version or hash does not match | Inspect requests and confirmation history; issue a current request |
| Invitation no longer works | Used, expired, rotated or withdrawn link | Sign in if enrolled; otherwise ask advisor for a replacement |
| Request expired | Due date passed in UTC | Advisor creates a fresh bounded request |
| Recording cannot start | Permission/device/browser issue | Check microphone permission or use a typed response |
| Clip upload interrupted | Connection or server interruption | Keep the draft; use Upload / resume |
| Framework is blocked | Upstream analysis or accepted sources missing | Complete and review prerequisites |
| Report cannot download | Draft, withdrawn or stale bindings | Review the exact draft or generate a fresh packet |
| Case cannot advance | Wrong step, expired deadline, retry ceiling, or changed workflow | Inspect the reason; resolve the condition or close and restart |
| Org chart is empty | No manager relationships recorded | Use By team or add verified roster relationships |
| Graph is partial | Bounded query or scan limit | Focus a smaller neighborhood and inspect the register |
| Runtime is blocked | No verified integrations | Continue work review; follow the separate integration plan |

When reporting a defect, include the page, record title and ID, expected result, actual result, timestamp, browser, and visible error code. Avoid attaching raw customer evidence, credentials, invitation URLs or backup keys to a public issue.


# Advisor playbook: execute an engagement A to Z

This playbook is the working procedure for an advisor. Use it with the Full user manual for screen-level instructions. The sequence describes a typical bounded engagement; the timing is illustrative and should be agreed with the sponsor.

## A. Qualify and prepare

Before the first session, write one sentence describing the result the client wants and one sentence describing the work in scope. “Understand standard order intake through release” is useful. “Transform the entire business with AI” is too broad to guide evidence collection.

Identify the executive sponsor, day-to-day work owner, data custodian, and people who perform the work. Ask where policy, actual system permissions, process documentation and execution records live. Distinguish access to a source from authorization to change a system.

For this local build, use synthetic or otherwise approved pilot information. The operator must complete the deployment, identity, source access and retention decisions before real client collection. Record unresolved setup dependencies in the engagement plan; do not assume a form setting has enforced them.

Prepare the engagement record and collection notice. Agree what the client will receive, who will see it, the intended review cadence, and the permitted delivery channel. Establish where the final package and distribution log will be stored.

Research public context before the meeting. Use Business research with operator-configured Exa, or capture public pages manually. Start with the official website, then inspect appropriate public sources for the offer, customers, footprint, people and recent changes. Keep source URLs and dates. Do not scrape private interviews into a public search query. Draft a short account with Known, Inferred, Assumed and Missing information distinguished; public leadership listings do not establish internal accountability.

Bring that draft to kickoff. Ask the team to correct it explicitly: “Here is what we found publicly. What is wrong, outdated or missing?” Preserve both the original public claim and the team's correction with their own origins. Treat suspected bottlenecks and inferred process steps as questions until evidence supports them. The current release collects sources through Exa but does not generate this synthesis with an AI model.

**Exit evidence:** reviewed scope; named sponsor and work owner; roster plan; source/visibility policy; exclusions; first review date; agreed deliverable audience.

## B. Run a bounded kickoff

Use four or five kickoff questions. Ask for a recent example, not only a general process description. Listen for the completed output, the business value of that output, demand conditions, places work waits, and decisions that require escalation.

Suggested opening: “We will first document how this work happens, then ask the people involved to check the description. We will test an explanation for delay before recommending a change. This interview does not grant system access or authorize automation.”

Record the sponsor’s preferred explanation as a hypothesis. Ask what evidence would show that another explanation is stronger. Name the output unit—released orders, accepted jobs, fulfilled requests—so later analysis concerns system results.

Create follow-up requests only where information is missing. Avoid asking every person every possible question. Preserve the exact request and original response. After acceptance, cite the source as an account from that participant, with an exact locator.

**Exit evidence:** a recorded kickoff account; explicit output measure or missing-baseline reason; initial flow boundary; competing explanation; prioritized evidence questions.

## C. Collect and assess evidence

Collect at least one concrete work walkthrough from someone who performs the work. Ask them to trace a recent item from trigger to output, including waiting, returns, workarounds, and handoffs. Ask the owner separately about exceptions and acceptance criteria.

Inspect documentary and execution sources where permitted. A policy describes intended rules; an execution record shows an observation; an employee account explains experience. Keep these types separate. Record exact source locations and independent origins. Repeated copies of a single document do not strengthen source independence.

When accounts conflict, preserve the conflict and identify the discriminating evidence. Example: one team says “approved” when another means “verified.” Ask what decision was taken, by whom, under which source, and what the receiving team expects.

Accept reviewed sources; keep uncertainty in the interpretation. Retract unusable sources with reasons and inspect the dependent stale records. Use the source policy when deciding what text can be included in any client-facing summary.

**Exit evidence:** a source register with origins and locators; named gaps and conflicts; sufficient information to draft concrete task cards. Unknown information stays unknown.

## D. Build the work record

Write one task per bounded trigger-to-output unit. Use verbs and observable outputs. “Manage procurement” is a duty; “Check that the supplier packet contains a tax form and bank verification reference” is a task.

For each task, name one accountable owner and the performer, describe inputs/instructions/output, identify systems, state human checkpoints, and list denied actions and stop conditions. Select sources and a review date. Save incomplete proposals when necessary, then resolve the missing owner or evidence before review.

Group tasks with a duty label. Create an explicit duty record when responsibility for that continuing area needs review. Define each handoff’s receiving condition, input/output mapping, exception owner and failure handling. A receiving check is more useful than an unlabeled arrow.

Inspect the company graph. Read the selected relationship labels aloud. Use By team to check coverage and Reporting chart to check recorded managers. Do not infer a manager from seniority, job title or task ownership.

**Exit evidence:** reviewed task definitions; an explicit list of remaining conflicts; meaningful receiving checks; no unexplained orphan work.

## E. Confirm with the people

Issue confirmation requests only after the task text is ready. Ask participants to review the exact current version and explain disagreements. Ensure that local account and invitation assurance match the training or pilot context; stronger real-client assurance is an operator dependency.

Review returned decisions. Correct responses count only after acceptance and only for the exact version/hash. Needs change, Not mine, and Unsure are valuable results. Resolve the issue, revise, and ask again. Do not change a participant’s response to improve the dashboard.

Explain to the client that “Human confirmed” means the relevant people accepted the described work. It does not mean a policy owner approved a permission grant, that a duty is fully confirmed, or that the task can run autonomously.

**Exit evidence:** current confirmation coverage; an exclusion list for unconfirmed/stale tasks; participant disagreement preserved in history.

## F. Test what limits progress

Define the system output and a plausible limiting mechanism. Record a leading alternative. Build a discriminator capable of separating them. For example, compare how much time orders spend waiting for intake corrections with time waiting for credit review, in comparable cohorts.

Define metrics before interpreting results: formula, unit, cohort, source, owner, window, baseline, target, missing-data reason and guardrail. Use null for a missing baseline. Do not substitute an estimate into a measured-baseline field without explaining its source and limitations.

Use framework analyses where they clarify the question. Write evidence-bound analysis and review prerequisites. The current product supports human-authored work; it does not supply autonomous diagnosis. Structural readiness checks are a floor, not evidence that the test is well designed.

**Exit evidence:** a testable hypothesis, alternative, discriminator, defined metric, and sufficient independent sources—or an explicit collection plan for what is missing.

## G. Plan a bounded intervention

Choose a small change that addresses the proposed mechanism. Name the accountable owner, prediction, measurement, stop conditions, and review date. Preserve the original prediction before collecting the result. Write what would lead you to stop, reverse or revise the intervention.

If assistance is being considered, create an agent proposal tied to exact work versions. Keep requested, approved, provisioned and observed scopes separate. Current export packages are drafts for review. Customer authority and live execution remain a separately configured and accepted integration.

Create a manual workflow only when task and handoff descriptions are current. Review its sequence and branch rules. A manual case can record what a human observed; it cannot verify an external action on its own.

**Exit evidence:** intervention record, preserved prediction, owner, observation plan, guardrails, reviewed workflow where useful, and explicit deployment boundaries.

## H. Observe, review and learn

Record observations with time and locator. Track manual case progress, failures and bounded retries. Inspect expired deadlines and stale workflow bindings. The advisor must arrange follow-up outside the application because this version does not send reminders or escalations.

At the weekly review, begin with changed evidence and unfinished commitments. Compare the prediction with actual observations. Ask about population changes, staffing, product mix, seasonality, concurrent changes, and other confounders. Avoid declaring causation from a before/after difference alone.

Write an outcome review. Supported, Falsified and Inconclusive are distinct judgments. A missed target with poor measurement coverage may be inconclusive; a credible discriminating observation can falsify the proposed mechanism. Preserve the frozen prediction and measurement snapshot. Reviewing a falsified outcome returns the hypothesis to review.

**Exit evidence:** dated observations, outcome interpretation with limits, decision/owner/next action, and next review date.

## I. Prepare and deliver the client record

Choose a report for its audience. An executive report emphasizes the decision and next action. A weekly report emphasizes changes, observations and commitments. An audit report identifies the application activity actually covered. Internal work and agent packets belong with implementation reviewers.

Select records deliberately. Write the summary in plain language: scope, what was learned, supporting observations, competing explanation, decision, next action, and limitations. Avoid unsupported claims of efficiency gains, complete coverage, verified authority, or successful deployment.

Preview the exact frozen report. Check names, dates, states, source locators, exclusions, audience, and unnecessary sensitive material. Record the review rationale. Download only when the current bindings pass. If evidence changes, regenerate and review a fresh report.

Deliver manually through the agreed channel. Record which version went to whom and when in your distribution log. Give the client a readable report and offer the structured register where it helps. Keep checksums with the original package.

**Exit evidence:** approved packet; delivery record; named owners and due dates; known limitations; agreed next engagement step.

## J. Close or hand over

Review open commitments and sources due for refresh. Name the continuing record owner. Explain how later changes invalidate confirmations or reports. Provide the client-facing material and the appropriate operator or implementation handoff separately.

Have the operator verify backup and restoration for the installation. Follow the engagement’s approved retention and distribution policy; this pilot does not implement comprehensive client erasure or legal hold. Record unresolved infrastructure or integration decisions in the technical backlog.

An engagement is ready to close when its agreed questions are answered or explicitly bounded, its outputs are reviewed and delivered, and each remaining action has an owner. A visually complete graph is not a substitute for those conditions.

## Suggested cadence

| Session | Main activity | Preparation | Output |
| --- | --- | --- | --- |
| Kickoff, 45 minutes | Bound outcome, flow and evidence questions | Initial scope and sponsor | Reviewed engagement and requests |
| Discovery, 2–4 focused interviews | Trace real work and exceptions | Roster and source policy | Accepted accounts and source register |
| Work review, 60 minutes | Resolve task and handoff descriptions | Draft work cards | Current reviewed work and confirmation requests |
| Diagnosis, 60 minutes | Compare mechanisms and measurement needs | Observations and alternatives | Testable hypothesis and bounded intervention |
| Weekly, 30 minutes | Check changes and commitments | Updated sources and cases | Outcome/decision and next action |
| Delivery, 45 minutes | Review findings and hand over | Approved report and exclusions | Client packet and continuing ownership |

These are facilitation suggestions, not service-level or delivery-time promises. Adjust the cadence to evidence availability and the agreed scope.


# Training workbook

Use this workbook to demonstrate that you can operate the application and reason about its evidence correctly. Complete exercises in a separate practice company. The prebuilt Northstar company is a reference answer, not a blank worksheet. All exercise data is fictional.

## Workshop plan

| Module | Time | Practice |
| --- | --- | --- |
| Orientation | 20 minutes | Explain the record types and four key distinctions |
| Scope and discovery | 40 minutes | Create engagement, roster and kickoff |
| Work and confirmation | 60 minutes | Write tasks, resolve disagreement, obtain current decisions |
| Relationships and cases | 35 minutes | Inspect org chart, define handoffs, complete and fail cases |
| Measurement and outcomes | 35 minutes | Test the explanation and preserve uncertainty |
| Client delivery | 30 minutes | Draft, review and inspect a package |
| Review and discussion | 20 minutes | Compare answers and identify improvement areas |

Allow breaks between modules. Pair participants so one plays advisor and the other plays a fictional participant in a separate browser profile. Rotate roles. A facilitator can shorten the workshop by inspecting the prebuilt example instead of recreating every record.

## Exhibit A: fictional order procedure

Standard orders need an item, quantity and customer reference. Sam checks intake. Robin records the credit-check result. Jamie owns the completeness and exception process. Sam records a release only when the complete order packet and passing credit result are available. Jamie reviews exceptions. This exercise excludes payments, changing credit limits and automatic release.

Alex is the executive sponsor. Jamie and Robin report to Alex. Sam reports to Jamie. These relationships are supplied as training roster facts; do not infer additional reporting lines.

## Exhibit B: invented practice observations

| Measure | Baseline cohort | Practice cohort |
| --- | --- | --- |
| Standard orders observed | 20 | 20 |
| Median intake-to-release duration | 10 hours | 8 hours |
| Credit review duration | Under one hour | Under one hour |
| Product mix | Mostly established items | More small, simple orders |
| Staffing comparison | Not recorded | Not recorded |
| Intended target | At most 7 hours | At most 7 hours |

These are invented aggregate values, not an empirical dataset. They are sufficient to practice recording observations and limitations, but do not establish an effect or provide source-level statistical verification.

## Exercise 1: bound the engagement

Create a company and engagement plan. Use the goal of understanding standard order delays without weakening credit controls. Record the exclusions in Exhibit A, four roster people, optional total headcount 24, source policy, audience and weekly cadence.

Write your answers before proceeding:

- What is the output unit?
- Who is accountable for the work and who sponsors the engagement?
- What belongs outside the scope?
- Does a roster of four establish coverage of all 24 employees?
- Which policy fields are descriptive in this version rather than technically enforced?

**Submit:** engagement record and screenshot or written summary of coverage.

## Exercise 2: preserve an account

Create a kickoff request for Alex using five relevant questions. Issue and open the link in the participant profile. Submit the fictional account, inspect it as advisor, and accept it.

- What proves the source’s origin in the application?
- Does accepting the response confirm the tasks?
- Was an email sent?
- What must you do if the invitation is already used?

**Submit:** request, response and resulting source IDs. Do not include the invitation URL or password.

## Exercise 3: resolve disagreement

Draft the intake task with Jamie as owner and Sam as performer, but deliberately say that Sam can change customer credit limits. Review and request confirmation. Have Sam choose Needs change and explain the error. Accept that response as advisor.

Revise the denied actions and instructions. Review the new task and issue current confirmation requests to Jamie and Sam. Inspect the history after accepting their responses.

- Why must the first disagreement remain visible?
- Which version do the new responses apply to?
- Can the previous correct response from Jamie confirm the revised text?
- Does the final Human confirmed state authorize an agent to act?

**Submit:** task version history, final state, and a two-sentence explanation of the authorization limit.

## Exercise 4: make the graph useful

Create the remaining two tasks and supplied manager relationships. Open Connected and select Jamie. Open Org & duties, compare By team with Reporting chart, and inspect Sam’s responsibilities.

- Which view best answers “What evidence supports this task?”
- Which view best answers “Who reports to Jamie?”
- What should appear when no manager is recorded?
- What does a truncation notice mean?

**Submit:** a written explanation of two arrows and one reporting relationship. Use the record inspector to verify the relationship direction.

## Exercise 5: observe a workflow

Create and review the duty, two handoffs and a workflow. Complete TRAIN-001 through all three steps. Create TRAIN-002 and record missing information at intake.

- Why must credit review remain blocked in TRAIN-002?
- Which route should be selected after a passing credit result?
- What happens when a ready step passes its deadline?
- Do the case controls call a real order system?
- What must you do if the pinned workflow is revised before the case continues?

**Submit:** one complete case and one case needing attention, each with useful observer notes.

## Exercise 6: interpret an outcome

Create the hypothesis that incomplete intake causes waiting, with credit capacity as the alternative. Define the metric and intervention prediction before recording Exhibit B’s observation. Create an Inconclusive outcome review.

- What does the arithmetic difference between 10 and 8 show?
- Did the practice result meet the 7-hour target?
- What confounders prevent a strong causal conclusion?
- Which new observation would help separate the two mechanisms?
- Why should the original prediction remain unchanged?

**Submit:** hypothesis, metric, intervention and reviewed outcome, plus a proposed next test.

## Exercise 7: deliver to the right audience

Create an executive report for Alex and Jamie. Select appropriate records and write a short summary, decision, next steps and limitations. Preview the draft and attempt to download before approval. Then review the exact audience and content and download it.

Inspect the ZIP. Locate the HTML report, JSON, CSV and checksums. Confirm that raw interview text and credentials are absent. In a separate practice report, change a selected record after drafting and observe the stale-binding rejection.

- Why does approval bind to exact content and audience?
- What needs to happen before a changed report can be delivered?
- Which package is appropriate for the sponsor, and which for an implementation reviewer?
- How will you record delivery when the application does not send it?

**Submit:** approved synthetic client packet and a manual delivery-log entry clearly labeled “training; not sent.”

## Final assessment

Explain the engagement to a fictional sponsor in five minutes. Show the work, the evidence, the strongest remaining uncertainty, and the next decision. Finish by opening a reviewed client report and identifying its audience and coverage limits.

An advisor is ready for supervised use when they can operate the flow, recover from disagreement and stale data, and explain the limits without prompting. The assessment is a training aid; it is not professional accreditation or production security acceptance.


# Facilitator guide and answer key

Use this guide after learners attempt the workbook. Grade the quality of the reasoning as well as the state displayed in the application. A learner who obtains green badges by inventing agreement has not passed the exercise.

## Preparation

Ask the operator to verify the app, database and current build. Run `npm run training` once if the reference Northstar company or example files are missing. Each run creates another clearly named company, so avoid repeated runs during the workshop.

Prepare separate advisor and participant browser profiles. Use fictional addresses unique to each group. Do not give learners a shared real-client account. Provide Exhibit A and Exhibit B from the workbook and set the expectation that they must not infer permissions, causation or coverage beyond the evidence.

## Exercise 1 answers

The output is a released standard order; the time metric is one measurement of the flow. Jamie is accountable for the work, while Alex sponsors the engagement. Payments, credit-limit changes, production credentials and automatic release are excluded. Four roster participants do not establish representation of all 24 fictional employees.

Visibility, engagement retention and timezone planning fields record intended policy. They do not implement fine-grained evidence ACLs, legal hold, a different server-audio retention period or automated scheduling. Learners should identify this distinction without assuming that a saved policy text enforces itself.

## Exercise 2 answers

The response retains the request, person, original content and submission identity; acceptance creates a source linked to that original. Acceptance does not confirm task cards. Issuing a link does not send email. A participant already enrolled should sign in; an unused expired or rotated link needs replacement by the advisor.

The local session and bearer invitation provide local account assurance only. Do not describe the flow as verified corporate identity or enterprise MFA. A good learner includes the limitation without dismissing the value of preserving exact local responses.

## Exercise 3 answers

The original decision shows the real disagreement in the exercise and explains why the work changed. New confirmations apply to the revised version and hash. Jamie’s previous response does not automatically endorse new wording. Human confirmed establishes that the named people accepted the description; it does not grant permission to an agent or alter customer-system access.

Expected progression: proposed card, reviewed card, request returned, accepted objection creates conflict, revised card, review, current owner/performer requests, accepted correct responses, Human confirmed. The exact version count depends on how many edits the learner made; assess the linkage, not an arbitrary number.

## Exercise 4 answers

Connected plus the inspector is appropriate for evidence relationships. Reporting chart is appropriate for manager relationships. Missing managers should remain unlinked with a clear explanation; team membership and senior titles do not justify invented lines. Truncation means the displayed graph is a bounded subset and must not be presented as the whole company.

Check arrow direction with the inspector: an owner is accountable for the task; a task is supported by evidence. A selected card can have incoming and outgoing relationships. The text labels should make the direction understandable without guessing from layout.

## Exercise 5 answers

TRAIN-002 has no completed intake and therefore lacks the receiving input for credit review. After a passing credit result, select the handoff to release only if the documented condition is met. An expired ready step needs attention and cannot be completed through the normal action until a permitted retry resets the deadline. Retry limits prevent endless repeated attempts.

Case controls record human observations; no external order is changed. A changed pinned definition blocks progress. Review the revised work and workflow, then close/restart the obsolete case when appropriate. Do not use retries to bypass a stale-definition error.

The handoff record’s timeout/retry fields describe the contract; case enforcement uses workflow step settings. Learners should set them coherently and understand that this version does not execute handoff-specific background timers.

## Exercise 6 answers

The invented median is two hours lower, a 20% arithmetic reduction relative to ten. It misses the at-most-seven target. That arithmetic is not evidence of a real client improvement. Different product mix, missing staffing information, small cohorts, and no source-level matched dataset limit interpretation.

A useful next test measures intake correction waiting and credit-review waiting in comparable order groups while recording staffing and error rates. A capacity explanation needs observations that distinguish it from missing-input rework. The original prediction remains unchanged so later reviewers can evaluate the intervention honestly.

Inconclusive is an acceptable and expected outcome. Do not reward a confident “supported” result based only on the attractive before/after number.

## Exercise 7 answers

Approval binds to the frozen report, exact version/hash, selected records and named audience. A changed source requires a fresh packet and review. An executive or weekly report is the usual sponsor-facing document; an internal confirmed-work or agent packet is for implementation/review audiences. Download alone is not a delivery record.

A training distribution log should say no message was sent. For an accepted engagement, the advisor records recipient, packet/version, date, approved channel and any acknowledgement in the agreed system. The application does not revoke copies that have already left the installation.

## Scoring rubric

| Competency | Points | Evidence of competence |
| --- | --- | --- |
| Scope and data boundaries | 15 | Clear outcome, exclusions, roster denominator, policy limits |
| Evidence handling | 15 | Original preserved; locator/origin; uncertainty retained |
| Work and confirmation | 20 | Specific work, exact version decisions, disagreement resolved |
| Graph and workflow | 15 | Correct relationship meanings, receiving conditions, safe case progression |
| Measurement and reasoning | 20 | Alternative and discriminator, preserved prediction, justified outcome |
| Client delivery | 15 | Appropriate audience, clear report, current review, manual delivery record |

Suggested pass threshold is 80/100, with no critical reasoning error. Critical errors include inventing participant agreement, treating a title or task as a permission grant, claiming a real measured improvement from the synthetic data, concealing a material source conflict, or distributing unreviewed sensitive content. Revisit the relevant module before retesting.

## Debrief prompts

- Which missing fact changed your next action most?
- Which apparent process disagreement was really a difference in vocabulary?
- What did the graph help you see that the register did not?
- Where was the register clearer than the graph?
- What would make the outcome supported or falsified rather than inconclusive?
- Which integration would need separate acceptance before this engagement used real customer systems?

Record product defects separately from learner mistakes. Include a minimal synthetic reproduction and visible error code. Never paste credentials, private invitations, or real source material into public issues.


# Client deliverables and example outputs

The deliverable is a reviewed explanation of the business record and the next decision. A client should be able to understand it without learning the application’s database structure. Keep the structured files available for reviewers who need traceability.

## Package choices

| Package | Intended audience | Typical contents | Review behavior |
| --- | --- | --- | --- |
| Executive client report | Sponsor and named decision owners | Scope, coverage, finding, decision, next action, limitations, selected work | Exact audience/content review before download |
| Weekly client report | Work owner and review participants | Changed observations, cases, commitments and next test | Exact audience/content review before download |
| Audit client report | Named governance/review audience | Selected records and latest 500 application event metadata | Exact audience/content review; explicit coverage limit |
| Internal workspace snapshot | Advisor and implementation reviewers | Described tasks, states, source metadata and exclusions | Frozen historical internal artifact |
| Confirmed-work packet | Work and implementation reviewers | Current qualifying confirmed tasks and excluded-task reasons | Frozen subset; no business authority conferred |
| Agent proposal packet | Authorized design/review team | Version-bound work instructions, constraints and setup requirements | Non-operative proposal; no grants or runtime deployment |

## What is in an approved client ZIP

`client-report.html` is the readable report. It uses a self-contained print layout and can be opened without the application. Use the browser’s Print / Save as PDF function for a paper copy.

`report.json` is the structured frozen packet. It contains the company scope, report audience and purpose, selected record fields, source revision, coverage and limitations.

`record-register.csv` is a concise index of type, title, version, state and record ID. `READ-ME.md` explains the audience and manual-delivery boundary. `checksums.json` lists SHA-256 hashes for the other UTF-8 files and the report record hash. A checksum detects changed bytes; it is not an independent approval signature or proof of who sent a file.

Raw source text, recordings, passwords, invitation tokens and person email fields are excluded by the client-report serializer. An advisor can still accidentally include sensitive details in a free-text summary or selected analysis. Inspect those fields before approving.

## The supplied Northstar examples

The portable handbook’s example index contains three actual API-generated client ZIPs and their readable HTML reports: executive, weekly and audit. It also contains the confirmed-work internal package and an agent-proposal internal package. The training manifest identifies the fictional company and the record states used to produce them.

These files were generated by creating a separate sandbox company, enrolling fictional participants through the local API, submitting and accepting exact confirmation responses, reviewing work and handoffs, recording manual cases, and approving the report audience/content. They were not hand-drawn mockups. No real participant decision or customer result is asserted.

The example shows four roster people, three Human confirmed tasks, one complete manual case, one case needing attention, and an Inconclusive outcome. The fictional median changed from ten to eight hours but missed a seven-hour target, with unmatched cohorts and missing staffing information. This is the kind of limitation the client should see clearly.

## Example executive message

“We have documented the standard-order flow and clarified the receiving checks between intake, credit review and release. The reviewed record identifies one incomplete case that needs Jamie’s attention. Incomplete intake remains a candidate explanation for delay; the current practice observations do not establish causation. We recommend collecting a matched cohort before expanding the change. All release decisions remain with people.”

For the supplied training packet, retain the explicit notice that all people and observations are fictional. In a real engagement, replace the language only with claims supported by that client’s reviewed sources and actual measurements.

## A useful delivery checklist

1. Confirm the named audience and purpose match the agreed engagement scope.
2. Confirm the company, date, source revision and selected records are correct.
3. Check that claimed confirmations and observations match their current states.
4. Explain missing coverage, conflicting sources, confounders and open decisions.
5. Remove unnecessary personal or sensitive details from authored narrative.
6. Preview the exact packet and record the approval rationale.
7. Download, open and inspect the readable report and register.
8. Deliver through the approved channel and record recipient, version and date.
9. Keep the original ZIP and checksums with the distribution record.
10. Regenerate and review a fresh report after material source changes.

The application performs the binding and state checks. The advisor remains responsible for the business meaning of the narrative, appropriate audience, and actual delivery decision.

## Suggested delivery meeting

Allow 30–45 minutes. Begin with the client’s desired outcome and the bounded scope. Show the work description and evidence only to the depth needed for the decision. Explain the strongest remaining uncertainty. Compare the prediction with observations, then agree the next action, owner and review date.

Use the graph to answer a relationship question, not as a decorative proof that the company is understood. Use the report’s selected records when the audience needs a stable reference. Finish with a written list of commitments and the limits of any proposed automation.

## Handoff to an implementation team

Provide the relevant confirmed-work or agent proposal package along with the approved scope, source policy and unresolved authority questions. The implementation team needs a separate accepted identity/permission model, exact target resources/actions, approval chain, runtime adapter and operational controls before any live execution.

Do not distribute the complete development repository as the ordinary client report. Source code and technical runbooks are a developer/operator handoff. Do not include `.env`, database backups, encryption keys, raw recordings or commercial reference documents in a public repository or generic client packet.


# Glossary and quick reference

| Term | Meaning in this application |
| --- | --- |
| Accountable owner | Person named as accountable for the described task or claim |
| Advisor review | Recorded human assessment of a record’s current completeness or meaning |
| Accepted source | Source reviewed for use; acceptance does not prove every assertion |
| Agent proposal | Draft assistance design bound to work versions, with no operative grant |
| Authority | Legitimate permission to act in a business context; separate from work description |
| Binding | Reference to an exact record version and hash used by another artifact |
| Case | One persisted instance of a reviewed manual workflow |
| Classification | Known, Inferred, Assumed or Missing label describing the stated basis |
| Company revision | Incrementing value identifying changes to the company’s record |
| Confirmation | A named participant’s decision about an exact task version/hash, later accepted by advisor |
| Constraint hypothesis | Testable explanation of what may limit overall output |
| Coverage | Explicit scope of roster, responses, tasks, observations or audit activity |
| Discriminator | Observation or test intended to distinguish competing explanations |
| Duty | Continuing responsibility that may contain several tasks |
| Evidence origin | Identity of the original source, used to avoid counting copies as independent |
| Export | Frozen internal record package; distinct from a reviewed client report |
| Framework | An evidence-bound analysis with defined upstream prerequisites |
| Guardrail | Condition that must remain acceptable while testing a change |
| Handoff | Contract describing what the receiving task requires and how exceptions are handled |
| Hash | Digest of canonical content or file bytes; not an approval signature |
| Human checkpoint | Described point where a person must review or decide |
| Idempotency | Retrying the same command key/content returns its prior result instead of repeating it |
| Intervention | Proposed change with owner, prediction, measure, stop conditions and review date |
| Locator | Reference precise enough to find the supporting passage or observation |
| Manual case observation | Advisor’s record of human work, not independent evidence of external execution |
| Outcome review | Interpretation against a preserved prediction and measurement snapshot |
| Performer | Person described as carrying out a task |
| Projection | Rebuildable graph metadata derived from authoritative records |
| Report audience | Explicit intended recipients whose names are frozen into a client packet |
| Roster | People in the bounded engagement; not necessarily the entire company |
| Source retraction | Removal of a source from current use while preserving history and marking dependencies stale |
| Stale | A record needs fresh review because its inputs, content or review period changed |
| Task | Bounded trigger-to-output work description |
| Tenant | Application isolation boundary for an account’s company data |
| Throughput | Completed system output per period, defined for the engagement |
| Workflow | Reviewed sequence and branches of tasks and receiving handoffs |

## Before clicking Review

Check the current version, required fields, evidence, accountable people, unresolved conflicts, and scope. State why the review is justified. If the source changed, refresh the derived record before reviewing it.

## Before saying Confirmed

Check that both required roles have accepted correct decisions for the current version and hash. Check the review date. Do not transfer a past confirmation to a new description.

## Before saying Improved

Check the formula, cohort, source, baseline, observation window, target and confounders. Distinguish arithmetic movement from causal attribution. If the source is synthetic, say so.

## Before saying Authorized or Deployed

The current local build does not establish either state for external business systems. A draft task, reviewed diagnosis, report approval or exported agent package does not change that. Consult the separate integration and production acceptance plan.

## Before sending a client packet

Check audience, exact content, current bindings, exclusions, and limitations. Download the reviewed packet, inspect it and use the agreed channel. Keep a distribution record; the application does not send messages or recall downloaded copies.


# Explore the Cobalt workflows

Cobalt Industrial Supply is fictional. Its interviews, people, policies and work descriptions are training examples. The examples contain no live agents, sent emails or measured business results.

Open **Workspace settings → Open my sample company**, then **Company graph → Work flow**. Reopening the sample adds the complete examples to an older Cobalt workspace. It enriches untouched original task descriptions, preserves revised or confirmed work, and does not reset your notes.

## Supplier onboarding

The intended outcome is a supplier ready for purchasing. Eight task cards and nine handoffs cover the usual path and two exceptions.

1. Start with **Check supplier packet**, then **Create draft supplier record**.
2. Click **Standard terms** to inspect the direct Finance route. Compare it with **Nonstandard terms**, which requires Legal review before Finance.
3. At **Verify bank details**, compare **Bank details match** with **Bank-name mismatch**. A correction must include an independent Finance recheck before the verification result can be recorded.
4. Inspect **Approve the supplier**. Its owner and performer are intentionally unresolved. Procurement describes verification as approval; Finance disagrees. This is a hypothesis about a source of delay, not a proven throughput constraint.
5. Click **Authorized approval**. Read the output mapping, required input and acceptance check. A completed bank check does not authorize activation. Elena owns the escalation, not the unresolved approval decision.
6. Open **Org & duties** to see complete records, bank verification, contract review, approval and activation responsibilities grouped around the work.

## Customer order fulfilment

Select **Customer order fulfilment** in the workflow picker. Seven task cards and seven handoffs connect a customer's purchase order to a checked shipment and dispatch confirmation.

1. Follow **Check customer purchase order → Check stock and delivery date**.
2. If stock is available, **Stock reserved** proceeds to pick release.
3. If stock is short, **Stock shortage** goes to Procurement. Click **Receipt + accepted date** to see the three required items: a replenishment receipt, a stock reservation, and the customer's acceptance of a revised date. An estimated arrival date alone does not qualify.
4. Both paths meet at **Release the order for picking**, followed by picking, dispatch and customer confirmation.
5. The suspected issue is waiting for a coordinated shortage release. Inventory availability and carrier capacity are competing explanations. No timings or percentage improvements are invented.

## What clicking means

- Click a task to inspect it; **Open full record** shows its input, output, performer, owner, duty, boundaries and sources.
- Click an arrow's label to open the actual handoff record, including acceptance criteria, timeout, retry limit and exception owner. Timeouts describe the proposed contract; they are not measured waiting time or an active agent timer.
- Dashed links are proposed handoffs that still need review. Fictional source acceptance does not imply participant confirmation, authority approval or deployment.
- **Workflows & cases** opens each workflow definition. A manual case requires reviewed current tasks, handoffs and workflow bindings. The supplier approval conflict deliberately prevents that readiness until it is resolved.
- **Agent governance** contains two proposals: Supplier Packet Assistant and Order Handoff Assistant. Both have named human owners and bounded drafting purposes. Neither runs tools, schedules jobs, releases business transactions or sends customer messages.

## A useful screenshot

Use the dark theme, a named workflow and **Expand → Fit**. Keep the workflow name and synthetic-data context visible. Capture the clean flow first, then a second image with a handoff or task inspector open. Avoid showing personal account details, API settings or private invitations.

The landing page should feature this genuine application screen immediately below the hero. The final screenshot composition and landing-page copy remain subject to the owner's design feedback.


# Read a task card in seconds

Open **Task cards**. Choose a workflow and browse Receive, Prepare, Check, Decide and Deliver. These are browsing categories; use Company graph for actual handoff sequence and branches. A task with no stage is shown under Not mapped. An empty column means no records match, not that the company definitely has a missing function.

The color and icon describe the recorded operating mode:

- **Blue / Human:** a person performs the work.
- **Violet / AI:** bounded AI execution is proposed.
- **Amber / AI + human review:** AI assistance, drafting, recommendations or execution with approval is proposed.

The review state appears separately. A proposed, reviewed or confirmed task does not establish that an agent is deployed. AI-generated descriptions start with human mode; the advisor deliberately chooses any proposed automation role.

Each card shows its duty, work product, accountable human, software, version and source count. Open it for the human instructions, proposed AI prompt, input/output contract, stop conditions, evidence, confirmations and version history. Edit the stage, prompt and software using **Edit record**. Changing the record still creates a new version and invalidates dependent bindings.

Software chips describe systems used by the task. Cobalt's SAP, Google Drive, Google Sheets, Gmail and Notion choices are fictional. Their logos are bundled with the app; neither a logo nor a task record verifies a connection or grants access.

Cobalt includes one bounded AI proposal and three AI-plus-human proposals alongside human work. The prompts explain allowed inputs and outputs, uncertainty handling and human review. No agent is activated or email sent by loading the sample.


# From evidence to a better result

The Strategy page connects five steps: collect evidence, record a possible constraint, define a test, try an intervention, and review the outcome. A framework helps ask a question. It does not prove the answer.

## Use the constraint ledger

Each card states the suspected limit, why it is suspected, another explanation, what would change if it were removed, and how to test it. The Cobalt sample has two hypotheses. Neither is a proven constraint. Compare independent accounts and actual work records before selecting a diagnosis.

The Strategy assistant uses the existing OpenAI connection. Select up to eight sources, approve sending those excerpts, and request hypotheses. Review a result for the ledger. Complete the owner, output unit and missing fields before saving. The assistant does not review its own diagnosis. The separate framework library can run all sixteen analyses in dependency order when you select **Run remaining sequence**; it does not run unattended.

## Define a KPI

A key performance indicator (KPI) is a measure used to judge progress. Record its question, formula, unit, population, period, source, owner, baseline, target and guardrail.

For supplier onboarding, separate approval waiting time from total onboarding time. For fulfilment, consider on-time complete orders, shortage waiting time and rework. Choose measures that test the suspected constraint and protect quality. Record whether elapsed time means calendar hours or business hours. A baseline is measured; a target is a choice with a stated basis. Missing is not zero.

## Compare with competitors

No verified competitor benchmark dataset is loaded. Public research can establish a competitor list and its advertised offer. It rarely proves private operational cycle times, margins or staffing productivity.

Before comparing a measure, match the formula, units, segment, geography, period and population. Keep the source, publication date, collection method and comparability limits. Separate internal performance, competitor observations, industry references and management targets. Do not average incompatible measures or use AI estimates as measured facts.

The present metric form supports the internal measure. A dedicated, source-linked competitor benchmark register and automatic feeds remain to be built. Keep reviewed benchmark research in evidence and cite it in Industry Map and Balanced Scorecard / OKRs until then.

## Set objectives and key results

An objective states the result the business wants. Key results state measurable changes and dates. Use Balanced Scorecard / OKRs to connect the objective to the KPI definitions in Measurements. Task counts are not usually business results.

Illustrative structure: objective — make supplier onboarding reliable. Key result — reduce the defined approval wait from a measured baseline to an agreed target by a named date, without increasing verification errors. Establish the baseline before choosing the numbers. Keep the actions needed to reach the result in duties and task cards.

## Describe an intervention

An intervention is a specific change made to test an explanation. Record the suspected constraint, exact change, human owner, measure, prediction, review date and stop conditions.

Cobalt example: propose a named approval owner and one decision queue. Predict that waiting for approval will fall. Check whether total completed supplier onboarding rises, not just whether one queue gets shorter. Stop if authority remains disputed or control errors increase.

An outcome review compares the recorded prediction with observations. State the observation period, coverage and other changes that could explain the result. Choose supported, falsified or inconclusive. With no baseline or observations, use inconclusive.

## Prepare a weekly standup

Weekly review now prepares four questions from the selected person’s current tasks and measures. The advisor can review them as a participant request. Saving does not send email. The existing invitation flow can send a reviewed request using Resend. Participants can type or record a response, create an editable OpenAI transcript, and check it before sending. Their advisor must have an OpenAI key configured for transcription. The four draft questions and response due date can be edited before preparing the request. Status counts show draft, sent and returned weekly requests.

The intended full cycle is:

1. Before the meeting, draft questions from changes, unresolved decisions and missing measurements.
2. The advisor reviews recipients and questions. An approved schedule sends one invitation per person and meeting.
3. Participants send short updates. AI drafts an agenda with source links, decisions needed and a time limit per speaker.
4. The team meets. Fireflies captures the meeting when the configured account and recording permissions allow it.
5. A verified webhook identifies the completed transcript. Import it with meeting, speaker and time references, deduplicate it, and route it to Customer calls or People & work according to meeting type.
6. A person checks the transcript and proposed decisions. Accepted evidence creates new analysis versions and proposed work. It does not silently change duties or authorize agents.

The rule-based request draft is implemented. The scheduled invitation cycle, Fireflies import, AI meeting agenda and continuous framework refresh remain integration work. Participant audio transcription is available on demand; it does not run unattended. Monday at 10 am was an example, not a configured schedule.

## Review frameworks when needed

Each framework has a specific AI instruction set, named input requirements, a visual canvas, and a suggested review frequency. Open a card to read its canvas, inspect citations and confidence, or run a saved analysis with OpenAI. Relevant accepted evidence, public research and current upstream analyses are included automatically. You do not need to select source checkboxes. Manual advisor analyses remain available.

Customer frameworks respond to new interviews. Operational constraints and KPIs need weekly review. External-environment frameworks usually need less frequent review unless a material event occurs. These are suggested review times, not active schedules.

The app detects changed inputs and marks affected saved analyses out of date. A changed upstream analysis also makes its downstream analyses out of date, through the full dependency chain. Every required upstream analysis must be current before a dependent run starts. **Run remaining sequence** updates ready analyses in order, skips current ones, and stops if a run fails. It can make up to sixteen provider calls; charges apply. Each run saves its model, prompt version, exact inputs, citations, output, provider usage and outcome. A run does not confirm a constraint or change authoritative duties.

Scheduled refresh, automatic change summaries and notifications remain future work. See [Live framework canvases](24-live-framework-canvases.md) for all sixteen layouts, input limits and version history.

Sources: [ASD-STE100](https://www.asd-ste100.org/about_STE.html), [Porter’s Five Forces](https://www.isc.hbs.edu/strategy/business-strategy/Pages/the-five-forces.aspx), [Fireflies signed webhooks](https://docs.fireflies.ai/graphql-api/webhooks-v2).


# Strategy reports and the copilot

Open Strategy to understand the business without reading each framework separately.

## Read a report

1. Add evidence in Discovery. Review it and mark it accepted. Choose Business context, Leadership input, Customer calls, or People and work. Run the relevant framework canvases when you want their analysis included too.
2. In Strategy, select **Read executive brief** for the whole company. Use **Read report** beside a framework group for a focused view.
3. Select **Generate with OpenAI**. The app uses the API key and model in your account settings.
4. Read the overall picture, findings, suggested next steps, and open questions. Select a source link to check the record behind a finding. A citation to a generated framework opens that exact saved canvas version.
5. Use report history to compare saved drafts. AI reports do not overwrite your framework analyses, confirm a constraint, create duties, or authorize work.

A report is an AI interpretation. Inferred means the AI drew a conclusion from the sources. Assumed means a premise still needs checking. Missing means the required information was not supplied. A source may describe a belief rather than an established fact. A framework analysis is also an interpretation; citing it does not make its conclusions primary evidence.

## Read the underlying frameworks

Select any of the sixteen framework cards to open its recognizable canvas or table. The canvas shows findings, data gaps, confidence notes, supporting sources and next questions. Its input section explains which variables the framework needs and what the supplied material actually established. Use the saved-version selector to compare earlier runs. Manual advisor analyses remain available inside the canvas.

Each framework uses its own system instructions. All required upstream analyses must be complete and current. **Run remaining sequence** runs ready frameworks in order using the account's OpenAI key. An upstream change marks its dependent analyses out of date recursively. Old versions remain readable, but reports and the copilot exclude generated frameworks whose inputs are no longer current. The framework sequence has a separate limit of 32 attempts per account in 24 hours. See [Live framework canvases](24-live-framework-canvases.md).

## Ask the copilot

Select **Ask the copilot** to open the side drawer. Ask one strategic question, such as “What could delay delivery, and which evidence should we check first?” Each answer uses current company context. Questions are independent: earlier chat answers are not silently treated as facts or added to the next request. Saved answers remain in history.

## Understand update alerts

The Strategy page checks report input status each minute while it is visible. A new accepted source, changed source, withdrawn source, or changed saved analysis can show **Inputs changed** beside an existing report. A newly completed current framework run can also change report inputs. This is a prompt to refresh the report. It does not claim that AI has already read the change. A copilot answer does not replace or mark the executive brief current.

Report generation runs when you press the OpenAI button. Reports do not run on a daily schedule yet. The app checks source IDs, versions, hashes, and status. It labels older reports when their input set changes, including changes to records outside the excerpt limit.

## Context limits

Each request can use 24 accepted evidence excerpts and 24 analysis/work excerpts. Each excerpt is limited to 4,000 characters. The executive brief reserves space for all 16 canonical framework analyses before recent work records. Group reports use their relevant evidence buckets and framework group. Reports disclose omitted records. Workspaces above 1,000 records require a narrower context feature before these reports can run. The account limit is 20 strategy attempts in 24 hours, separate from discovery drafts. OpenAI charges apply. Provider failures are not retried automatically.

## Find places to watch

Discovery → Research now includes Company overview, Customer communities, Competitors & their channels, and Industry news & feeds. Community searches include Reddit and professional forums. Competitor searches look for alternative providers and their public channels. Industry searches look for trade news and feeds. These searches use Exa and retain source links and dates. Results need advisor review; a discovered URL is not automatically a verified competitor or an active subscription.

## Collection workflow to build next

The intended recurring flow is: collect → remove duplicates → retain source and date → review incoming evidence → identify affected framework groups → generate reports → notify the advisor about material changes.

Fireflies imports, leadership voice-note transcription, RSS subscriptions, permitted social/community collection, and daily jobs are not connected in this release. They need account connections, an explicit source list, a timezone and collection cadence, stored cursors, retry limits, and a run history. New raw material must remain separate from accepted company evidence. A proposed future automatic-report setting should disclose its source scope and spending limit before it starts. Do not describe a feed or scheduled agent as active until a successful run is recorded.


# From business research to confirmed work

Discovery has five steps. Each step uses the information collected in the preceding steps. You do not select source checkboxes or choose a generic interview template.

## 1. Research and contact

Enter the public business name and website. All four research areas are selected by default: company overview, customer communities, competitors and their channels, and industry news and feeds. Each area uses one Exa request and returns up to five pages. The default selection uses four requests from the ten-request daily allowance. Finding a community or feed does not subscribe to it.

Read the results in Collected sources. Research text is available to the contact email and meeting guide automatically. Import is optional when you also want a page in the evidence history. Public research does not establish internal duties or reporting lines.

Enter the name and email of your point of contact. Add agreed meeting details if available. Choose **Draft contact email**. The draft asks the contact to invite the leaders who should attend, provide the participating people's names, emails and departments, describe responsibilities, and consider the company's goals, vision and problems. It does not assume supplier onboarding or any other internal workflow.

Edit the subject, message and preliminary questions. **Save contact request** creates a private request. Preview the branded email, then choose **Send invitation email**. Saving and sending are separate actions. The contact can speak or type answers on their private page. Their response appears in this discovery journey and the evidence history tools.

## 2. Leadership meeting

Choose **Prepare meeting guide**. The guide uses public research and the contact's actual reply, when available. It groups questions for the live discussion: scope, customers and value, goals, people and responsibilities, and next steps. The advisor uses the guide during the meeting.

After the meeting, paste the transcript or your notes into **Capture the leadership meeting**. Review the notes, then save them. These notes are accepted as the advisor's account of the meeting and become the source for team dossiers. They do not establish independent proof of every claim. Direct Fireflies import is not connected; paste an authorized transcript here.

## 3. Review the team

Choose **Build team dossiers**. AI extracts the people, departments, roles, manager emails and duties stated in the kickoff notes and contact reply. Missing information stays blank. Public research cannot create the internal roster.

Review each person's dossier. Correct an email or role, add a stated duty, or remove a mistaken suggestion. Every saved person needs an email, role and department. **Save reviewed team** records the roster and responsibilities. Existing work records remain available in the workspace; a new roster does not silently erase them.

## 4. Team interviews

Choose **Create question sets**. AI prepares one tailored interview for every person in the reviewed team. It uses their role, reviewed duties and leadership context. Questions ask about a real example: what starts the work, what is needed, what they do, the tools they use, what they produce, who receives it, and where decisions or delays occur.

Review the questions and email messages, then **Save all personal requests**. **Send pending team invitations** sends each person's private request in sequence. A confirmed email-service receipt is skipped on later batch attempts. An uncertain result stops the batch for review. Open each request to inspect its email preview, delivery attempt and original questions.

The recipient opens the private link and signs in or creates a participant password. Voice is preferred: a real example helps capture steps, exceptions and frustrations. Typing is also available.

After recording, they save the clip, create and check its transcript, and add it to their answer. **Create my task cards** uses the configured AI service to extract their work. They check the input, action, output, destination and software. Each card is marked **This matches my understanding**, **Remove — this is not my task**, or **I'm not sure — ask the advisor**. Edits require another check before sending.

Their original answer and reviewed descriptions arrive together. This is their understanding of the work, not company approval of ownership or agent permissions. If AI is unavailable, they can send the answer without cards for advisor review. See [Review your task cards before sending](25-participant-review.md).

## 5. Review task cards

Start with the descriptions people have already reviewed. Open their returned responses to see their original account, corrections and decisions. Retained cards are proposed tasks, with the participant as performer; accountable ownership still needs review. Removed cards remain in the response history.

Accept the original evidence after reviewing it. Resolve missing owners, overlapping responsibilities and handoff differences with the relevant people. This release does not automatically detect cross-team conflicts. **Draft task cards** remains available for answers sent without cards and for further analysis; check existing cards before saving more to avoid duplicates.

A participant's initial check records their understanding. Company-level task confirmation still uses the existing exact-version owner/performer rules. A changed description may need another check. Agent proposals come afterward; this process does not grant access or deploy an agent.


# Live framework canvases

Open **Strategy → Frameworks** to see the company through sixteen connected analyses. Each card opens the actual framework layout. You can inspect an empty canvas before supplying data, then run the analysis to fill it with the company's research and evidence.

## Start with the business model

1. Research the company in Discovery. Public search results are available to the framework automatically. They remain public claims, not confirmed internal facts.
2. Accept useful leadership, customer and employee evidence as the engagement progresses. Frameworks use the relevant evidence buckets and work records automatically.
3. Open **Business Model Canvas**. Read the nine sections and select **Run this framework**.
4. Review the summary, populated sections, input assessments, citations and open questions. Save your own interpretation with **Write advisor analysis** if needed.
5. Open the next available framework, or select **Run remaining sequence** to run ready analyses in dependency order. The sequence can make up to sixteen paid model calls. It skips current analyses and stops on a failed or uncertain result. **Stop after this analysis** allows the current call to finish and prevents another call.

The browser must remain open for the sequence to continue. An individual server request saves its result even if you leave the page. Reopen the framework to inspect its history before retrying an uncertain request. This is an on-demand action, not a daily or weekly automation.

## Understand the canvas

The opening summary explains the decision-relevant picture. Each finding names its basis:

| Basis | Meaning |
| --- | --- |
| Reported | A supplied source explicitly reports the point. This does not establish independent verification. |
| Inferred | The model draws a conclusion from the cited evidence. |
| Assumed | The model identifies a proposed assumption which needs a test. |
| Missing | The information is unavailable. It must not be filled with a plausible answer. |

Each finding also has Low, Medium or High confidence and a reason. Missing findings always have Low confidence. Confidence is an assessment, not a probability or a guarantee.

Select a **Source** link to see its title, version and location. **Read used excerpt** shows the exact text supplied to that saved analysis, even if the underlying record has since changed. You can also open the current internal record or original public page. A cited upstream framework opens its exact saved canvas version. Historical analyses retain their original citations, and strategy reports can reopen those versions too.

The input panel assesses each named variable as Found, Partial or Missing. Having a source available does not mean that it answers every input question. For example, a website may describe the offer without explaining margins or internal decision rights.

## The sixteen outputs

| Framework | What you see | Key input requirement |
| --- | --- | --- |
| Business Model Canvas | Nine connected business model blocks | Offer, customers, delivery and economics |
| Industry Map | Inputs → company → channels → buyers, with rivals and substitutes | A defined industry, region and value chain |
| Five Forces | Rivalry surrounded by entrants, suppliers, buyers and substitutes | Competitive structure within the chosen industry |
| PESTLE | Six external-change categories | Dated events, jurisdiction and company exposure |
| SWOT / TOWS | Four quadrants plus paired strategic options | Internal capability and external conditions |
| VRIO | Resource rows with four explicit tests | Capability proof and comparable competitive evidence |
| Ansoff | Existing/new product and market matrix | The company's current offer and served markets |
| Three Horizons | Core business, emerging growth and future options | Initiatives, capacity, learning goals and decision gates |
| Blue Ocean / ERRC | Eliminate, reduce, raise and create, plus a value-factor comparison | Customer decision factors and comparable offers |
| Jobs to Be Done | Situation, progress, workaround, forces and success | Specific buying or use episodes |
| Value Proposition Canvas | Customer profile and value map | Customer jobs, pains, gains and offer proof |
| Kano | Feature rows with category, sample, conflict and next question | Paired presence/absence research; otherwise features remain unclassified |
| McKinsey 7-S | Seven interrelated organizational elements | Leadership and employee accounts of how the business works |
| Balanced Scorecard | Financial, customer, process and capability perspectives | KPI formulas, sources, populations, windows, baselines and targets |
| Theory of Constraints | System output, suspected limit, alternatives and test | Demand, completed output, queues, waits and rework |
| RACI | Work rows with responsible, accountable, consulted and informed roles | Named people and supported responsibility or authority |

Five Forces addresses industry competition. PESTLE addresses broader external changes. The constraint analysis addresses the factor that may limit the company's total output. These should not be treated as interchangeable labels.

## Dependencies and changes

The canonical registry defines the execution order. A framework waits until **all** of its direct upstream analyses are current. A completed, reviewed advisor analysis can also satisfy a prerequisite. An unfinished or stale manual analysis cannot.

Direct upstream artifacts are passed in full. Other current framework summaries provide orientation only; they are not independent evidence. The server binds each run to the exact source versions, hashes, prompt version and upstream run IDs. A source change, withdrawal or upstream rerun marks affected downstream analyses stale recursively. The old versions remain available for comparison; they do not silently become current again.

The Theory of Constraints analysis joins eight upstream frameworks. It is not run from a single isolated observation. Its result remains a hypothesis for human review and does not sign a diagnosis or change a task card.

## Model and data limits

Each account can reserve 32 framework attempts in 24 hours. Retries with the same command key do not make another provider call. The application does not retry a failed provider call automatically.

Context includes up to sixteen accepted evidence excerpts, twelve structured work records and twelve public research excerpts, plus complete direct upstream analyses. The current research window is the fifty latest completed research runs. Evidence excerpts are limited to 5,000 characters and public research excerpts to 4,000. The page displays omitted-source and excerpt notices. Companies above 1,000 records need a narrower engagement before running this build's frameworks.

Prompts require source citations and visible uncertainty, reject missing or unexpected sections and columns, and prohibit invented measurements, benchmarks, quotations, owners or approvals. Schema and citation validation reduce invalid outputs; they cannot prove that every model conclusion is correct. Review the evidence before making a decision.

AI versions are separate from advisor-authored framework records. They do not edit the company roster, assign duties, send emails, activate an agent or apply an intervention.

## Method references

The recognizable layouts and analytical distinctions follow the methods' published descriptions: [Strategyzer's Business Model Canvas](https://www.strategyzer.com/library/what-is-a-business-model), [Strategyzer's Value Proposition Canvas](https://www.strategyzer.com/library/achieve-product-market-fit-with-our-brand-new-value-proposition-designer-canvas), [Harvard Business School's Five Forces](https://www.isc.hbs.edu/strategy/business-strategy/Pages/the-five-forces.aspx), [McKinsey's 7-S framework](https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/enduring-ideas-the-7-s-framework), [McKinsey's Three Horizons](https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/enduring-ideas-the-three-horizons-of-growth), [the ERRC grid](https://www.blueoceanstrategy.com/tools/errc-grid/), [Christensen Institute's Jobs to Be Done](https://www.christenseninstitute.org/theory/jobs-to-be-done/), [Balanced Scorecard Institute's four perspectives](https://balancedscorecard.org/bsc-basics/articles-videos/the-four-perspectives-of-the-balanced-scorecard/), and [Lean Enterprise Institute's Theory of Constraints](https://www.lean.org/lexicon-terms/theory-of-constraints/).


# Review your task cards before sending

Your advisor wants your best understanding of the work. You do not need a polished explanation.

## Try it without an account

Open the [five-person walkthrough](/?demo=discovery). Choose a teammate and follow the invitation, private page, answer, card review and advisor inbox. It uses fictional information. It sends no email and uses no microphone.

## 1. Open your invitation

Use the private link in your email. Check your name and company. Create a password on your first visit, or sign in. Do not forward your link. Read the notice and questions before answering.

## 2. Describe a real example

Voice is preferred: a real example helps us capture the steps, exceptions and frustrations. You can type instead.

Start by listing your regular duties and the tasks within each one. A duty is an ongoing responsibility. A task produces a specific result; its actions explain how to produce that result. Describe each task using these five points:

- What you receive to start the task.
- What you do with it, including checks and exceptions.
- What the finished result looks like.
- Which person, team or system receives the result.
- Which software you use.

Say when something is unclear or different in practice. Your account can differ from a colleague's account. The advisor can review those differences later.

## 3. Save and check your answer

Choose Save recording to upload a completed clip. If AI transcription is configured, create a transcript, correct it and add it to your answer. You can also write the answer yourself. Keep the original recording attached.

Text drafts and card edits save on this device when browser storage is available. Use the same device and browser to return. Do not clear browser storage before submitting. A saved draft is not a submitted response.

## 4. Create and review your cards

Choose Create my task cards. This sends your answer and assigned work context to the company's configured AI service. AI can draft several task cards under one duty. There is no required count. Cards open as readable instructions; use Edit only when needed. Review every description before choosing a response:

- **Approve:** the card describes the work as you understand it.
- **Edit:** correct the description, save your edits, then approve the card.

Changing a card clears its decision so you can check it again. If you change the original answer, create or review the cards again. This is not approval of company policy or permission for an agent to act.

## 5. Send everything together

Choose Send my response. Your original answer and reviewed cards arrive together. Wait for the receipt message before closing the page.

If AI is not connected, or a draft cannot be produced, select Send my answer for advisor review without task cards. Your advisor can help with the next step.

## What the advisor does next

The advisor opens your returned response, checks the original evidence and sees your card decisions. Retained cards are proposed work records. The advisor resolves missing owners and differences between teams. A changed description or company-level confirmation can require a further check. Automatic cross-team conflict detection is not active in this release.

In the public walkthrough, Maya returns six separate tasks. The advisor sees three prepared AI-assistance recommendations, two human tasks, and an approval-ownership gap. Only approved, unchanged candidate descriptions can enter the simulated governance preview. Edited descriptions need a fresh suitability review. This preview lists requested work and checks still needed; it grants no scopes, issues no agent, and does not save a live governance request.

## Review the team in the public walkthrough

The advisor inbox starts with people and compact task cards. Select a returned teammate, filter for AI candidates or gaps, and expand a card for its inputs, actions, handoffs and software. The original transcript stays closed until you open it.

Choose **Load remaining sample responses** to complete the fictional five-person team without replacing responses you already reviewed. Then choose **Review sample team findings**. Prepared examples highlight an unresolved approval owner, a possible missing handoff account, and a shared-software process worth investigating. These are not results of a live AI analysis, confirmed conflicts, measured bottlenecks, or proof of duplicate software spending. Edited source cards are excluded from prepared findings until a fresh review.

The handoff view shows selected sample paths, not a complete company graph. Click a task to inspect its source card. Select the findings to discuss, choose **Prepare all-hands readout**, add notes, and download the meeting draft before leaving the screen. The readout includes an agenda, decision questions and proposed actions for the client meeting. Downloading does not send invitations or client messages.


# 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](/?demo=discovery) and [participant guide](25-participant-review.html) 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).

| Skill             | Evidence to inspect                                          |
| ----------------- | ------------------------------------------------------------ |
| Scope             | One workflow and explicit exclusions                         |
| Kickoff           | Questions address gaps rather than assume answers            |
| Roster            | People and duties trace to leadership input                  |
| Participant flow  | Correctly demonstrates prepare, send, answer, review, submit |
| Evidence handling | Preserves original accounts and sources                      |
| Task review       | Distinguishes personal understanding from company authority  |
| Diagnosis         | States uncertainty and a way to test the finding             |
| Delivery          | Readout 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.


# Classify the business and shape its operating flows

In Discovery, Research & contact and Leadership meeting both include **What kind of business is this?** The library contains 52 proposed operating models across services, technology, commerce, production, the built environment, transport, consumer services, care and education, financial services, and public/mission delivery.

An industry describes the market. An operating model describes how work delivers value. A company can therefore be an industrial supplier with distribution, manufacturing and service flows. Choose one or several templates, or create a custom flow. Eight flows per company and sixteen stages per flow are currently supported.

Every stage maps to a common function: Get work, Shape work, Commit work, Do work, Collect value, Keep/grow customer. Templates use appropriate names. Manufacturing's source, make and ship stages all support Do work; they do not silently become shape, commit and collect based on their position. Mission and public-service templates use outcome/funding language.

Search or filter the library, preview the stages and add a flow. Rename the flow or stages, reorder them, add/remove stages and adjust their common function. Save as proposed for kickoff discussion, or save as advisor reviewed after checking the fit. Editing a reviewed profile returns it to proposed. Advisor review is not an assertion of client approval or task confirmation.

Industry Map's **Operating models & business flows** section uses the same template identifiers, cites research, and can suggest several models. Current saved suggestions appear in the profile panel. Selecting a suggestion adds a proposed template; it never overwrites the company's profile automatically. Generate or refresh Industry Map explicitly using configured research and AI providers. No paid research or generation is triggered by browsing templates.

The saved profile is stored per company, version-checked and audited. Discovery uses it as context and asks leadership to validate the fit. Framework context includes the profile; profile changes make dependent analyses stale. Templates do not create duties, tasks, permissions, metrics or measured bottlenecks. These flows provide the company-level foundation for a future Company Flow Map; they are not yet linked to operational task chains.

## Starter library

- **General business** (General): Attract → Qualify → Commit → Deliver → Collect → Retain
- **Advisory & consulting** (Services): Prospect → Diagnose → Propose & agree → Deliver advice → Invoice → Expand
- **Professional services** (Services): Develop demand → Scope work → Agree engagement → Deliver service → Bill → Maintain relationship
- **Marketing & creative agency** (Services): Attract clients → Develop brief → Agree campaign → Create & deliver → Invoice → Optimize & renew
- **Legal practice** (Services): Receive inquiry → Assess matter → Agree engagement → Perform legal work → Bill → Maintain relationship
- **Accounting & bookkeeping** (Services): Attract clients → Assess records → Agree engagement → Prepare & review → Bill → Renew engagement
- **Engineering & design** (Services): Identify project → Develop requirements → Agree scope → Design & validate → Invoice → Support next phase
- **Managed IT & security services** (Technology): Attract clients → Assess environment → Agree service → Operate & support → Bill → Review & renew
- **Software as a service** (Technology): Market → Qualify & sell → Subscribe → Onboard & serve → Bill → Renew & expand
- **Licensed software** (Technology): Generate demand → Evaluate fit → License → Deploy & support → Collect fees → Upgrade & renew
- **Custom software development** (Technology): Find projects → Discover requirements → Agree delivery → Build & release → Invoice → Maintain & extend
- **Marketplace & brokerage platform** (Commerce): Attract both sides → Match supply & demand → Confirm transaction → Facilitate fulfillment → Collect fees → Drive repeat use
- **E-commerce** (Commerce): Attract shoppers → Merchandise & select → Place order → Fulfill & deliver → Settle payment → Support & repurchase
- **Physical retail** (Commerce): Attract shoppers → Assist selection → Complete purchase → Provide goods → Settle receipts → Support & return visits
- **Wholesale & distribution** (Commerce): Develop accounts → Quote availability → Confirm order → Source & fulfill → Invoice & collect → Replenish accounts
- **Discrete manufacturing** (Production): Forecast demand → Plan production → Confirm orders → Source materials → Make → Ship → Bill → Support
- **Process manufacturing** (Production): Forecast demand → Plan batches → Commit supply → Source inputs → Process & test → Release & ship → Bill → Support
- **Contract manufacturing** (Production): Find programs → Engineer & quote → Agree production → Source & manufacture → Deliver → Invoice → Extend program
- **Agriculture & food production** (Production): Assess demand → Plan growing cycle → Commit supply → Grow & harvest → Grade & distribute → Collect → Plan next cycle
- **Mining & resource extraction** (Production): Identify demand → Assess resource & plan → Agree supply → Extract & process → Transport → Collect → Maintain supply
- **Construction contractor** (Built environment): Find projects → Estimate & plan → Contract → Build & inspect → Invoice & collect → Maintain relationship
- **Property development** (Built environment): Identify opportunity → Assess & design → Secure commitments → Develop & deliver → Sell or lease → Manage next phase
- **Real estate brokerage** (Built environment): Generate leads → Match property & need → Agree transaction → Coordinate closing → Collect commission → Maintain relationship
- **Property management** (Built environment): Attract owners & tenants → Assess property → Agree management or lease → Operate & maintain → Collect & account → Renew
- **Field service & trades** (Services): Receive inquiry → Diagnose & quote → Book work → Dispatch & perform → Invoice → Maintain & return
- **Repair & maintenance** (Services): Receive item or request → Diagnose → Approve estimate → Repair & test → Collect payment → Follow up
- **Staffing & contingent labor** (Services): Find employer demand → Source & qualify talent → Agree placement → Deploy & manage time → Bill & pay → Extend assignment
- **Recruitment & executive search** (Services): Find hiring needs → Define role & search → Agree engagement → Assess & place → Collect fee → Support retention
- **Business process outsourcing** (Services): Find accounts → Design service → Agree transition → Operate process → Bill → Improve & renew
- **Freight brokerage & forwarding** (Transport): Find shipping demand → Plan route & quote → Book shipment → Coordinate movement → Settle & invoice → Retain shipper
- **Transport carrier** (Transport): Find loads or passengers → Plan capacity → Book service → Move & deliver → Collect → Retain accounts
- **Warehousing & fulfillment** (Transport): Develop accounts → Design storage & service → Agree contract → Receive store pick & dispatch → Bill → Optimize & renew
- **Hotels & lodging** (Consumer services): Attract guests → Select stay → Book → Host & serve → Settle bill → Encourage return
- **Restaurant & food service** (Consumer services): Attract guests → Choose order → Confirm order → Prepare & serve → Collect payment → Encourage return
- **Healthcare practice** (Care & education): Receive referral or inquiry → Assess needs → Arrange care → Provide & document care → Bill & reconcile → Follow up
- **Hospital & care network** (Care & education): Receive referral or arrival → Triage & assess → Plan care → Treat & coordinate → Bill & reconcile → Follow up
- **Education & training** (Care & education): Attract learners → Assess fit → Enroll → Teach & assess → Collect fees or funding → Support progression
- **Research organization** (Care & education): Identify question & funding → Design study → Approve project → Research & validate → Report & account → Extend research
- **Insurance agency & broker** (Financial services): Find clients → Assess needs → Bind placement → Service policy → Collect fees → Renew & remarket
- **Insurance carrier** (Financial services): Attract risks → Assess & price → Bind coverage → Administer & handle claims → Collect & reconcile → Renew
- **Lending** (Financial services): Source applicants → Assess application → Agree financing → Fund & service → Collect repayments → Retain relationship
- **Payments services** (Financial services): Acquire merchants → Assess fit → Agree service → Process & reconcile → Collect fees → Retain & expand
- **Investment management** (Financial services): Develop relationships → Assess mandate → Agree mandate → Manage & report → Collect fees → Review & retain
- **Nonprofit & mission delivery** (Public & mission): Identify community need → Design program → Secure commitments → Deliver mission → Account for funding → Sustain relationships
- **Public services** (Public & mission): Identify public need → Assess eligibility & plan → Authorize service → Deliver service → Account for resources → Review outcomes
- **Membership & associations** (Consumer services): Attract members → Explain fit → Join → Deliver benefits → Collect dues → Renew membership
- **Events & experiences** (Consumer services): Attract audiences & sponsors → Design experience → Book or register → Produce event → Settle revenue → Build next event
- **Media & publishing** (Technology): Build audience → Plan content or campaign → Secure subscriptions or advertisers → Produce & distribute → Collect revenue → Retain audience
- **Telecommunications** (Technology): Generate demand → Qualify coverage → Contract → Provision & operate → Bill → Support & renew
- **Utilities & infrastructure services** (Production): Forecast need → Plan capacity → Authorize connection → Supply & maintain → Meter bill & collect → Support continuity
- **Franchisor & network operator** (Commerce): Attract operators → Assess fit → Agree franchise → Launch & support locations → Collect fees → Develop network
- **Equipment rental & leasing** (Commerce): Find demand → Match asset & term → Reserve or contract → Deliver maintain & return → Bill → Renew or re-rent


# Company Work Map

Open **Company Work Map** in the sidebar. The first tab shows recorded flows, their tasks, and accountable people. Business-type templates help discovery; they do not create evidence that a company follows a particular process.

Choose **Ownership & gaps**, **AI opportunities**, or **Work only**. These highlights do not move the layout. Click a task to read its inputs, actions, output, software, human decision and evidence. Open its full record to review or change it.

Columns follow recorded dependencies; multiple tasks in a column are branches. The handoff list names the actual source, destination and condition. Visual proximity never establishes a dependency. Connections between flows appear only when an explicit handoff exists. Tasks not yet assigned to a flow remain accessible below the map.

**Follow a work item** opens an individual recorded case. A case is distinct from its workflow definition and task descriptions. Fictional examples carry their own label. The map does not invent waiting counts, average times or system activity coverage.

**Priority to investigate** surfaces a recorded constraint hypothesis, not a measured company bottleneck. Inspect its alternative explanation and proposed measurement before presenting a conclusion.

**Prepare client readout** brings ownership decisions, delay hypotheses and AI scope proposals into a meeting sequence. Review findings with the company, agree an action owner and a measurement window, then use Weekly review and Deliverables to follow through.

Participant confirmation means a task reflects their understanding. Proposed AI scope, company approval and enforced system permissions remain separate. This view does not issue or execute an agent.

Org & duties retains the CSV reporting chart. Relationships and Agents & controls remain available for focused investigations. PostgreSQL remains authoritative; Neo4j remains a derived relationship projection. The Work Map can display workspace records even when the graph connection is unavailable.