Skip to main content
Use the @bijection/connectors/dbos entrypoint to declare DBOS workflows resources.

​
Availability

This page describes the pinned source package. Published availability is unestablished for this artifact. Source build and package availability.

​
Resources and modes

Declare a resource in application code, then bind deployment-specific settings and credentials. See typed resources, connections and source inspection.

​
Workflow

​
observed: observed

The following example matches configuration standard.
The function references identify application policy queries. Implement those policies in your application; the references alone grant no authority.

​
Configuration: standard

Case: dbos/workflow/observed/standard. Connection and resource configuration are declared by this exact case. Credential kind: http. Keep credential material in the private credential inventory.
Native admission analysis is available for this exact declaration. Collection: records
Commands
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Provider guidance

dbos.workflow.observed declares a customer-owned DBOS application through the native HTTP connection, source observation and command owners. Capture an explicit dbos.contract project, generate its application descriptor and worker helpers, and pin the release. The optional dbos/worker and dbos/adapter entrypoints use DBOS SDK 5.3.0; application descriptors import neither the SDK nor PostgreSQL. Starts confirm the exact persisted execution envelope. Business commands run as separate DBOS workflows and confirm only a successful, matching output envelope. A declared refusal field maps a business refusal to a refused native command. Messages run through generated command workflows: their receipt proves durable message delivery, not processing or a business decision. Cancellation similarly confirms a runtime cancellation request; it establishes neither compensation nor business completion. Customer domain transactions own consequential decisions. The customer-hosted adapter uses the official DBOSClient in the customer network. It owns no journal, schema migrations, queue provisioning or worker process. serveAdapter binds loopback; terminate authenticated HTTPS in front of it. Its private PostgreSQL pool has statement, connection and transaction deadlines. Secret files must be bounded owner-only regular files. Give the adapter only the runtime privileges needed for the declared DBOS interactions, and provision its system schema, queues and application versions separately. Identity checks read application versions and queue ownership for current and retained releases. They perform no business probes. Generated handler/build manifests and retention policies are customer attestations; read-only checks do not establish worker liveness, mutation privileges or handler behavior. Deployment candidate checks issue the same confined identity GET before activation. Ordinary installation checks remain in place after activation. Recovery reads the original command’s stored input, workflow name, queue, application, version, creation identity and output envelope. It never enqueues. Missing history remains unknown. Execution references retain the original creation identity and command envelope digest. Observation keys include immutable business positions; runtime status remains separate. Paging is bounded by count and bytes, visits explicitly tracked originals first and advances over unrelated entries. The application epoch requires no deletion, rewind or ID reuse for attached executions during retention. DBOS rewind can preserve an ID; available SDK evidence cannot prove continuity across arbitrary administrator rewrites. Change epoch and explicitly reassociate work after such intervention. Preserve old adapter endpoints, contract artifacts, worker versions and credentials while accepted calls depend on them. Retained deployments in one release share its contract; contract changes require separately retained declarations and bindings. The approval example in Bijection demonstrates transactional decision receipts, notification repair, frozen review terms, current authorization, typed result reads and runtime cancellation. Shared workflows helpers only present values already read through authorized native owners. No result helper grants access based on a call identifier. Source implementation and portable tests exist. Hosted DBOS qualification has not been established; it must be explicitly requested through Atlas with customer resource isolation, exact serving identities, assertions and cleanup ownership. Executions remain observable before their first progress event: the source retains the typed original input and runtime status, with a null business snapshot and revision -1. Applications must not derive approval terms from that absence. The example authorizes those rows by the original input tenant and displays startup failures separately from reviewable business observations.

​
Application helpers

All workflow adapters share one application vocabulary. Object-typed inputs are named command arguments, optional fields included: adding an optional field never wraps or renames existing arguments. Other values travel as input. Bijection-owned members are camelCase (start, requestCancellation); names a contract declares keep their spelling. Serialized routes, capability keys and records keep their snake_case wire names. <adapter>.commands(contract) returns each command’s target and argument validators for commandPolicy from bijection/server, so a policy module types its inputs without importing the schema that installs the resource. <adapter>.policies(contract, "permissions", { reads }) references one exported policy per command name (permissions:decideShipment, …). Names follow the contract; a missing export fails deployment analysis. <adapter>.observations.select(rows, { bound }) interprets acquired execution rows the application read through its own indexed queries. It returns current, missing, conflict (with its reason) or exceeded; it never invents ordering or infers deletion from absence. The application still decides business association, actor permission and acceptable freshness. <adapter>.trace(...) resolves a retained call’s interaction from the generated capabilities and composes it with an authorized observation.

​
Provider references

Provider references and prerequisites are maintained in the connector guidance above. No separate provider-documentation review date is recorded.

​
Source and evidence

Canonical connector source, native analysis and check receipts. Connector artifact: 905888ea276a2a28e36981a79e8142b2547ea451c3e63162cb6915ad4a7d1305. The resource declaration examples above are compiled and compared with exact catalog declarations. Recorded checks apply only to their source, declaration and runtime identities. Configure a connection and inspect its status to establish deployment-specific readiness.