- accept a provider occurrence that passed the exact provider and adapter proof contract, then ingest it into a Session, and
- present committed Session output back to the provider.
What a verified occurrence means
In these docs, a provider occurrence is verified only when the exact provider and adapter contract supplies the required signature or other trusted proof and the adapter boundary validates that proof successfully before callingConversationIngest.
A signed webhook is one possible mechanism. Another provider may use a different trusted proof. Some provider or adapter paths may expose no equivalent cryptographic mechanism. Constructing an adapter, parsing a callback, or receiving a provider-owned ID is not a universal verification guarantee.
Installation pairing, private-scope membership, occurrence verification, occurrence identity, and author resolution are separate contracts. Proof for one does not silently prove the others.
One conversation, one Session truth
A provider callback is not a second conversation record. After the exact occurrence proof succeeds, the adapter normalizes the provider tenant, governed place, canonical conversation, author when required, and occurrence identity into Checkfu resources:Occurrence identity and redelivery
When the provider and adapter expose a stable occurrence ID, the adapter supplies it as the external event identity. Checkfu claims that identity under the ExternalInstallation. A provider redelivery carrying the same stable ID can converge on the existing disposition instead of driving twice. This is not universal deduplication. If an adapter lacks a stable provider occurrence ID, the host cannot manufacture an equivalent durable identity. That path may downgrade to at-most-once acceptance for the callback it receives. The maintained conversation host does not retryConversationIngest. Before acceptance, recovery therefore depends on the provider redelivering the same stable identity. After acceptance, observation recovery no longer depends on redelivery: the exact Session event coordinate is stored in a content-free durable observation job.
Author and actor identity
The provider installation, occurrence author, Session requester, and AgentInstallation execution actor are different identities. An authoredinvoke occurrence requires the person Principal named by the current ConversationIngest contract. The trusted adapter or backend first validates the provider occurrence, then resolves the installation-scoped provider member through an ExternalIdentityLink. The first trusted resolution for an unseen member may mint a person Principal. Later resolutions return the active linked Principal. A revoked link or a resolution that does not yield the required active person fails closed.
An autonomous AgentInstallation executes as a service Principal. A delegated AgentInstallation executes as a person Principal. Neither rule turns the ExternalInstallation itself into an author.
An observe occurrence may carry a Principal or be authorless, as with a provider-authenticated deletion. An authorless observation never invents a person, never creates a Session when no live interaction binding exists, and never becomes an authored invocation merely because it came from a provider.
Durable acceptance and observation recovery
The maintained host resolves provider identity and the canonical binding, then durably ingests the exact occurrence before scanning Session history. For an authored turn, the ingest receipt carries the exact event ID and sequence. The host atomically opens a content-free observation job for those coordinates before returning a successful callback response. An incomplete Session-log walk delays interpretation rather than dropping accepted input. The per-process projection cache is an optimization only; after eviction, the host refolds from the Session log. A later host process can adopt the journaled job under the shared state lock and continue observation without another provider delivery. Observation recovery is not provider presentation recovery. A recovered job has Session coordinates but not the live provider thread object needed to post. It can finish accounting and observation, but it does not replay a provider-visible reply. A provider redelivery with the same stable ID can adopt the same job and supplies a live callback context again.Presentation
Presentation begins only from committed, readable Session output. A provider draft, typing indicator, local callback result, or in-memory token stream is not an answer. A presentation attempt is an external-effect boundary:indeterminate when the current process can record it.
Presentation custody is restart-safe without turning uncertainty into a resend. The maintained host persists a content-free pre-claim intent and one job for each presentation generation. After provider completion it records the exact invocation token and settlement fact before settling, so a restart can retry settlement without repeating provider I/O. A lost claim receipt can be recovered from the pre-claim intent. Claimed work may continue only with a live rented adapter; dispatching work is never resent. After the lease and grace period, an abandoned dispatching generation terminalizes indeterminate at the same generation unless an exact retained provider receipt proves a stronger result. Lease expiry is never permission to resend.
Progress indicators are presentation hints. Final results, failures, and human waits derive from the Session log. Provider message IDs and projection cursors may be retained as content-free coordination, but provider message bodies do not become canonical history.
Approvals stay in Checkfu
A provider callback cannot settle an ActionApproval. A provider button is presentation only. When a Session waits for approval, a Channel may present the signed Checkfu approval link already carried by committed Session output. The authorized human decides on the Checkfu surface under Checkfu’s identity and version fences. The Channel can later render the committed resolution. It does not maintain a parallel provider-side approval ledger.ZDR and recovery
Under zero-data-retention custody, execution content may be available only to a live subscriber. The content-free observation journal may preserve IDs, sequences, and timestamps, but it cannot reconstruct omitted messages or output after restart. A recovered job that missed live-only output is completed or aged out without inventing a reply. Standard-retention Sessions can be replayed from the Session event log, subject to the Workspace retention model. Replay rebuilds a projection. It does not transfer transcript authority to the Channel or guarantee recovery of a provider post whose effect is uncertain.What provider-neutral means
Provider adapters may differ in proof mechanisms, acknowledgement behavior, occurrence IDs, reactions, ephemeral messages, rate limits, and message APIs. Those differences stay behind the adapter boundary. Public Checkfu concepts remain the same:
Provider capability in source code is not production support. Live-provider qualification, the maintained host limits, and capability status determine what can be claimed.
Next steps
Installations and surface scopes
Establish the provider tenant, governed place, and Agent placement.
Conversation bindings
Map a canonical provider conversation to one Session.
Action approvals
Keep the decision and execution fence in Checkfu.
Computer and Screens
Add provider-neutral visual execution and observation.