Skip to main content

Data Integration

When a source changes shape, nothing breaks quietly.

Every supplier and ERP interface has a versioned contract. Autonera detects drift on arrival, holds affected data and lets the owner approve exactly how mappings change.

How it works

Review drift in two incoming deliveries

Select a delivery to compare it with the active contract. Approve or reject each change; the contract can be published, and quarantined rows released, only when every breaking change is approved.

18,240 rows quarantined

CONTRACT V3 VS DELIVERY

  • item_nostring
  • - descrstring
  • uomstring
  • net_wtstring
  • list_pricenumber
  • countrystring
  • hazmat_flagboolean
  • + description_shortstring
  • + eco_feenumber
Detected changes2 breaking, 1 compatible
  • renameddescr → description_short

    Impacts mapping to Short description. Proposed: Repoint mapping to new field.

  • type changednumber → string

    Impacts mapping to Net weight. Proposed: Add conversion before mapping.

  • addednew number field

    No existing mapping affected. Proposed: Ignore or map new field.

2 breaking changes need approval. 2 mappings affected.

CHANGE LOG

  1. Contract v3 active since last release.

Problems it solves

Where this work usually breaks down

  1. 01

    Silent data loss

    A renamed column loads as empty, and descriptions disappear from thousands of products before anyone notices.

  2. 02

    Type changes that corrupt values

    Weights arriving as text fail conversions or are coerced into zero.

  3. 03

    Mapping fixes made in a hurry

    Integrations are patched in production without review or a record of what changed.

  4. 04

    No agreed definition of the interface

    Without a contract, nobody can say whether a delivery is valid or which side should fix it.

The capability

Interfaces evolve. Mappings should not break silently.

Supplier files and ERP extracts change without warning. A column is renamed in an ERP upgrade, a supplier stops sending country of origin, a weight field arrives as text. Traditional integrations either fail outright or, worse, load the data and silently blank or corrupt the mapped attributes.

Autonera treats each interface as a data contract: a versioned definition of the fields, types and meaning a source is expected to deliver. Every delivery is compared with its contract on arrival. Additions are classified as compatible, while removals, type changes and renames are breaking, and records that depend on them are quarantined in staging rather than loaded.

For each change, Autonera shows which mappings and target attributes are affected and proposes a response: repoint a mapping, add a conversion, retire a target or ignore a new field. The interface owner approves or rejects each change, and the resolved state is published as a new contract version. Processing resumes only after that decision.

Functional capabilities

What Schema Drift & Data Contracts includes

Versioned data contracts
Define expected fields, types and semantics per interface and keep every version.
Drift detection on arrival
Compare each delivery with its contract and classify added, removed, renamed and retyped fields.
Compatibility rules
Configure which changes are compatible and which are breaking per interface.
Quarantine
Hold records affected by breaking changes in staging instead of loading them.
Mapping impact analysis
Show the mappings and target attributes each change affects, with a proposed response.
Owner approval and publication
Approve or reject each change and publish the result as a new contract version.

In industrial operations

A distributor's ERP upgrade changes the nightly item extract

After an ERP upgrade, the nightly item extract renames the description column and sends weights as text.

  1. The first post-upgrade delivery is compared with contract v3 and both breaking changes are detected.
  2. The extract's rows are quarantined; yesterday's product data remains in place.
  3. The integration owner approves repointing the description mapping and adding a numeric conversion for weight.
  4. Contract v4 is published and the quarantined rows are processed under it.

Result: The upgrade causes a controlled review instead of blank descriptions and zero weights across the catalog.

Autonomous operations

How autonomous execution changes schema drift & data contracts

Agents detect drift, prepare impact analyses and propose mapping changes, while interface owners keep authority over the contract.

Agents carry out

  • Compare every delivery with its contract
  • Propose renames by matching values and names
  • Draft mapping and conversion changes
  • Release quarantined records after approval

People decide

  • Approve or reject each breaking change
  • Publish new contract versions
  • Coordinate corrections with source owners

Evidence recorded

  • Contract versions and their differences
  • Quarantine and release history
  • Decisions behind each mapping change

Buyer FAQs

Questions evaluators ask

What counts as a breaking change?

By default, removed fields, renamed fields and type changes are breaking, and added fields are compatible. Compatibility rules can be configured per interface.

What happens to data while a change is reviewed?

Records affected by breaking changes are held in staging. Existing product data stays in place until the change is approved.

How are renamed fields detected?

Autonera compares names and value distributions to propose likely renames, which the interface owner confirms.

Does this work with supplier spreadsheets as well as APIs?

Yes. Contracts apply to files, API payloads and database extracts.

Who approves contract changes?

Each interface has an owner. Approval can be routed through the same workflow used for other governed changes.

Your next step

See Schema Drift & Data Contracts on data like yours.

Bring a real file, catalog or record set. We will walk through how Autonera would handle it and where your team keeps the final say.

Book a Demo