All chapters Introduction

CHAPTER 02 / 12

Bring mail and other working evidence into context

A useful archive can include company mail, attachments, SMS, external reports and calendars. Understand what each source contributes, how it connects and which boundaries follow it.

A project rarely stays inside one inbox. A supplier sends specifications by mail, confirms a collection time by SMS, and changes a meeting in a calendar. An automated system contributes a report. SyncPier makes these sources available for connected work while keeping their origin, meaning and permissions.

Common search and discussion do not make all sources interchangeable. Receiving a report is different from collecting a mailbox; displaying an SMS is different from controlling a phone. Start with the question you want to answer, then choose the source connections and access that can supply trustworthy evidence.

What this chapter explains

  • A source's identity, connection protocol and readable representation are separate facts.
  • Shared management preserves each source's real capabilities and authority.
  • Cross-account context connects related evidence without merging originals or widening access.
On this page
CONCEPTUAL WORKFLOWMany sources, a common point of access
Mail · SMS · reports
Source protocols
SyncPier
MCP / API
Assistants · apps

The source identity stays with the information; access is checked for the consuming assistant or app.

Choose the mail connection separately from the provider

A provider is the service holding an account. A transport is the way SyncPier communicates with it. Company mail can use IMAP; Gmail and Zoho also have provider-specific REST interfaces. JMAP offers another mail connection model within the product's scope. Provider identity should not be confused with the selected connection, and choosing a protocol does not make every possible operation available.

Collection and sending are also distinct. IMAP collects and observes mail; SMTP or a provider's submission interface handles sending. Reading, replying, folders, labels and remote removal require their own supported operations and rights. Changing a connection should preserve proven account and message identity, rather than importing an apparently new history and assuming matching text proves continuity.

Treat attachments as evidence with their own coverage

An attachment can contain the essential detail that the mail body only introduces. Keeping the original message preserves the connection between the sender's words and the attached file. Text extraction can make supported documents searchable; OCR, or optical character recognition, can recover text from supported images. File type, encryption, resource limits and document quality affect what can be extracted.

An attachment name is useful context but does not establish that its contents were read. A body summary may mention a filename without analyzing the file. When the task depends on a price table or a clause, ask for the relevant attachment and its extraction coverage. An unsupported or incomplete part must remain visible as a limitation in the conclusion.

Use SMS context without confusing it with phone control

An SMS relay supplies a source-bound message snapshot to SyncPier. Its exact submitted payload and a readable presentation serve different purposes: one preserves what the relay sent, while the other makes the message usable alongside mail. Device and source identity help distinguish messages that would otherwise look alike, including repeated short confirmations.

SMS retention also has its own boundaries. A server-side archive copy, the local SyncPier copy and the original on a phone are separate. A configured archive operation does not imply permission to erase the phone's messages. Use explicit retention choices for each supported location instead of assuming that removing one copy removes every copy.

Keep reports from agents and automation as durable inputs

External reports can contain research discoveries, development updates or monitoring results. Their producer may be an AI agent or deterministic automation. Direct report submission and a requested collection job are different flows, but both need a clear source and intended audience. Admitted report originals are retained so recovery does not depend on the producer being able to send them again.

A readable report can be searched and discussed with other evidence. Reported authors, model names, citations, timestamps and task references explain provenance; they do not authenticate a person or grant execution rights. A report saying that a task is complete does not itself complete a SyncPier job. Private requested results also remain private unless authorized publication is compatible with the destination audience.

Read calendars as a scoped view of time

A calendar adds events, recurrence, time zones and availability to the working context. A unified view can show selected authorized calendars together while retaining which account and calendar supplied each event. Reading an event does not confer the right to modify it, and a selected calendar view does not represent every calendar a person uses.

Availability requires coverage, not just an empty page of events. A source may disclose only busy intervals; another may be unavailable or incomplete. Missing coverage means availability is unknown, not free. For scheduling work, ask which calendars and time range the observation covers, and distinguish a suggested time from a confirmed change to an event.

Keep the identity of the occurrence

Two messages can contain the same text while remaining different evidence. The account, source occurrence and representation identify what was actually received. A forwarded message, another account's copy and a report quoting an email are not automatically the same original. Matching content may support carefully scoped processing reuse, but it cannot substitute for source authority.

This distinction makes citations and corrections useful. A reader can locate the occurrence supporting a statement, understand whether it is native mail or a generated readable view, and see which representation was inspected. A claimed author in a report or a displayed sender in a generated presentation is not equivalent to authenticated producer identity.

Continue a business conversation across accounts

Business context may outlive an address. A customer can resume a conversation through another mailbox after delivery to the original address fails. A cross-account topic links the related messages and discussion so the work continues without losing the older evidence. Each member message keeps its own identity, reading state and source account.

Topic readership and original access are checked separately. An authorized participant can read the topic's visible discussion while lacking access to some source mail. Membership must not expose hidden bodies, attachments or private comments. Connect what readers are allowed to see, and keep any existence notice about inaccessible evidence free of revealing details.

Questions that come up in practice

Does a connected provider support every mail action?

No. A connection exposes the operations that its protocol, provider behavior, configuration and granted rights support. Search access does not imply sending, moving or removing mail. Evaluate the particular action instead of relying on a provider name.

Can a non-AI system send reports?

Yes. Monitoring, build and other automation can provide external reports. The important properties are enrolled source identity, authorized destination, preserved originals and understandable provenance, rather than whether a model wrote the report.

Can I combine calendars and mail without mixing their permissions?

Yes. Use them together as working context while retaining each source's access checks. A combined view or topic does not create calendar write rights, mail read rights or complete availability coverage.

Once the sources are connected, the next question is what SyncPier retains and how originals remain connected to searchable and prepared information.