Connector boundaries
Runtime is in development. These guides explain design intent; they are not a released API or installation reference. Read the release policy →
A connector is a boundary contract
Section titled “A connector is a boundary contract”A connector mediates between integration work and an external system. Its design includes more than request formatting: lifecycle, resources, concurrency, cancellation, authentication, and failure mapping all affect correctness.
There is no public ZERNOVA connector SDK or authoring API on this site.
Make ownership explicit
Section titled “Make ownership explicit”Decide who creates and closes clients, who owns connection pools, and which resources can be shared safely. Describe whether an operation can block, how demand is bounded, and what cancellation means after a remote request has been sent.
Define the contract before the implementation
Section titled “Define the contract before the implementation”| Boundary | Questions to resolve |
|---|---|
| Input and output | Types, encoding, size limits, and streaming behavior |
| Lifecycle | Initialization, reuse, shutdown, and cleanup |
| Authentication | Credential source, rotation, and redaction |
| Failure | Error categories and uncertain outcomes |
| Compatibility | Engine versions and external service versions |
Plan contract tests
Section titled “Plan contract tests”Test malformed responses, slow services, partial reads, authentication rejection, exhausted resources, and shutdown during work. Verify that secrets do not appear in failure reports. Repeated attempts must be tested against the downstream system’s idempotency contract.
Future authoring documentation
Section titled “Future authoring documentation”A released guide needs package coordinates, interface definitions, a compilable sample, compatibility tests, and license requirements. Until those exist, no sample connector repository or registration command is linked here.
See SDK readiness and HTTP boundaries for adjacent decisions.