Duty Graph advisor handbook
Explainer, walkthrough, full user manual, playbook, training workbook, facilitator answers, client deliverables and glossary.
Hosted pilot: start here
Release 0.3 provides hosted advisor workspaces, a private synthetic sample, encrypted account API-key settings, discovery drafts and invitation email. The current path begins in Discovery and ends with reviewable work records. This remains a pilot, with the production gaps listed below.
First visit
- 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.
- Open Workspace settings → Explore a fictional company → Open my sample company. Cobalt is clearly synthetic and private to your account. Loading it does not send email or call AI/search providers. Reopening returns the same sample, preserving your edits.
- Open Company Work Map. Select a business stream and stage to highlight the recorded organization, then select a person to see their duties, tasks and flows. Work with no stage, no owner or a removed stage remains visible for repair. The map uses explicit assignments; it does not infer membership from a title, department, reporting line or task value stage. PostgreSQL holds the authoritative records. Optional Neo4j Aura can project the graph, with current PostgreSQL records available when Aura is absent or behind.
- 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 the shared compact company snapshot and its proposed business streams. Review the public findings, then draft the preparation email to your point of contact. Save and preview it before sending the private link. The contact opens the kickoff preparation page without an account: they can correct the snapshot, upload a CSV or add the roster manually, connect managers, nominate executive attendees and pilot participants, and share leadership context by typing or voice. The advisor reviews the returned package before importing people or preparing the two-hour leadership meeting.
After the meeting, save the guided notes, review the team dossiers, create one tailored work request per selected pilot participant, and choose which recipients to email. The send review lists the exact people and addresses; previewing or saving a request does not send it. Work response links also open without an account. Each recipient can type or record a response, transcribe a short clip when enabled, review the text, and send it. The advisor then reviews the account and task cards, resolves gaps and ownership, and confirms the exact current work when needed.
Read From business research to confirmed work 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
- Add or review the person with their correct email address. Prepare a work-capture or exact-task confirmation request in Discovery.
- Review the questions, recipient, due date and privacy notice. For a team batch, select the people explicitly and use the review screen to check the final recipient list. Configure Resend's verified sender in Settings first.
- Open the request and click Send invitation email. This is the action that sends email; preparing a request, previewing the response form or generating a manual link does not send one.
- 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.
- The recipient opens the private seven-day link without an account or password, reads the notice and answers the assigned questions. They can type or record up to three minutes per clip. When enabled, Transcribe into my response adds editable text; they review it before sending. The recording stays in the page until it is transcribed or discarded. Text drafts save on the same device. A failed transcription keeps the recording and allows another attempt or a typed answer.
- After submission, the advisor sees the returned request in Discovery and reviews it. A response records the person’s account; it does not confirm company ownership, approval or permission to automate. Task cards remain proposed until the advisor reviews them and obtains any required exact-version owner and performer confirmations.
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 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.3 is a hosted advisor pilot with PostgreSQL persistence. It supports a human-led engagement, password-free kickoff and work-response links, and manual workflow observation. External provider quality, enterprise identity, customer-system authority and execution acceptance remain separate concerns. The application will not perform business actions in customer 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
- 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.
- Gather accounts. Review the roster, nominate kickoff attendees and pilot participants, issue private links to selected recipients, and collect typed or recorded responses.
- Review evidence. Check the original, its locator, its origin, and the limits of what it supports.
- Describe the work. Write task cards, identify accountability and performance, define duties and receiving checks.
- Confirm and connect. Ask the named people to review exact task versions; assign duties and tasks to saved business stages; use the Work Map to follow stage → person → duty → task → flow.
- Test the explanation. Record a constraint hypothesis, competing explanation, metric, intervention, and outcome.
- Review progress. Observe manual cases, resolve exceptions, and assign the next useful action.
- 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 |
Three ways to inspect the same work
Work map starts with saved business streams and stages. Select a stage to highlight people whose recorded work belongs there, then inspect their duties and tasks. Reporting lines come from the roster. Stage links, responsibility and manager relationships describe different things; none grants approval.
Work flows shows recorded task order and handoff conditions. Choose a workflow and inspect an arrow to read what the next person needs. A nearby card or arrow layout is not evidence of an unrecorded process.
Tasks provides the detailed task cards, filters and supporting registers. Open a task or duty to inspect its evidence, human checkpoints, versions and related records. Agent proposals and controls have their own governance tools.
These three views replace the separate Connected, Org & duties and graph/control tabs. Use Client brief to move from detailed work into coverage, findings, commitments and a report for a named audience. The graph is an inspection tool; it does not create truth, authority or causation.
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 Discovery from the Help & training page. Use the clearly labeled Cobalt guided example or the generated Northstar Parts training company to inspect synthetic 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 the clearly labeled Cobalt sample or the generated Northstar Parts — Advisor Training company. If Northstar is absent, ask the operator to run npm run training from the repository; that creates a new synthetic company and regenerates the example files. It does not replace Cobalt.
To practice writing records, 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
- Open Discovery, then Engagement & kickoff.
- Create the engagement plan. Enter the outcome, dates, systems, locations, in-scope work, exclusions, source policy, visibility, retention expectation, review cadence, and timezone.
- Save, inspect the record, and record your review rationale.
- In Discovery’s people view, add the four people below. Add managers before their direct reports, or use the CSV preview and import flow.
- 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.
- In Discovery, use the saved business snapshot and choose Alex as the contact, with a due date and four or five kickoff questions. The default five cover customer value, output, demand, flow, and authority.
- Save the reviewed request and open Preview response form. Review the notice and questions before sending.
- Choose the link-issuance action. No email is sent by issuing a link. Copy the URL only into the approved training browser session.
- Open the link in a separate browser profile. The current kickoff form needs no account or password. Keep the advisor session open in the original profile.
- 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.
- Submit. Back in the advisor session, refresh Discovery, open the returned response, inspect it, and accept it.
Checkpoint: the original response remains visible. Acceptance creates an evidence record tied to that submission. It does not confirm any task or authorize automation.
4. Review two more sources
Add an evidence record named “Training order checklist,” classified as a policy document. Its text says that intake must contain the item, quantity, and customer reference; credit review records a result; release requires a complete checked packet. Use locator “Training workbook, exhibit A, steps 1–3.” Accept it after inspection.
Add “Training queue observations” as an execution record. Its fictional baseline is a median of 10 hours for 20 standard orders; a practice cohort of 20 has a median of 8 hours. Credit review remains under one hour. Use locator “Training workbook, exhibit B, rows 1–40.” State that these are invented training aggregates with different product mix and small samples. Accept the source.
Keep the two source origins independent. Copying the checklist into a second evidence record would not create a second independent source.
5. Describe three task cards
This exercise teaches manual task creation and exact-version company confirmation. For the newer participant-first interview flow, use Review your task cards before sending or the interactive discovery demo.
Open 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
- In Discovery, create a confirmation request for Jamie covering all three reviewed tasks.
- Create a request for Sam covering intake and release, and another for Robin covering credit review.
- Issue each private link. In the participant sessions, inspect every task and choose Correct only if the card describes that fictional role accurately.
- Submit each request. In the advisor session, inspect and accept each returned response.
- 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 Work Map → Work map. Select a business stream and stage, then select Jamie in the highlighted organization. Inspect Jamie’s duties and tasks. Use Assign stages to place a duty or task explicitly; a task’s own assignment overrides inherited duty stages. Open Work flows for recorded handoffs and Tasks for detailed cards and source records.
The Work map reporting chart places Alex above Jamie and Robin, with Sam under Jamie, using the roster relationships you entered. These are not inferred from titles. Missing manager relationships remain unlinked. Continue to Client brief to see coverage and prepare a reviewed report from the saved work.
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 Client brief, choose Prepare client report, and name Alex and Jamie as the fictional audience. Review and refine the suggested purpose, summary, decisions, next steps, limitations and selected records. Save the frozen draft, open its preview, and inspect every section.
Approve the exact current content and audience with a rationale, then download the ZIP. Open client-report.html; print it to PDF if desired. Inspect record-register.csv and checksums.json. The package omits original response text and recordings. Delivery remains manual.
12. Finish the handoff
Record who owns the next review, the outstanding evidence questions, and the limits of the current result. Store the approved package using the engagement’s agreed policy. Ask the operator to take an encrypted backup and perform the documented restore drill before any important installation change.
You have now practiced the entire supported advisor journey. Repeat it with the adverse scenarios in the Training workbook before moving to an accepted customer environment.
Full user manual
This manual describes DutyGraph 0.3, the hosted advisor pilot. It covers the current Discovery journey, password-free response links, record lifecycle, Company Work Map, 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 Work Map | Business stages, highlighted people, duties, tasks and flows |
| Company Work Map > Tasks | 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 |
| Client brief | Live audit summary, audience-reviewed report snapshots and internal 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 Discovery’s Team & attendees panel to upload a team CSV or add, edit and remove people manually. The CSV columns are name, email, role, department and manager_email. The preview identifies missing values, invalid addresses, duplicates, unresolved managers and cycles. Correct all errors before submitting the kickoff package. The contact can nominate executive kickoff attendees and pilot discovery participants from the valid roster; those selections prepare the advisor’s review and do not send invitations. Existing people are not silently merged by a matching display name.
The sample CSV shape is:
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 carries the shared compact company snapshot into a contact email and leadership meeting guide. The contact reply and kickoff notes then supply the reviewed team roster and personalized interviews. Read the five discovery steps 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, or open the request and use Preview response form to inspect the live fields without submitting them.
Kickoff and work-response links expire after seven days and are intended for the named recipient. They open without an account or password and close after submission. Reissuing an open request rotates its unused invitation. Used, expired or revoked links cannot be submitted; ask the advisor for a replacement.
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
Kickoff and team work-response links open without an account or password. The recipient reads the notice, confirms they are the intended person, and sees only the assigned questions. A signed-in participant workflow remains available for older or exact task-confirmation requests; use the request type and page shown by the invitation.
A recipient can type a response or record a short voice clip. Recording requires browser microphone permission. Choose Record a voice response, stop the clip, listen to it, and choose Transcribe into my response when enabled. Review the editable text before sending. The clip remains in the page until it is transcribed or discarded; text drafts can be saved on the same device. Do not close the page before 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 held in the page until the recipient chooses transcription. No transcript is created automatically. The advisor must review the returned response and any transcript rather than treating a recording or checksum as proof of a company fact. 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
Company Work Map
The default Company Work Map follows stage → highlighted organization → person → duties and tasks → flow. Select a saved business stream and stage, then select a person to see the work recorded for that stage. The first stream is primary; later streams are supporting. The map uses the saved profile only as the stage vocabulary. It does not infer work from a title, department, reporting line, task name or legacy value-stage field.
Use Assign stages on a duty or task to place work in the map. Duties may be assigned to several stages. Tasks inherit a duty’s assignments through the duty’s explicit task IDs, unless the task has its own stage links. A task assignment then overrides inheritance; clearing it restores inheritance. Work with no stage, no owner or a link to a removed stage remains visible for repair. These assignments describe map membership, not approval.
The map has three primary views. Work map connects stages, recorded people, duties and tasks, including the reporting chart. Work flows shows explicit task-to-task handoffs and their receiving conditions. Tasks provides task cards, filters, complete work registers and supporting details. Open an underlying record for evidence, related records, human checkpoints and version history. The former Connected, Org & duties and graph/control tabs are no longer separate primary choices.
In Work flows, choose a workflow to scope its steps. Alternate branches are layout choices, not claims about which path is usual. Select a connection to inspect its handoff condition. Missing handoffs stay missing. Pan and zoom, use Fit for the bounded flow, or Expand for more room. No executable order is invented from a stage or a list of tasks.
Use Client brief to inspect current coverage, gaps, findings, commitments and measures, then prepare an audience-reviewed report. Linked work does not establish complete coverage or a measured result.
Reporting chart uses recorded manager relationships. Missing relationships remain unlinked. Team membership, task accountability, and reporting hierarchy answer different questions. The enriched Cobalt fixture includes a small synthetic reporting chart; it is demonstration data and does not establish a real organization.
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 | Ask the advisor for a replacement link |
| 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. In Discovery, enter the business name, official website and optional description once, then review the shared compact snapshot and proposed business streams. Use the configured research areas or add public sources manually. Keep source URLs and dates. Do not scrape private interviews into a public search query. Treat the brief as reported public context: 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. Kickoff and work-response links open without accounts; select the intended recipients explicitly before sending. 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 Company Work Map's three views: Work map for stages, recorded people and duties; Work flows for handoffs; Tasks for detailed cards and evidence links. The Work map reporting chart uses recorded managers. Do not infer a stage link, manager, owner or performer from seniority, job title or task ownership. Continue into Client brief to discuss coverage, priorities and the next review.
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, or inspect the clearly labeled Cobalt guided example. The generated 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 |
| Work Map and cases | 35 minutes | Assign stages, inspect the org highlight, 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. Preview the response form, issue the private link, and open it without creating a participant account. 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 by issuing the link?
- What must you do if the invitation is already used or expired?
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 Company Work Map's Work map, select a stage and then Jamie. Follow the highlighted organization to Jamie’s duties and tasks. Compare Work flows for handoffs with Tasks for detailed cards and evidence. Open Client brief to inspect the same work's coverage without treating a documented task count as a measured business result.
- Which recorded fields make Jamie an owner, and which make Sam a performer?
- Which view best answers “Who reports to Jamie?”
- What should appear when no stage, owner or manager is recorded?
- When does a task inherit a duty’s stage assignment, and when does its own assignment override it?
Submit: a written explanation of the stage → person → duty → task path 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.”
Exercise 8: ask without assuming
Use the fictional sandbox for this exercise. On Company Work Map, select a stage and open its info button. Identify whether the explanation is authored guidance or a sourced AI proposal. If company passages or peer examples are absent, record that limitation; do not invent them. For a sourced proposal, explain why a peer example is not a client fact or proof of success.
Open Ask about this work, select a relevant fictional person and preview the questions. Do not send real messages. Explain which saved work links support that choice, why an empty stage may not apply, and how a standalone task differs from an unrecorded sequence.
- Which exact stored email would be used in a real workspace?
- What continuing checks does the selected-recipient option authorize, and how would you pause it?
- Why can the weekly spacing, open-request rule or already-asked gap prevent another request?
- What remains saved when AI processing fails or encounters changed work?
- Why can a documented task flow remain unavailable for case execution?
Submit: the sandbox question preview and a brief explanation of the evidence, recipient and review boundaries. No email or provider execution is required for this exercise.
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 synthetic company, so avoid repeated runs during the workshop. The Cobalt guided example is also synthetic and clearly labeled; it is safe for demonstration, not client evidence.
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. Current kickoff and work-response links open without an account or password. An expired, used or rotated link needs replacement by the advisor.
The bearer invitation provides possession assurance only. It does not verify corporate identity or provide enterprise MFA. A good learner includes the limitation without dismissing the value of preserving the exact response.
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
Teach the three Company Work Map views together: Work map for stage → recorded people → duties/tasks, Work flows for explicit handoffs, and Tasks for detailed cards and source records. The reporting chart within Work map uses manager relationships. Missing stages, owners or managers remain gaps; team membership and senior titles do not justify invented links. Use Client brief to discuss coverage and next commitments. A bounded map or report must not be presented as the whole company.
Check the record fields with the inspector: an owner is accountable for the task; a performer does the work; a task is supported by evidence. A duty assignment can place its linked tasks in a stage, but an explicit task assignment overrides that inheritance. 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.
Start with the living client brief
Open Client brief in the sidebar, or use the link from Company Work Map. The page assembles current scope, work coverage, documentation gaps, current advisor-reviewed findings selected for discussion, commitments and measures. It uses the saved company record; opening it does not call AI or send anything to a client. The displayed revision identifies the snapshot you are reading.
Use Prepare client report to carry that snapshot into a draft narrative and suggested record selection. Refine the summary, decisions, next steps and limitations, then name the audience. Save report draft creates a frozen report for preview and exact-content review. A source change can require a new draft or review. Write a custom report remains available for a different audience or purpose.
The living brief is an advisor workspace view, not a client portal. A saved report is a separate snapshot; it does not keep rewriting itself as the work changes. Download and share the approved packet through the channel agreed with the client, and record the recipient, version and delivery date. Preparing a report does not email it, schedule a meeting, activate billing or start a subscription.
Continue the engagement deliberately
Use the brief's Open weekly review action to revisit decisions, owners, dates, missing baselines and observations. Prepare participant updates, review returned accounts, and record the next intervention and how its result will be judged. Use Review strategy inputs to see what each framework needs before opening its existing canvas. Work records can inform strategy without supplying all financial, customer or market variables.
A recurring advisory engagement should have an agreed scope, participants, review cadence, responsibilities and deliverables. These are the advisor's working agreement with the client. The application supports that work record and manual sharing; it does not create a commercial retainer, client access or automatic charges. Measured benefit still needs actual observations and appropriate comparison.
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
- Confirm the named audience and purpose match the agreed engagement scope.
- Confirm the company, date, source revision and selected records are correct.
- Check that claimed confirmations and observations match their current states.
- Explain missing coverage, conflicting sources, confounders and open decisions.
- Remove unnecessary personal or sensitive details from authored narrative.
- Preview the exact packet and record the approval rationale.
- Download, open and inspect the readable report and register.
- Deliver through the approved channel and record recipient, version and date.
- Keep the original ZIP and checksums with the distribution record.
- 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 guided example
Cobalt Industrial Supply is fictional. Its company snapshot, people, policies, stages and work descriptions are authored training examples. The example contains no live agents, sent emails or measured business results. Treat every finding as synthetic.
Open Workspace settings → Open my sample company, then Company Work Map. The enriched sample includes a saved wholesale distribution stream and a small synthetic reporting chart. Select a stream and stage, choose a highlighted person, and follow their duties, tasks and flows. 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.
The saved sample’s stage links are authored synthetic fixture data. They are persisted with the Cobalt business profile and can be edited in Assign stages; they illustrate how duties and tasks appear in saved business stream columns. They are not inferred from titles or the order of stages. A task with its own stage links overrides its duty’s stage links.
If an older or incomplete Cobalt workspace cannot load the saved business profile, the guarded legacy fallback may show clearly labeled illustrative assignments. That fallback is read-only and does not change records. The normal saved sample profile and its stage assignments remain editable.
Supplier onboarding
The intended outcome is a supplier ready for purchasing. Its eight task cards are part of the sample’s 18 guided business task cards; nine handoffs cover the usual path and two exceptions.
- Start with Check supplier packet, then Create draft supplier record.
- Click Standard terms to inspect the direct Finance route. Compare it with Nonstandard terms, which requires Legal review before Finance.
- 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.
- 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.
- 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.
- Select a person in Work map to see their duties and tasks. Use Tasks for detailed cards and responsibility records, and Work flows for handoffs. Open the Client brief to inspect the fictional audit coverage.
Customer order fulfilment
Select Work flows → Customer order fulfilment. Its seven task cards and seven handoffs connect a customer's purchase order to a checked shipment and dispatch confirmation. The sample also includes three account-cycle task cards, for 18 guided business tasks in total. The separate access-review walkthrough has two access-controls task cards, both Unassigned, because it is a synthetic control walkthrough rather than part of the wholesale stages. Additional synthetic control scenarios remain in the saved records and Agent governance tools, outside the wholesale stages.
- Follow Check customer purchase order → Check stock and delivery date.
- If stock is available, Stock reserved proceeds to pick release.
- 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.
- Both paths meet at Release the order for picking, followed by picking, dispatch and customer confirmation.
- 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 stage, then a person, to narrow the map. Owns work comes from an owner field; Does the work comes from a performer field. Neither label is an approval.
- 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.
- Unassigned, ownerless and removed-stage work stays visible for repair. The map does not create a relationship from a task title, duty name, department or reporting line.
- 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. The board uses saved business stream stages as columns, with an Unassigned column for work that has no explicit stage link. Choose a workflow, person or operating mode to filter the cards. A task can appear in more than one saved stage. An empty column means no records match; it does not prove that the company lacks that work.
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. Use Company Work Map → Assign stages to change business-stage membership. A task with explicit stage links overrides its duty’s inherited links; clear them to restore inheritance. 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.
Start from the live work audit
The Strategy entry shows the current audit's evidence coverage, confirmed tasks, respondent coverage and unresolved work inputs. These counts describe the saved record, not business performance. A complete-looking work map does not establish costs, margins, customer demand, competitor results or a measured bottleneck.
Choose a Strategy question to see that framework's actual required inputs. Sources to assess means matching excerpts are available; read them to decide whether they answer the question. No matching source identifies a collection gap. Expand an input to see what it requires. The source inventory shows record versions, review states and excerpts; changed inputs can make a prior analysis out of date.
The suggested starting framework follows the server's dependency order and currentness checks. Missing or outdated upstream analyses appear by name. Review [framework] opens the existing canvas to inspect sources and decide whether to generate. Opening it does not call AI. Existing consent, provider charges, input limits and version checks apply when you start a run. A report remains a synthesis of its underlying evidence, not an independent source that proves its own conclusions.
Bring the next observation back shows saved measures, missing baselines, interventions, outcomes and returned weekly updates. Open Weekly review to prepare the next conversation. New accepted observations can inform another strategy version, but the application does not run an unattended strategy cycle or treat every gap as resolved.
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:
- Before the meeting, draft questions from changes, unresolved decisions and missing measurements.
- The advisor reviews recipients and questions. An approved schedule sends one invitation per person and meeting.
- Participants send short updates. AI drafts an agenda with source links, decisions needed and a time limit per speaker.
- The team meets. Fireflies captures the meeting when the configured account and recording permissions allow it.
- 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.
- 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 for all sixteen layouts, input limits and version history.
Sources: ASD-STE100, Porter’s Five Forces, Fireflies signed webhooks.
Strategy reports and the copilot
Open Strategy to understand the business without reading each framework separately.
Read a report
- 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.
- In Strategy, select Read executive brief for the whole company. Use Read report beside a framework group for a focused view.
- Select Generate with OpenAI. The app uses the API key and model in your account settings.
- 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.
- 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.
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 earlier. AI saves an editable first result: the company snapshot, the people and their duties, then the detailed task cards. Explore that result before making corrections. Proposed links do not count as a person confirming the work.
Start from a demo request
You can also choose Add a company. Enter its name and website, then select Continue to company research. Discovery opens with these details. Review the research options and start research. The review covers the whole business by default. For a large company, expand the department option and name the division to review first. Set improvement goals after research and leadership discussion.
The public form collects the company website, company name, team size, contact name, email and role. The goal is optional. Configured operator advisors see Demo requests in the sidebar, with a count of new requests. Choose Research this company to create its workspace and start Discovery. The contact details carry forward. Reopening the same request reuses its company. Manage follow-up records the request status and next action. Opening a request does not send email.
1. Research and contact
Enter the business name, website and an optional description, or use the details carried from the demo request. Choose Research this company. Research coverage includes company overview, customer communities, competitors and industry news. Each selected area uses one Exa request; the default uses four of the ten requests available in the rolling daily allowance. AI uses these sources to prepare and save the company snapshot and proposed stages. Existing company stages survive later research passes. Continue to Draft contact email, or use Change business streams and Edit the profile and stages to adjust the result.
Keep the page open while the sequence runs. If interrupted, Resume research pass continues with saved command keys; it does not repeat completed searches. A failed step offers an explicit retry. Provider connections must be configured in Workspace settings. Without Exa, provide a description for an AI-only recommendation; without OpenAI, you can still collect public sources.
The Industry Map is a separate deeper analysis after this initial pass. It uses the collected context to prepare a structured industry baseline before kickoff. Finding a community or feed does not subscribe to it or start continuous monitoring.
The snapshot shows short facts about offers, customers, size and competitors. Open the research details to inspect original qualifications and sources. Reported facts have not been independently confirmed. Primary stream sets the starting focus; supporting streams can describe other parts of the business. Use Make primary to change that focus. Public research does not establish internal duties or reporting lines.
Open a stage's info button for Why this stage? New AI stage proposals retain their company passages, documented peer examples, source links and dates, rationale and unknowns. The number of stages follows the proposed grouping; it is not fixed at six. Peer examples are comparisons to discuss, never client facts, employee assignments or evidence that a practice succeeds. Older saved template stages retain their authored guidance.
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 Leadership meeting and the evidence history tools. Reopening Discovery after a returned contact response selects step two; Research & contact offers a forward link.
The contact's private page includes a team CSV template/upload, manual add/edit/remove controls, manager links, executive kickoff and pilot participant selections, and structured leadership inputs. Review the returned package, then choose Confirm roster & populate org chart. Invalid reporting lines or conflicting existing people block the import without partial changes. Selections do not send invitations. The uploaded organization is separate from the interview roster agreed after kickoff.
Optional evidence and deeper industry mapping are under Supporting research. Opening the map does not generate analysis and is not required for the email.
2. Leadership meeting
Choose Prepare meeting guide. The guide uses public research and the contact's actual reply, when available. It follows the selected business model and each stream of a hybrid company. Confirm or correct the proposed stages. The guide covers the offer and customer journey; goals with owners, measures and time horizons; departments and reporting; role duties; a concrete task example; dependencies and delays; software and decision boundaries; and follow-up. The advisor uses the guide during the meeting.
During or after the meeting, use Understand the business, together. Select one of eight topics, read the lead question, open follow-up prompts as needed, and record the answer. Agenda topics and preparation details are collapsible. You can also paste an authorized transcript. Unsaved notes survive switching Discovery steps, but leave Discovery only after saving. “Notes added” means text was entered, not verified coverage. Guided notes are optional; use them to close gaps rather than copy the whole conversation. Record who supplies each input, who produces the output, where it goes, and who handles exceptions. Leadership establishes context; each employee describes their detailed procedures later. The combined notes and transcript can contain up to 20,000 characters. 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
Save outcomes & review team saves the kickoff notes and opens step three. With AI configured, it also extracts the team and duties, infers their business-stage links, and saves the proposed map. Review the expanded people, roles and duties breakdown against the meeting notes before preparing individual interviews. Open company work map lets you explore it immediately. Public research cannot create the internal roster.
Open a person or duty to correct the saved result. Existing work remains available; a new roster does not erase it. Each saved person needs an email, role and department. If the AI output cannot be saved, an error explains the issue and the draft remains editable. Correct it and save, or prepare a new draft. The system does not invent email addresses to get past a missing field.
4. Team interviews
Choose Create question sets. AI prepares one tailored interview for every person in the reviewed team. It uses their role, full reviewed duty descriptions, business model and leadership context. Up to eight focused prompts cover all of the person's stated duties, including recurring and exception work. 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.
Question generation saves the personal requests automatically. Preview each form and email. Select the people to contact and choose Review selected recipients. The final review lists the exact names and email addresses. Send questions to the selected people sends only those requests 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 without an account or password. Voice is useful for a real example that captures steps, exceptions and frustrations; typing is always available. The recipient reviews the response before sending it. If transcription is enabled, a short recording can be transcribed into editable text.
After recording, they stop the clip and choose Transcribe into my response, then check the editable text. The advisor starts task extraction from returned responses. AI saves the proposed cards with inferred people, duty and stage links; the advisor can explore and correct the map afterward.
Their original answer arrives first. This is their understanding of the work, not company approval of ownership or agent permissions. If AI is unavailable, the typed or transcribed answer still gives the advisor useful evidence. When exact task checks are needed later, the advisor prepares a separate confirmation request for the named owner and performer. See Answer a work request from your private link.
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.
Generated cards are saved as proposed work, without marking advisor review or participant confirmation. Inspect each card's input, action, output, tools and decisions. AI can reuse identified existing tasks on later runs, preserving corrections. Resolve missing owners, overlapping responsibilities and handoff differences with the relevant people. Use Review the work across the team for recorded gaps and optional AI hypotheses. Validate findings with the team before treating them as established facts.
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.
Meeting agenda sections total 120 minutes. Without a returned preparation response, the guide is labeled provisional. Changed duty descriptions are not silently merged by owner and title. Stage links can be inferred by AI or assigned manually; each is saved on the work record. For older unassigned work, use Connect existing work with AI on Company Work Map. Open a duty or task to inspect the inference basis and confidence.
Continue with focused questions
On Company Work Map, Ask about this work previews short questions about missing details in the selected stage. Choose relevant people from their stored email addresses. Continuing checks are on by default after this selection; the roster is not enrolled automatically. Pause or resume the saved selection from the map. A person receives at most one new gap request a week, cannot have another open work request, and is not automatically asked the same gap again. Sample workspaces preview questions without sending email.
The person answers by voice or text on the private page. Their reply is saved before AI processes it. Eligible updates remain proposed; changed or reviewed work and contradictions need advisor review. Reported task flows are documentation only until separately configured and reviewed for cases. Missing information does not prove a broken process, and this loop does not guarantee that every gap will be resolved. See Company Work Map.
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
- Research the company in Discovery. Public search results are available to the framework automatically. They remain public claims, not confirmed internal facts.
- Accept useful leadership, customer and employee evidence as the engagement progresses. Frameworks use the relevant evidence buckets and work records automatically.
- Open Business Model Canvas. Read the nine sections and select Run this framework.
- Review the summary, populated sections, input assessments, citations and open questions. Save your own interpretation with Write advisor analysis if needed.
- 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
Use the numbered section buttons to jump to a part of the framework. The opening summary counts findings to review, explicit gaps and unresolved questions. Open a confidence label to read its explanation. On a phone, table rows become vertical records with their field labels visible.
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, Strategyzer's Value Proposition Canvas, Harvard Business School's Five Forces, McKinsey's 7-S framework, McKinsey's Three Horizons, the ERRC grid, Christensen Institute's Jobs to Be Done, Balanced Scorecard Institute's four perspectives, and Lean Enterprise Institute's Theory of Constraints.
Answer a work request from your private link
Your advisor wants your best understanding of the work. You do not need a polished explanation. A work response is your account of what you do; the advisor reviews it before turning it into task cards.
Try it without an account
Open the five-person walkthrough. 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. No account or password is needed for this work response. Do not forward the link. Read the notice and questions before answering. If the link is expired, closed or already used, ask your advisor for help.
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 starts the task, what data or documents you receive, and who supplies them.
- The ordered actions, checks, decisions and exceptions; say how often you do the task.
- 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
Type your answer in the notes box, or choose Record a voice response. Recording stops automatically after three minutes. Listen to the clip, then choose Transcribe into my response when your advisor has enabled transcription. Check the editable text before sending. You can also use device dictation or type everything yourself. Audio stays in the page until it is transcribed or discarded; saving text progress does not save the recording.
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
The current passwordless work response does not ask you to create task cards. Your notes go to the advisor, who may draft cards for review. Keep separate duties and tasks clear in your answer so the advisor can preserve that structure. A task card describes a bounded unit of work; it does not prove company policy or give anyone permission to act.
The phone companion, when your advisor uses it, asks you to check a short proposed description before sending. That check means the description matches what you said. It does not approve company policy, and your advisor still reviews it. The private browser link on this page works the same way until you send.
5. Send everything together
Choose Send my response. Read the notice and confirm that you are the intended person before sending. Wait for the receipt message before closing the page.
If recording or transcription is unavailable, type your answer and send it. A typed response is complete; your advisor can help with the next step.
What the advisor does next
The advisor opens your returned response and preserves your original wording. They may draft task cards, assign the work to a business stream, and resolve missing owners or differences between teams. Your response records your understanding; it does not confirm company ownership, approval or permission for an agent. Any later company confirmation applies to the exact task version under review.
In the public walkthrough, Maya returns six fictional tasks. The advisor sees prepared assistance recommendations, human tasks and an unresolved approval-owner gap. These examples are synthetic; they are not live analysis, confirmed conflicts or deployed agents.
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 response and any transcript stay closed until you open them.
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 and participant guide before the exercises. The sample does not send invitations or issue live agents.
Module 1: qualify the engagement
Practice: an executive asks to automate the entire business. Write a one-sentence scope for one workflow, name the decision the work should support, and identify the sponsor and day-to-day work owner.
Required output: scope, exclusions, participant estimate, agreed data sources, success measures, and unresolved setup requirements. Before real collection, the operator and client must agree data handling, provider use, access, and retention.
Pass condition: another advisor can explain what is in scope and what would require a new agreement. Do not start with a promise of savings or a predetermined automation solution.
Module 2: prepare and lead the kickoff
Practice: separate public research into supported facts, inferences, and questions. Draft an invitation to the point of contact asking for executive participants, a roster, departmental responsibilities, goals, and concerns.
Run a 20-minute role-play with a sponsor. Ask for a recent example. Clarify the desired outcome, current measures, and constraints. Ask permission before recording a real meeting.
Required output: meeting guide, corrected business context, agreed roster, and open questions. Public research must not silently establish internal reporting lines or task ownership.
Module 3: prepare the team questions
Practice: review two people in the roster. Check department, role, and proposed duties against the kickoff account. Correct errors before generating individual questions.
A useful prompt asks: what arrives, what you do, what leaves, where it goes, which software you use, and what makes the work difficult. Ask for exceptions and an actual recent example. Prefer voice, while preserving a typed option.
Required output: reviewed questions and a private invitation draft. Demonstrate which action prepares a request and which action sends it. Do not use a real participant's email during practice.
Module 4: review returned task cards
Practice: a participant explains a task, edits the extracted cards, marks one uncertain, and submits. Find the original account and the reviewed card in the advisor view.
Explain that the participant has confirmed their understanding of the input, action, output, destination, and software. This does not assign company authority or resolve a conflict with another person.
Required output: two reviewed cards and an issue log with the source, disagreement, decision owner, and next question. Keep original accounts intact. Do not claim that automatic cross-team conflict detection has resolved the issue.
Module 5: diagnose and deliver
Practice: compare two accounts of the same handoff. One person thinks an order is ready when stock is reserved; the other expects a confirmed delivery date. State the mismatch and ask the work owner which condition is required.
Create a hypothesis about delay, identify the evidence needed to test it, and name a measure with a baseline period. Use a framework only when its inputs are available. Missing data should remain visible.
Required output: an evidence-linked work map, unresolved-issues log, and short readout with one recommended next step. Show what would change your conclusion. Obtain the required review before distributing a deliverable.
Module 6: hand off and maintain
Practice: teach an internal owner how to review a changed task and identify affected handoffs. Ask them to do it back without your help.
Required output: named internal owner, review cadence, open actions, change process, and support contacts. A 6–12 month support period is a possible commercial model, not a required or proven duration.
Practical review rubric
Score each item 0 (missing), 1 (needs help), or 2 (independent and evidenced).
| 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
Business stages are broader than duties: a stage groups work across roles; a duty is an ongoing responsibility; a task is a specific piece of work. There is no universal stage count. Templates are suggested starting points, and saved streams support 1-16 stages. Hover a stage or focus/tap its info button for an explanation and typical work. Company descriptions take precedence; renamed/custom stages ask for a description instead of inheriting unrelated examples. Edit descriptions in Discovery > Edit the profile and stages.
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 alone do not create duties, tasks, permissions or measured bottlenecks. Discovery AI uses internal accounts to propose work and saves stage links. Advisors can change those links afterward. The map does not infer operational chains from a template's layout.
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
Get the first connected map
Discovery saves proposed stage links with AI-created duties and task cards. Open Company Work Map to explore the result, then correct the work or its stage assignments. For older unassigned work, choose Connect existing work with AI. Open a duty or task to inspect the inference basis and confidence. These links do not grant authority or count as a person confirming the work.
Technology advisory and distribution
Search Tier4 Advisors for IT procurement advisory & technology brokerage, or Telarus for Technology services distributor (TSD). Review their proposed stages, independent-agent relationships and payment arrangements with leadership. See model details.
Company Work Map
Business stages are broader than duties: a stage groups work across roles; a duty is an ongoing responsibility; a task is a specific piece of work. There is no universal stage count. Templates are suggested starting points, and saved streams support 1-16 stages. Hover a stage or focus/tap its info button for an explanation and typical work. Company descriptions take precedence; renamed/custom stages ask for a description instead of inheriting unrelated examples. Edit descriptions in Discovery > Edit the profile and stages.
Open Company Work Map in the sidebar. The default path is simple: choose a business stream, choose a stage, select a highlighted person, then inspect that person’s duties, tasks and task flows. The map connects the saved business model to recorded work. A business template alone never creates company evidence.
Your company's name anchors the page. Workstream labels how it delivers value, with the saved stream name alongside it. Read left to right for the business stages, then down through People & duties to Task flows. Person summaries show actual duties; select someone to read each duty's purpose and its tasks. Work map gives the business overview, Work flows follows tasks and handoffs, and Tasks opens the detailed work. A workflow may cross several people's duties. Expanded mode keeps the company identity visible.
Follow the work
Open a stage's info button for Why this stage? New research proposes a useful grouping from company evidence and, when available, documented practices at comparable businesses. The help shows the rationale, exact passages, source links and dates, and what remains unknown. Company-reported evidence, Peer example and AI-suggested stage mean different things. A peer practice is not a client fact, a task assignment or proof of success. Older template stages show authored guidance instead. Existing custom stages survive later research.
- Select a stream. The first saved stream is marked Primary; the others are Supporting.
- Select a stage, or choose All company work. Stage names come from the saved business profile.
- Select a person in the highlighted organization. The person’s labels distinguish Owns work from Does the work.
- Open a duty, task or flow to inspect its record, inputs, output, evidence, handoffs and human decision boundary.
The chart uses the available screen height and stays in position when you switch stages. Drag to pan. Pinch or use +/− to zoom. Fit team brings everyone back into view; Expand provides more room. Scroll down to reach the task flows. On phones, person details appear below the chart. Stage help opens outside the stage row so you can keep clicking through the stages.
The organization is highlighted from recorded task owners and performers in the selected stage. Reporting lines remain manager relationships from the roster. The map does not infer work from a title, department, reporting line, task name or old valueStage field. Owners and performers describe accountability and performance; neither role is an approval.
Assign stages explicitly
Use Assign stages on a duty or task. A duty can belong to more than one stream or stage. Its tasks inherit the duty’s stage links through the duty’s recorded task IDs. A task with its own stage links overrides that inheritance; clear the task links to return to its duty’s stages. A task title, duty label or stage position never creates an assignment automatically.
Unassigned work appears under Work not assigned to a stage. Work with no recorded owner or performer stays visible as a gap. If a profile stage is removed, the old link appears under Repair assignments to removed stages so the advisor can choose a current stage. Missing links and missing people remain gaps instead of becoming guessed relationships. Saving an assignment creates a normal record version and follows the usual review rules.
Three views, one record
The task flow below the people section uses recorded workflow and handoff links. Branches and nearby cards are layout choices; only an explicit handoff establishes that work passes between tasks. Open Workflows & cases to inspect a workflow definition or a manually observed case. Case controls record observations and do not call an external business system.
Choose Work map, Work flows or Tasks. Work map contains the stage/people/duty path and reporting chart. Work flows shows recorded handoffs. Tasks provides the cards, filters and supporting registers. The former Connected, Org & duties and graph/control tabs are consolidated into these views and the existing record/governance tools. Open Client brief from the map to inspect coverage, discuss priorities, prepare a report and continue into Weekly review or Strategy.
PostgreSQL is authoritative; Neo4j is a derived projection. The normal Cobalt sample has a saved synthetic business profile and authored stage assignments. Those assignments remain editable and clearly synthetic. The guarded fallback for an incomplete old sample is illustrative and read-only; it never classifies client work.
Get the first connected map
Discovery saves proposed stage links with AI-created duties and task cards. Open Company Work Map to explore the result, then correct the work or its stage assignments. For older unassigned work, select the unassigned-work count above the chart, then choose Connect existing work with AI. This action also appears under Assign work to business stages below the chart. Open a duty or task to inspect the inference basis and confidence. These links do not grant authority or count as a person confirming the work.
Ask about missing details
The map can flag an unexplained stage, a duty without tasks, missing task details or people, and work whose sequence is not recorded. These are gaps in what we know, not proof that people work badly. A stage may not apply; a task may stand alone.
Choose a stage, then Ask about this work. Preview up to three questions and select the relevant people using their displayed, stored email addresses. Selection is deliberate: the whole roster is not enrolled. An unlinked person is not assigned questions just because of their job title. With continuing checks left on, this selection also authorizes later gap questions to those people. Turn it off for a single round.
Use Pause to stop queued automatic follow-ups and future checks; use Resume to continue for the saved selection. A send already in progress may finish. Only one work request stays open per person, new gap requests are spaced at least a week apart, and the same gap is not asked again automatically. An unanswered or unclear gap can still need advisor attention.
The private link lets the person speak or type, review the text, and submit. The answer is saved first. AI then proposes new work or fills missing details in eligible proposed records. Original evidence remains available; reviewed work, changed sources and conflicting accounts are held for advisor review. Delivery and processing status appear in the request history. A saved reply does not mean its AI update succeeded.
Sample workspaces allow question previews and send no emails. Real follow-ups need email and AI configured in Workspace settings. Replies may describe actual task flows, but automatically captured flows are documentation only. They cannot start cases until an advisor configures and reviews them through the normal workflow controls.