Skip to main content
Use the @bijection/connectors/temporal entrypoint to declare Temporal 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: temporal/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

Temporal keeps workflow execution and customer workers. This resource uses the stateless bijection temporal serve gRPC bridge and the existing Bijection HTTP request, external-call and record-observation owners. The bridge holds no journal and starts no workers. Compile a workflow contract with bijection temporal generate. The source may be portable JSON or a TypeScript module whose default export is defineContract(...) from @bijection/connectors/temporal/contract. Import the generated artifact, then declare: Compiled declaration examples and configuration details are published in the connector reference. Bind setup.endpoint, setup.namespace_id (the immutable Temporal namespace UUID), and setup.task_queue to the authenticated HTTPS bridge and use temporal.credential("TEMPORAL_ORDERS") for its private HTTP bearer credential. The bridge configuration names the compiled artifact and release manifest. Temporal namespace, task queue, API key or mTLS files belong to the bridge’s operator configuration. Its listener binds loopback; remote deployments put it behind their existing authenticated TLS ingress. The ordinary ctx.calls.add path accepts start, Update, Signal and cancellation commands. A start addresses the collection; other commands address one acquired local workflow row. A message with one object argument exposes that object’s fields as command arguments, optional fields included. Several positional arguments, or one non-object argument, require parameters naming each position; Temporal still receives the positional tuple. requestCancellation takes no arguments. Every command requires its native governing rule. The resource’s ordinary read rule governs workflow facts and their disclosure. The target key freezes Workflow ID, Run ID and first Run ID. Updates use the native operation ID as Update ID; recovery polls that exact run. Signals and cancellations report server acceptance and never imply handler completion. Unknown commands are not automatically resent. Signals and cancellation can be accepted while workers are offline; they use the acquired contract-stamped target and service identity rather than requiring a fresh worker query. Start reconciliation checks the original request, argument digest and contract in the execution’s memo. Discovery uses Visibility only to find candidate executions. Published records come from exact execution descriptions and the declared progress query, after the worker’s generated __bijection_contract handshake matches. Records expose workflow_id, run_id, first_run_id, previous_run_id, lifecycle, progress, result and observed_at. Completion results are validated against the workflow result schema, and predecessor IDs come from exact start history. Distinct facts have content-addressed record keys and expose progress_revision, history_length, observation_id and contract_digest; applications select the newest revision/history position and refuse equal-position conflicts. A late response cannot overwrite a newer source identity. The record protocol makes no complete-history or deletion claim. Application operations must verify tenant/order/process identity before attaching a row. The supported encoding is Temporal json/plain, with bounded explicit schemas. Custom converters are refused. Worker bindings include deterministic validation and typed SDK messages. The customer must install the generated contract handler and implement its workflow messages. Update refusal_kind optionally declares a business result’s kind that denotes refusal; other schema-valid completed Updates establish their declared completion only. Their full result stays in the retained response evidence; ordinary call inspection exposes delivery status. The Go CLI bridge tests and package declaration tests do not establish deployed qualification. The catalog names remaining native coverage explicitly. Read-only binding checks validate server/namespace identity and retention, the current/ramping/tracked worker versions and task queue membership against the release. Known executions may be named in release.executions. Missing pollers are an availability warning. Protocol, namespace, task queue, interface and release are carried in host-bound request headers; use distinct immutable bridge endpoints for changed bindings and keep original endpoints for retained calls. Worker generation is optional. ContractTypes<typeof contract> exposes portable argument tuples and result types without a general-purpose Temporal client.

​
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. temporal.observations.select orders one run by progress revision and history length. temporal.observations.follow({ contract, start, runs, successors, bound }) follows continue-as-new successors from an associated run, keeping contract, workflow, first-run and declared identity fields, and refuses ambiguous successors.

​
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.