CONN
Connector Engines
1. Identity
| Attribute | Value |
|---|---|
| Type code | CONN |
| Canonical name | Connector Engines |
| Parent type | — |
| Type status | review |
| Tier scope | pre-tier, tier-0 |
| Invocation | ingress |
| Payload effect | derive |
| Lineage role | stamps-cmi |
CONN is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: CONN. The type itself has no MEID, no CMI and no runtime presence.
2. Purpose and boundary
Connector Engines (CONN) are the boundary with external structured systems: ERP and general-ledger systems, accounts-payable systems, emission-factor and EPD databases, air-quality and other data APIs, and partner ECO entities in federation.
A connector authenticates, fetches or pushes, maps the foreign schema onto a ZAYAZ contract through a registered mapping profile, records source provenance per record, and hands the result to VALI. It materialises nothing from unstructured content (that is EXTR), validates nothing beyond the mapping, and computes nothing.
CONN runs in both directions: IMPORT and SYNCHRONIZE bring external records in; EXPORT releases artifacts that a CTRL decision has marked releasable.
3. Membership criteria
3.1 Inclusion tests
A micro engine is a member of CONN when its specification satisfies the following:
- Its source or target is an external system with a defined interface — an API, a database, a file format with a schema, a message queue.
- Its output is the external records mapped onto a ZAYAZ contract, with source provenance on every record.
- It performs no computation, no business validation and no interpretation; the mapping is declarative and registered.
- Its runs are windowed and idempotent — the same window and mapping version yield the same records — and every run records its window and source cursor.
- Its MEID capability is
IMPORT,EXPORTorSYNCHRONIZE; its CMI kind isCONNECTOR,ENGINEorJOB.
3.2 Exclusions
A micro engine is not a member of CONN when any of the following is its responsibility; each belongs to the type named:
- ❌ materialise structure from unstructured material (EXTR)
- ❌ validate business rules or completeness (VALI)
- ❌ convert units or reshape structures beyond the mapping profile (TRFM)
- ❌ compute or aggregate (CALC, AGGR)
- ❌ decide routing, quarantine or what may be released (CTRL)
3.3 Boundary cases
- CONN versus EXTR: a document, scan, text or feed without usable structure is EXTR; a structured source reached through an API, database or schema-bearing file format is CONN.
- CONN versus TRFM: field mapping and type coercion declared in the mapping profile are CONN; unit conversion or structural reshaping beyond the profile is TRFM.
- CONN versus CTRL: the federation exchange engine carries artifacts across ECO entities (CONN); the decision which artifacts may leave, and with which redactions, is CTRL.
- CONN versus RSLU: a connector keeps the foreign identifiers it received; resolving them to canonical ZAYAZ entities is RSLU.
4. Design rules
The mapping from the foreign schema to the ZAYAZ contract SHALL be a registered, versioned mapping profile. A connector SHALL NOT carry mapping logic outside that profile.
Every record SHALL carry the source system identity, the endpoint or query, the external record identifier and the retrieval timestamp.
A connector SHALL be re-runnable for the same window without producing duplicates, and SHALL record the window and cursor of every run.
A connector SHALL NOT alter values, infer missing fields or apply business rules. Records that cannot be mapped SHALL be emitted as rejects with a reason; they SHALL NOT be dropped.
A connector SHALL execute with tenant-scoped credentials from the platform secret store. Credentials SHALL NOT appear in payloads, logs or lineage.
An EXPORT or SYNCHRONIZE member SHALL release only artifacts that a CTRL decision has marked releasable, with the redactions that decision prescribes.
5. Contract
5.1 Inputs
CONN engines consume:
- a connection profile (system, endpoint, tenant binding, credential reference),
- a registered mapping profile and its version,
- a fetch window or cursor, or — for export — the set of artifacts a CTRL decision released.
5.2 Outputs
CONN engines emit:
- records mapped onto the target contract, each with source provenance,
- rejects with reasons for unmappable records,
- the run record (window, cursor, counts, mapping version),
- for export: delivery receipts from the external party.
Consumers: VALI (first stop for every imported record), TRFM, CALC, META; partner ECO entities for exports.
6. Position in the computation chain
6.1 Placement
External system → CONN (import) → VALI → TRFM → CALC / AGGR …
CTRL (decision) → CONN (export / synchronize) → partner ECO entity
6.2 Interaction with ZSSR
ZSSR schedules and selects connectors by connection profile and mapping version. Tags such as connector or the source system name are discovery hints only; explicit rules bind a connector to a tenant and a window.
7. Identity rules for members
Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:
mice.categorySHALL beCONN.- The
CAPABILITYsegment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one ofIMPORT,EXPORT,SYNCHRONIZE. - The
DOMAINsegment SHALL be any registered MEID domain. - Typical
FUNCTIONsegments:IMPORTER,EXPORTER,SYNCHRONIZER,CRAWLER,EMISSION_FACTOR,EPD,ACCOUNTS_PAYABLE,AIR_QUALITY,FEDERATION. - CMI kinds bound through
zar.meid_cmi_bindingSHALL be amongENGINE,CONNECTOR,JOB. - Lineage: members append their CMI stamp to the USO lineage tail.
- Tier scope: pre-tier, tier-0; invocation: ingress; payload effect: derive.
10. Members
11. Related types
- CTRL — Control & Governance Engines
- VALI — Validator Engines
- TRFM — Transformation Engines
- CALC — Calculation Engines
- META — Metadata Enrichment Engines
- EXTR — Extraction Engines