Source Discovery Manifest

Purpose#

Complete this manifest before finalizing connector order or claiming that a client's operating data is understood.

The manifest prevents a connected-system list from becoming a false picture of the business. It includes structured systems, human-maintained workspaces, files, messages, forgotten repositories, and sources that are known but not yet accessible.

Client:
Discovery owner:
Started:
Last reviewed:
Client approver:
Status: Draft / Reviewed / Complete for current scope

Completion rule#

The manifest is complete for a phase when:

• Every named source has an accountable owner.
• Every source is classified as connected, accessible-manual, known-unconnected, unavailable, or intentionally excluded.
• Exclusions have a reason, risk assessment, and approver.
• Unknown-source discovery questions have been asked across departments.
• Known-unconnected sources remain visible in the Property Knowledge Audit.
• The client acknowledges that later-discovered sources will be added without invalidating earlier evidence.

Source register#

Required detail per source#

For each source, attach or link a source profile containing:

Ownership and access#

• Who creates and maintains the information?
• Who can authorize access?
• Is access individual, shared, service-account, export-only, or manual?
• Are API scopes, vendor terms, or retention restrictions relevant?
• Can access be made read-only?

Contents and grain#

• Which resource types exist?
• What is the stable external identifier?
• What fields, files, events, or relationships exist?
• Is the source a system of entry, approval surface, current mirror, publication destination, or historical archive?
• Does prose duplicate structured facts?

History and change behavior#

• Is version history available?
• Are deletions observable?
• Are created, updated, observed, and effective timestamps available?
• Does the source support webhooks, cursors, ETags, exports, or point-in-time snapshots?
• What is the expected change frequency?

Authority and conflict#

• Which fields does the client intentionally maintain here?
• Is it authoritative, advisory, or merely a copy?
• Who approves changes?
• What other sources may disagree?
• Are there known historical mistakes?

Safety and privacy#

• Which data is public, internal, sensitive, or restricted?
• Does it contain guest, owner, employee, financial, identity, payment, or access data?
• May the content reach an external AI model?
• What retention, deletion, residency, or legal-hold requirements apply?

Capture and recovery#

• Can original payloads or file bytes be preserved?
• What source metadata and permissions must accompany them?
• How will captures be hashed and replayed?
• How will a current mirror be rebuilt?
• How will capture completeness be verified?

Destination behavior#

• Can the system be written to?
• Which fields are safe and contractually permitted to write?
• Does it support dry runs, validation, idempotency, readback, rollback, or audit history?
• What is the smallest safe canary?

Unknown-source discovery interview#

Ask each functional owner:

1. Where do you look when the PMS is wrong or incomplete?
2. Which spreadsheet, document, folder, inbox, or chat contains information only your team knows?
3. Where are owner exceptions, special instructions, and historical decisions recorded?
4. Where do new-property details originate before entering the PMS?
5. Which data is copied manually between systems?
6. Which exports or reports are kept because the source system cannot answer a question later?
7. Which former vendors still contain history?
8. Which local computer, shared drive, or employee-owned account contains business records?
9. Which dashboard numbers are calculated outside the underlying system?
10. Which system would create the biggest operational problem if access disappeared tomorrow?
11. Which data should never reach an external AI provider?
12. Which information does the team routinely discover is outdated or contradictory?

Source-state classifications#

• Connected: automated permitted capture is operating and monitored.
• Accessible-manual: authorized export or manual capture is available.
• Known-unconnected: relevant source is known but integration/access is pending.
• Unavailable: relevant source cannot currently be accessed; impact is documented.
• Excluded: intentionally out of scope under an approved reason and risk decision.
• Retired: no longer active but retained for history.

Capture acceptance checklist#

• Source identity and accountable owner recorded.
• Access is authorized and least-privileged.
• Sample capture preserves native content and metadata.
• Content hash and timestamps are verified.
• External identities map without becoming internal identity.
• History and deletion behavior are understood.
• Sensitivity, retention, and AI-routing policies are assigned.
• Candidate-authority fields are documented.
• Current mirror can be rebuilt from raw capture.
• Sync health and staleness can be measured.
• Any write capability remains disabled until separately approved.

Discovery sign-off#

Known sources reviewed by:
Known-unconnected sources accepted by:
Approved exclusions:
Highest-risk missing source:
First connector selected and why:
Next review date:

Sign-off means the inventory is a credible basis for the current phase. It does not claim that no additional source will ever be discovered.