49 lines
1.6 KiB
Markdown
49 lines
1.6 KiB
Markdown
# Governed Connector Configuration
|
|
|
|
GovOPlaN connectors should make integration behavior inspectable and testable.
|
|
The target is not hardcoded glue hidden in module code, but governed connector
|
|
definitions with schemas, mappings, test runs, simulation, versioning, and
|
|
audit-visible execution.
|
|
|
|
## Connector Definition
|
|
|
|
A connector definition should describe:
|
|
|
|
- provider type and protocol
|
|
- endpoint and credential requirements
|
|
- supported capabilities
|
|
- input and output schemas
|
|
- mapping and transformation versions
|
|
- validation rules
|
|
- dry-run and test operations
|
|
- privacy and retention classification
|
|
- expected events and audit records
|
|
- operational limits and retry behavior
|
|
|
|
Provider-specific code may still be required, but the configured integration
|
|
logic should remain visible and reviewable.
|
|
|
|
## Runtime Expectations
|
|
|
|
Connectors should support:
|
|
|
|
- discovery where possible
|
|
- typed configuration through UI-managed controls
|
|
- secret references instead of plaintext secrets
|
|
- dry-run plans before writes
|
|
- simulation with sample payloads
|
|
- provenance for consumed and produced data
|
|
- idempotent external writes where supported
|
|
- quarantine/manual-review state for unsafe or ambiguous results
|
|
|
|
Configuration packages may install connector definitions, but local overrides
|
|
must be protected from accidental package updates.
|
|
|
|
## Relationship To Datasources And Dataflow
|
|
|
|
Recurring extraction and transformation should start as configuration across
|
|
connectors, files, workflow, reporting, and templates. Create dedicated
|
|
datasource or dataflow modules only when repeated source-catalog, lineage,
|
|
mapping, scheduling, or publication contracts clearly outgrow connector
|
|
ownership.
|