Supported native connectors
Use productized connectors where Darwin supports the required objects, direction, frequency, and operational behavior.
Integrations
Darwin uses the connection method appropriate to the system, data, and operating need—then makes the resulting context useful through a governed interface and workflow.
Connection patterns
A reporting view, an event-driven workflow, and an approved write-back have different requirements. Darwin scopes the connection around the first workflow rather than implying that every system works the same way.
Use productized connectors where Darwin supports the required objects, direction, frequency, and operational behavior.
Connect through documented APIs when the source system exposes the access and actions required by the workflow.
Use governed read or write patterns where direct database access is appropriate, available, and contractually permitted.
Support bounded workflows through structured file exchange when a source system has no suitable real-time interface.
Respond to source-system changes when timely operational coordination matters and event interfaces are available.
Configure and operate customer-specific connection patterns within an explicitly defined implementation and support scope.
Beyond data movement
Darwin is not positioned as a generic pipe between applications. The connected data becomes part of an operating view with shared identity, permissions, rules, provenance, Charlie context, and—where agreed—controlled action.
Scope and control
Connector availability, data objects, sync direction, frequency, and write capability must be confirmed for the actual system and workflow.
Source-system licensing, credentials, API limits, data quality, and customer authorization can affect implementation.
Darwin defines ownership, monitoring, failure handling, and change responsibility as part of the integration scope.