# Sample source and access boundary

> **Illustrative example — not a customer deployment.**
>
> This document is a synthetic sample authored by VeerOne to show how
> approved sources and exclusions are recorded for a workflow. It does not
> describe a real organization's systems or data, and no access grant shown
> here exists anywhere.

## Purpose

Before a workflow reads anything, both sides write down which sources it may
use, which it must not use, and who approved each side of that line. This
sample shows the shape of that record.

## Approved sources (synthetic)

| Source | What the workflow may do | Approved by (role) |
| --- | --- | --- |
| Team process guide | Read and cite excerpts | Content owner |
| Request intake inbox | Read incoming requests | Operations lead |
| Handoff checklist | Read required-fields list | Operations lead |

## Excluded sources (synthetic)

| Source | Why it is excluded |
| --- | --- |
| Personal staff mailboxes | Out of scope for this workflow |
| Archived guide versions | Superseded; conflicts must be escalated, not read silently |
| Any system not named above | Default is no access until this record changes |

## Standing rules

- A source is used only after it appears in the approved table.
- A conflict between sources is surfaced to a person; the workflow does not pick a winner.
- This record is reviewed when the workflow changes, not on a fixed calendar invented for this sample.

## Open unknowns a buyer would settle in scoping

- Who signs the approved-by column for each source.
- How a new source gets added, and who can request it.
- What happens to prepared work when a source is withdrawn.

## How to read this sample

The exclusion table matters as much as the approval table. A source boundary
that only lists what is allowed leaves the riskiest question — what is
off-limits — unwritten.