Import contracts

Это содержимое пока не доступно на вашем языке.

The same supplier sends the same broken spreadsheet every month, and you pay for it: re-mapping columns, fixing date formats, emailing back to ask for the column they forgot. Your tooling keeps getting better at absorbing the mess. Nobody ever gives the sender a way to get it right before they hit send.

An import contract is that missing thing. It is a file you mint from your own import setup and hand to whoever sends you data. They check their spreadsheet against it before sending — on their own machine — and find out what’s wrong while it is still cheap to fix.

What’s in one

A contract is a signed bundle describing what you accept:

Your target schema, pinned as a snapshot — the columns, their types, which are required.
What the engine already learned about this file shape, when you have imported it before: the header row, the column mapping, the cleanup steps.
Policy — required columns, an optional row cap, accepted encodings.
Engine version pins, so a checker running against an incompatible engine refuses rather than quietly disagreeing with you.
A signature and a content address, so the receiver can tell it came from you and hasn’t been edited.

What is not in one

No data. Not a sample row, not a single cell. A contract describes decisions and shapes — mapping, header row, cleanup rules, column types — and nothing else. That is a property of how it is constructed, not a setting you have to remember to switch on.

This is what makes contracts safe to email. You can hand one to a supplier, a partner, or a prospect without a data-processing conversation, because there is nothing in it to process.

How the sender uses it

They run their file against the contract on their own machine. Nothing is uploaded — not to you, not to us. The check happens entirely on their side, which matters because the file they are checking is usually data you are not allowed to see yet, and often data they would rather not send to a third-party portal either.

What comes back is a report: does the mapping cover every required column, which headers went unrecognized, which rows fail which validation rules, is the signature good, does the file shape still match what the contract expects.

The report says how many rows fail and which rule they fail — never the failing values themselves. A sender can safely run it on data neither you nor we should ever see, and safely send you the report.

Updates are reissues

A contract pins a snapshot. It does not track your schema as it changes, and that is deliberate — a file that quietly changes meaning after you signed it is worse than no file at all. When your schema moves, you mint a new contract and send it out. Contracts can carry an expiry date so a stale one stops being trusted on its own.

Why this is unusual

Data-contract tooling exists, but it points at internal pipelines — your own models, your own warehouse. Import portals exist, but they validate after upload, in someone else’s cloud, which is a non-starter for exactly the regulated counterparties who suffer most from bad files.

A contract that is portable, signed, free of data, and checkable on the sender’s own machine sits in neither category. It moves the fix upstream to where it is cheap, without moving the data anywhere at all.

For agents that produce files

By now a lot of these spreadsheets are generated by software — an agent exporting from one system to feed another. A producing agent has no machine-readable description of what the receiving system will accept, so it generates plausible output and hopes.

A contract turns that guesswork into a check. The agent runs its export against the contract before sending, reads a structured report, and fixes its own output — the same loop a compiler gives a programmer. See agent access over MCP for the rest of the agent surface.

Next steps

The import protocol — the other six artifacts.
Target catalogs — the schema a contract pins a snapshot of.
Agent access over MCP — how agents work an import.