> ## 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.

# Workspace visibility

> Use Atlas workspace APIs without blurring private review context and public evidence.

## Overview

Workspace APIs are for team workflows: private lists, briefs, coverage targets,
watches, usage proof, and Scout sync. They help teams act on source-backed
research while keeping public records, private notes, and review state separate.

For exact workspace endpoints and schemas, use the
[API reference](/docs/api/reference).

## The rule

Public Atlas records should be backed by public evidence. Workspace context is
private unless a user deliberately publishes a public-safe record.

An integration should never treat a private brief, note, list, or coverage
target as public evidence. Keep it scoped to the workspace unless the API
response explicitly says a record is public.

## What belongs in a workspace

Use workspace APIs for:

* Draft briefs and source-linked decision artifacts.
* Coverage targets for places, issues, actor types, and source gaps.
* Watches that keep a team aware of actor or coverage changes.
* Usage proof for evidence opens, exports, and workflow activity.
* Scout sync receipts and review state.
* Private notes that should not appear in the public directory.

Keep public actor facts and source evidence separate from team-only judgment,
planning notes, and workflow status.

## Understand entry links

Scout and workspace import flows may return `entry_links`. These links connect
records from one context to another:

* A local Scout entry to an Atlas entry.
* A workspace-private entry to a public directory entry.
* A run result to a brief, list, or coverage target.

Treat `entry_links` as mappings, not proof. The link tells you how systems refer
to the same or related record. The source evidence tells you whether the record
is strong enough to use.

## Read visibility as a publication decision

Visibility tells you who should be able to see a record.

| Visibility     | Meaning                                                 |
| -------------- | ------------------------------------------------------- |
| `public`       | Intended for the public directory with source evidence. |
| `private`      | Belongs to a workspace.                                 |
| `skipped`      | Not created or published by this import or sync.        |
| `needs_review` | Needs human review before publication or reuse.         |

If an endpoint returns a more specific status, prefer the endpoint response over
this general model.

## Safe workspace pattern

Use this pattern for imports, syncs, briefs, and exports:

1. Authenticate as the correct workspace.
2. Preserve source ids or source URLs with every imported actor.
3. Store returned entry links.
4. Store visibility and review state.
5. Keep private notes out of public records.
6. Re-check source freshness before publication, outreach, or funding review.
7. Export evidence with the artifact, not separately from it.

## Example: build a source-backed brief

For a nonprofit entering Phoenix, a safe workflow could be:

<Steps>
  <Step title="Find public actors">
    Use public place and entity APIs to find housing, wage-theft, and
    immigrant-worker organizations.
  </Step>

  <Step title="Inspect evidence">
    Review the sources that support each actor and issue connection.
  </Step>

  <Step title="Create a workspace brief">
    Save selected actors, sources, notes, and review state inside the team's
    workspace.
  </Step>

  <Step title="Track gaps">
    Add coverage targets for source types, issue areas, or places that need more
    review.
  </Step>

  <Step title="Export proof">
    Export the brief with source context preserved.
  </Step>
</Steps>

## What not to do

* Do not publish private workspace notes as source evidence.
* Do not treat entry links as confidence scores.
* Do not discard source URLs when exporting a brief.
* Do not assume a single-source lead is ready for outreach.
* Do not merge Scout entries into public records without visibility review.
* Do not present usage proof as public impact evidence without context.

## Related guides

<CardGroup cols={2}>
  <Card title="Team workflows" icon="users" href="/docs/workspace/customer-workflow">
    Build briefs, track coverage, watch changes, and export proof.
  </Card>

  <Card title="Sync Scout results" icon="terminal" href="/docs/scout/sync">
    Sync reviewed Scout results into Atlas.
  </Card>

  <Card title="Trust and provenance" icon="shield-check" href="/docs/resources/trust">
    Interpret source-backed claims and uncertainty.
  </Card>

  <Card title="API reference" icon="code" href="/docs/api/reference">
    Inspect exact workspace request and response schemas.
  </Card>
</CardGroup>