Zum Inhalt springen
MildportDocs
Loslegen

The import protocol

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

Most import tools are a pipeline: a file goes in, records come out, and whatever happened in between is gone. Mildport treats an import as a governed protocol between three actors — a deterministic engine, optional AI, and a human authority — where every step leaves an artifact behind.

The difference shows up the day someone asks a question the pipeline can’t answer. Why is this row’s country “DE”? Who approved that? Can you prove this import happened the way you say it did, to someone who doesn’t trust you? A pipeline shrugs. A protocol has an artifact for each of those.

This page is the map. Each artifact below is a thing you can hold — a document, a log, a signed file — not a feature name.

The seven artifacts

Section titled “The seven artifacts”
Artifact What it is Where to read more
Evidence Every value carries where it came from — source cell, extraction method, a calibrated confidence Capture-first imports
Decisions Every decision records who made it (engine, AI, or person), why, and under which engine version AI transparency
Receipt A signed, portable proof of one import that a third party can verify without access to your system below
Ambiguity ledger What the engine was unsure about, as typed questions with evidence — answerable by a person or an agent Agent access over MCP
Import contract What you accept, exported as a signed file a counterparty checks their file against before sending Import contracts
Changeset An apply is staged, classified and reviewable — and revertible after the fact Agent access over MCP
Benchmark A public import-quality benchmark with per-release scores. Not built yet — planned, and named here so you can hold us to it —

Six exist today. The seventh is on the roadmap, and we would rather list it as missing than quietly leave it out.

Why “protocol” and not “features”

Section titled “Why “protocol” and not “features””

A feature list is a set of things a vendor does for you. A protocol is a set of things you can check — including checking on the vendor. That distinction is the whole point:

  • Evidence and Decisions mean an import can be explained after the fact, by someone who wasn’t there.
  • Receipts and Contracts are files that leave the system. They stay meaningful when Mildport isn’t running — and when you are handing them to someone who has no reason to believe you.
  • The ambiguity ledger and changesets mean the engine can say “I don’t know” and “undo that” — two sentences most import tools cannot say at all.

The engine is liberal in what an import accepts and strict in what it emits. Messy input is the job, not an error condition; the records and artifacts that come out the far side are typed, versioned and checkable. Strictness lives at the exit, not the entrance.

But the input is chaos — what is there to protocol?

Section titled “But the input is chaos — what is there to protocol?”

A fair objection: if the whole job is turning messy files into clean records, what could a protocol possibly govern? Nobody can standardize the files — every attempt to discipline senders has failed, and Mildport doesn’t try. The protocol is not on the input side.

An import has two halves. Chaos → structure is the engine’s half: parsing, matching, extraction. No rules are possible there, and none are imposed. Structure → your system of record is the half that gets forgotten: once clean rows exist, someone has to trust them enough to write them into production. That is where the real questions live:

  • Why did the column “Kundennr.” become customer_id — and who decided?
  • The engine wasn’t sure about one row’s date format. Did it guess, or did it ask?
  • The apply wrote 8,000 records. Can it be undone?
  • A year later, an auditor asks you to prove this import happened the way you say it did.

A pipeline answers all four with trust us. The protocol is the rulebook for exactly this half: evidence on every value, uncertainty recorded as questions with recorded answers, applies staged as revertible changesets, and a signed receipt that answers the auditor with no vendor in the loop.

And there genuinely are two parties. Every import has a sender — the person or agent with the file — and a receiving system, and today their interaction has no rules at all: someone attaches a file to an email and hopes. The import contract is the first rule that interaction has ever had — a signed, data-free check the sender runs before sending. The dependency runs the right way around: it is because the engine absorbs unlimited chaos at the entrance that strict promises at the exit are affordable.

In one line: the engine eats the chaos; the protocol is the paper trail that proves what came out of it.

Receipts

Section titled “Receipts”

When an import is applied, the engine can issue a signed receipt: the decision log plus the outcome, canonicalized and signed with your instance’s key as a detached JWS. It records lineage, actor and confidence — and it is redaction-safe by construction, so it can be handed to an auditor without handing over the data.

Verification and license checks never phone home. There is no lookup service and no Mildport-hosted endpoint in the loop — the same posture as license verification, which checks a signature against a public key you deploy yourself.

Agents speak it too

Section titled “Agents speak it too”

The same governed surface is available to AI agents over MCP — reading evidence, working the ambiguity ledger, inspecting and reverting changesets. An agent gets no privileged path: it answers the same typed questions a person would, its answers are attributed to it in the decision log, and the write surface is off by default.

This matters in both directions. An agent consuming an import needs a trust signal it can act on rather than a wall of prose. An agent producing a file needs something to check its output against before sending — which is exactly what an import contract is.

Next steps

Section titled “Next steps”