> ## Documentation Index > Fetch the complete documentation index at: https://atlas.rebuildingus.org/docs/llms.txt > Use this file to discover all available pages before exploring further. # Team workflows > Task-based guides for saving actors, building briefs, tracking coverage, watching changes, and exporting proof. Atlas team workflows begin in public discovery and end in source-linked work products. A team should be able to find credible actors, inspect the evidence, save a working set, create a brief, track gaps, watch for changes, and export proof without losing the sources behind the record. This guide uses one concrete example: a nonprofit preparing to enter Phoenix wants a source-linked briefing on housing, wage theft, immigrant worker support, and related civic organizations. ## Workflow map | Task | Screen or API surface | Output | | -------------------- | --------------------------------------------- | ----------------------------------------------------------- | | Search public actors | `/browse`, `/map`, profile pages | Source-backed leads | | Save a working set | Workspace lists | Reusable actor list | | Build a brief | `/briefs` | Decision artifact with sources | | Track coverage | `/coverage` | Place, issue, actor, and source gaps | | Watch for changes | `/watching`, `/feed` | Recurring review queue | | Export proof | Brief export, coverage report, renewal packet | Evidence for funders, editors, partners, or internal review | | Sync Scout results | `POST /api/discovery-runs/syncs` | Remote run, visibility receipts, and links back to Atlas | ## Product screen references Use these screens when checking the team workflow against the product. They are the user-visible anchors for the workflow, so each one should make the next action and the evidence boundary clear. | Screen | Routes | What the user should see | | -------------------- | -------------------------------------------- | ---------------------------------------------------------------------------------------- | | Briefing room | `/briefs`, `/briefs/new`, `/briefs/:briefId` | Recent briefs, source-linked actors, confidence state, review state, and export actions. | | Coverage workspace | `/coverage`, `/coverage/:targetId` | Targets, gaps, source types, linked entries, linked runs, status, import, and export. | | Discovery run review | `/discovery?run=` | Run status, selected entries, source receipts, sync receipts, and workspace links. | | Watching and feed | `/watching`, `/feed` | Watched actors, coverage targets, brief changes, and review prompts. | The screenshots below show the briefing room and coverage workspace populated with local-mode demo data. Use them as the visual baseline for this workflow: briefs should preserve source counts and confidence state, while coverage should make gaps, next actions, and linked evidence counts visible. Atlas briefing room showing source-backed Detroit, Phoenix, and Milwaukee briefs. Atlas coverage workspace showing a Phoenix worker-power target with gaps, next actions, linked actors, and reviewed source counts. ## Task 1: Build a source-linked briefing for Phoenix Search for Phoenix and issue terms such as "housing", "wage theft", "tenant", or "immigrant worker". Open likely results and inspect their source panels. Save organizations, people, initiatives, and campaigns that have enough source evidence to review as a team. Keep the list focused: the first list should be a working set, not every possible result. Open the briefing room and create a brief for the Phoenix entry effort. Add the saved actors, source links, issue context, gaps, and review state. Use the brief to distinguish "ready to contact", "needs source review", "single-source lead", "stale evidence", and "coverage gap". A useful brief shows uncertainty instead of hiding it. Export the brief when a field team, funder, editor, or partner needs a portable artifact. The export should preserve the source context, not just actor names. ## Task 2: Track coverage for a new place Coverage targets turn missing knowledge into an explicit workflow. For the Phoenix example, create targets such as: | Coverage target | Why it matters | | ------------------------------------ | ------------------------------------------------------------------------ | | Phoenix housing organizations | The team needs credible tenant and housing leads. | | Worker centers and wage theft groups | Labor and immigrant worker support may overlap with housing instability. | | Public records and local journalism | The team needs evidence beyond organization self-descriptions. | | Under-covered issue areas | Thin evidence should become a research task, not a silent absence. | Each target should include geography, issue areas, actor types, source types, review state, gaps, linked discovery runs, and linked entries. ## Task 3: Watch actors and coverage targets Watching is for recurring review. Use it when the team needs to know whether a profile, brief, coverage target, or source-backed issue area has changed. Good watch candidates: * A coalition the team may contact. * A source-backed profile that needs freshness review. * A coverage target with gaps that should be revisited. * A brief that supports repeated field work. Watching should not blur public and private context. Public profiles stay public; private notes, planning context, and renewal proof stay in the workspace. ## Task 4: Run Scout locally, sync to Atlas, open the run Scout is useful when a researcher wants a local or scripted discovery workflow before syncing reviewed results into Atlas. Start with [reviewing Scout results](/docs/scout/review) when the run already exists, or [run local discovery](/docs/scout/run) when the team needs a new pass. Run a local Scout discovery for the place and issue set. Keep the raw local results so the team can inspect what Scout found before syncing. Decide which entries should be public, which should remain workspace-private, and which should be left out until the source evidence is stronger. Use `POST /api/discovery-runs/syncs` to send the selected Scout result to Atlas. The response includes the remote run id, entry visibility receipts, and links back to the workspace run. Open `/discovery?run=` and review the run in the workspace. Link the run to a brief or coverage target when it supports a team decision. Atlas discovery screen showing location, state, issue-area selection, and recent discovery runs. ## Task 5: Export proof without leaking private context Proof matters for teams, but proof should stay tied to the right audience. | Artifact | Good use | Boundary | | ----------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------- | | Brief export | Share source-backed findings with a team or partner. | Do not treat private notes as public evidence. | | Coverage report | Show where the team improved coverage or still has gaps. | Do not imply gaps mean no civic work exists. | | Renewal packet | Show usage, evidence opens, public-record improvements, and workflow activity. | Do not publish internal planning context. | | Public directory update | Improve the public map when evidence is public-safe. | Keep workspace-only details private. | ## API handoff for teams Human workflow and API workflow should describe the same model. Useful endpoints: * `POST /api/discovery-runs/syncs` syncs reviewed Scout results into Atlas. * `GET /api/orgs/{org_id}/briefs` lists workspace briefs. * `GET /api/orgs/{org_id}/briefs/{brief_id}/export` returns a source-linked evidence export. * `GET /api/orgs/{org_id}/coverage-targets` lists coverage targets. * `GET /api/orgs/{org_id}/coverage-reports` returns a coverage report. * `GET /api/orgs/{org_id}/watches` lists watched resources. * `GET /api/orgs/{org_id}/usage-summary/renewal-packet` returns renewal proof. Read [Workspace endpoints and visibility](/docs/api/guides/workspace) for `entry_links`, visibility receipts, and safe workspace endpoint usage. ## Demo checklist A strong team demo should feel like one continuous path: 1. Search Phoenix and one issue in public discovery. 2. Open a profile and inspect its sources. 3. Save relevant actors into a workspace list. 4. Create or open a brief. 5. Add source-backed actors and gaps. 6. Link a coverage target. 7. Watch the actor or coverage target. 8. Export the brief or coverage report. 9. Explain which facts are public evidence and which context is private. If the demo depends on unsupported claims, hidden internals, or private state appearing in the wrong place, the workflow is not ready for that user. ## Related guides Interpret source evidence before putting actors into a brief. Use workspace APIs without leaking private context or misreading visibility. Run local discovery, sync selected results, and open the workspace run. Review workspace capabilities by plan.