Connected preparation

Prepare a client reply from Gmail or Fastmail, a Telegram message, or a GitHub issue comment through the same Reach boundary. The result records the selected account, exact target, application payload, policy and expiry. It can be inspected without connecting an account or contacting a provider.

reach.connect.prepare@1 is an explicit offline profile. It does not activate or widen reach.discord@1, and does not qualify the operational reach.correspondence@1 successor proposed in the connected-work study. State of Work owns its evidence and the remaining deployment boundary.

One intent, several concrete channels

The shared request is semantic: read bounded correspondence or prepare text for one selected target. Provider builders translate it into their own protocol subset. They do not turn every service into an email server or expose an arbitrary API URL, method or shell command. A provider that cannot perform the requested operation refuses it.

The read subset is explicit: Gmail lists bounded message IDs, Fastmail queries a bounded header/preview projection, and Discord/GitHub list bounded conversation messages/comments. These plans do not implement arbitrary mailbox search or full Gmail message-body retrieval. Thread-scoped email reads, Telegram chat-history reads, WhatsApp history and social reads refuse. Telegram's bot-wide getUpdates would also acknowledge offset advancement; it cannot stand in for a target-scoped read. A Discord reply fails if its exact referenced message no longer exists.

A preparation policy defines one partition, exact connection snapshots, exact targets, operations, bounds and lifetime. Its connection IDs are local references; the provider account and actor IDs are external observations and do not become WardSecurity DeskSecurity Desk Principals. Allowing preparation therefore grants no send authority. Nor can matching display names or email addresses link two accounts.

Call the native Graph

The explicit factory builds an ordinary serial score. It validates the admitted request, prepares the provider payloads, and projects the resulting plan. The state binds the canonical RunJob RecordJob Record, session, policy and exact request; live handles remain dependencies. A caller must assemble this profile explicitly, because normal application boot installs no connected profile.

The corrected payload generator uses implementation py.2 under the same PatternWorkflowWorkflow revision 1. Runs pinned to py.1 refuse execution against it; prepare a fresh offline RunJob Record instead of resuming with different request bytes. This changes no live delivery or replay authority.

flowchart LR
    I[Explicit bounded request] --> V[Validate account, target and policy]
    V --> P[Prepare provider requests]
    P --> O[Return immutable plan]
    O -. later authority and durable delivery .-> E[Provider transport]

Inspect the plan as a prepared application request. It contains application bytes and a provider route selector, with no bearer token, credential URL or SDK session. Later transport still needs its own setup: the Telegram credential owner must insert a token, and Fastmail requires an authenticated JMAP Session and admitted API endpoint. The plan's digest binds only the prepared application request, not transport headers or the provider's eventual response.

There is no effect executor in this profile. Saving a provider draft would already disclose data and is therefore a later admitted write. Read plans also require current authority and disclosure checks before a future transport fetches private data. No model receives any correspondence here.

Preview the synthetic release announcement without credentials:

uv run --locked python scripts/reach_connect_prepare.py \
  --policy examples/reach/connected/policy.json \
  --requests examples/reach/connected/wuphf.json

Use founder-policy.json and founder-launch.json in the same directory for Fastmail plus Facebook Page, LinkedIn member and X launch-copy preparation. Both fixtures use invented accounts. The default output reports only preparation status and count. --include-payload explicitly prints the private application requests for inspection; protect that output like correspondence.

For native execution, assemble lychd.compositions.reach.connected.workflow.connected_preparation_workflow(policy, clock=clock, record_result=sink) in an explicit registry and submit the IntentRequestRequest from make_connected_intent(policy, requests, session_id=session.id, now=clock()) through the ordinary RunEngine. The registry, session and result sink belong to that caller; no startup selector or durable correspondence ledger is implied.

WUPHF as finite preparation

“Announce this accepted release in these three places” selects a finite tuple of explicit targets. Reach validates every item before returning the batch. Duplicate request identities and duplicate operation/target pairs refuse; a forbidden destination does not disappear from an apparently successful result. Each provider payload and the complete batch have separate bindings.

This is preparation inside a serial GraphStep MapStep Map station. It uses no GraphStep Map broadcast/map/join primitive, background sender or parallel executor. A future sender must settle each target independently: one accepted email cannot prove that a chat message or post was accepted. An unknown result must remain visible and cannot trigger a blind replay of the whole batch.

Reach owns correspondence and destination policy. Broadcast owns editorial acceptance and publication judgment. An already accepted announcement can enter Reach as settled input. Commissioning and waiting for several live CompositionAppApp InvocationsJob RequestsJob Requests would instead need a Suite.

Journeys and refusal cases

The account lifecycle and social assessment distinguish provider access, organic publication and advertising. The acceptance plan retains the durable outbox, credential, current-authority, revocation and live-provider work needed before actual delivery.

Reach architecture · Accounts