AIP-MCP · Private integration between companies

Your systems
need to talk.
Your data doesn't.

Two companies connect their software without either side handing over its data, its systems, or its code. AIP-MCP maps what the field names and types justify, asks a person about the rest, and produces a bridge that cannot reach the network. Not by promise. By construction.

Request a pilot See how it works

Mission

Make it possible for two companies to integrate without either one having to trust the other, or anyone in between.

The problem

Integration stalls on a question that isn't technical.

One system calls it full_name. The other calls it name. Reconciling that takes an engineer, and that engineer has to see both sides.

So the work stops on who is allowed to look. Legal negotiates. Compliance scope widens. Integrations that should take days take quarters, and the ones between competitors never happen at all.

End to end

The whole thing, start to finish.

Two companies that have never shared anything, from first contact to a verified bridge.

Animated walkthrough of two companies integrating through AIP-MCP Shared zone · no raw data Company A nameemailstatus weight mass "Dana W."dana@…"ACTIVE"1000 g stringstringenumnumber "Dana W."dana@…"ACTIVE"1000 g Company B nameemailstageweight expectsexpectsexpectsin lb stringstringenumnumber "Dana W."dana@…"customer"2.20462 lb Bridge ? ✓ g → lb Comparing shapes 1 question for a person Checked Sealed · no network access Running Field renamed · rebuilt

The boundary

Watch the values disappear.

Nothing real crosses the boundary. Types survive so a bridge can be proposed. Every value, identifier and category is reduced to its shape.

Inside the company

customer_name"Dana Whitfield"
email"dana@northwind.io"
account_status"ACTIVE"
annual_value248500

What leaves the company

customer_name·
email·
account_status·
annual_value·

Worked example

A benefits platform onboards three customers.

Every enterprise runs some HR system, and no two name things the same way. For a software vendor, each new customer means another integration, and another argument about employee data.

Animated example of a benefits platform onboarding three customers with different HR systems Shared zone · no employee data 6 weeks · an engineer sees everything 6 weeks · a new data agreement 6 weeks · and again Customer 1worker_idlegal_nameannual_salary Customer 2emp_nodisplay_namepay_rate Customer 3associate_oidformatted_namebase_pay Benefits platform One canonical shape employee_idfull_namesalary_usd Reading shapes Confirmed by a person Sealed Running Sealed Reading shapes Confirmed by a person Sealed Running Rebuilt Reading shapes Confirmed by a person Sealed Running Sealed

Onboarding today

  • A solutions engineer per customer, for weeks
  • A data-processing agreement negotiated each time
  • Your staff handling their employees' records
  • Every HR system upgrade breaks something

Onboarding with AIP-MCP

  • The customer describes their system once, privately
  • No employee data ever reaches your platform's builders
  • A narrower compliance footprint to negotiate
  • Format changes are caught, then rebuilt or held for a person

Use cases

Three integrations, from first call to a verified bridge.

Each one is a situation companies are in right now: what they are trying to do, how it goes with today's tools, and the same job done through AIP-MCP, step by step.

Scenario

A home-goods retailer is moving its warehousing to a new third-party logistics provider. Every order has to land in the 3PL's warehouse system in the 3PL's format: weights in pounds, its own field names, its own service codes. The retailer's order system works in grams and names its fields and its delivery services differently.

Objective

Be shipping from the new warehouse before the holiday peak, without giving the 3PL's integration team a login to the order system. The same 3PL ships for two of the retailer's competitors.

How this goes today

  • A joint project: mapping workshops, a shared test environment, sample files of real orders sent by email
  • The 3PL's engineers read customer names and home addresses while they build
  • The unit conversion lives in hand-written code that gets reviewed once, if at all
  • When either side changes a field, orders fail quietly until a customer calls
In the real world

In 1999 NASA lost the Mars Climate Orbiter because a contractor's software reported thruster impulse in pound-force seconds and the navigation software expected newton-seconds. Two organizations, one interface, one unit nobody checked.

With AIP-MCP, start to finish (illustrative)

  1. Set upEach side, separately

    Each company installs AIP-MCP inside its own network. Nothing is hosted in the middle, and neither side gets an account on the other's system.

  2. DescribeEach side, separately

    The retailer gives it the specification its order API already has, and one exported sample order. The 3PL does the same for its inbound-shipment API. Each becomes a description that stays at home.

  3. RedactAutomatic

    At each boundary every value and identifier is stripped. What leaves is structure: a string here, a number there, a category with three values.

  4. ProposeThe tool

    Working from the two shapes alone, the tool maps what the names and types justify and turns everything else into a short list of questions for a person.

    Retailer emitsStatus3PL expects
    order_refconfirmed by a personreference
    recipientconfirmed by a personrecipient_name
    ship_streetconfirmed by a personstreet
    ship_cityconfirmed by a personcity
    ship_postcodeconfirmed by a personpostcode
    parcel_gramsmapped + g → lbweight_lb
    serviceconfirmed by a personservice_code

  5. DecideOne person per side

    NEXT_DAY, STANDARD and ECONOMY have to become the 3PL's ND, STD and ECO. Which means which is a business meaning, so the tool asks instead of guessing. The two operations leads confirm the field pairs and the three service codes. Nobody opened an order to do it.

  6. CheckAutomatic

    Before it may run, the bridge is independently checked and every output is verified, the pound figures included. It passes, and it is signed. Before anything is saved, the output is also checked against the 3PL's own published schema.

  7. RunRunning

    Orders are translated. Each record passes through the sealed bridge and comes out in the 3PL's format. The bridge has no way to reach a network.

    Leaves the retailer

    order_ref"SO-48213"
    recipient"Dana Whitfield"
    ship_street"14 Harbour Rd"
    ship_city"Leeds"
    ship_postcode"LS1 4AP"
    parcel_grams2500
    service"NEXT_DAY"

    Arrives at the 3PL

    reference"SO-48213"
    recipient_name"Dana Whitfield"
    street"14 Harbour Rd"
    city"Leeds"
    postcode"LS1 4AP"
    weight_lb5.51155
    service_code"ND"

  8. HealMonths later

    The retailer's platform renames parcel_grams to mass_g. The mismatch is caught before an order goes out wrong. A new bridge is built, has to pass the same checks again, and replaces the old one. A change it cannot resolve with confidence is held for a person instead of going live. So is a rebuilt bridge that would write fewer of the fields the 3PL requires.

No shared test environment, and no sample files of real orders in anyone's inbox.

The 3PL's engineers never saw a customer.

The unit conversion is checked on every build, not trusted once.

Scenario

A regional hospital group starts using an outside laboratory for specialised tests. Orders have to move from the hospital's records system into the lab's. The hospital names its fields its own way, keeps the record number as a number, and codes sex as a single letter. The lab wants its own field names, a text identifier and spelled-out values.

Objective

Start sending orders without any outside engineer, the lab's or a contractor's, handling patient records during the build. Keep the list of organizations that touch patient data exactly as short as it is today.

How this goes today

  • An interface project between two vendors, usually measured in months
  • Every outside party that handles records while building it needs its own agreement and security review first
  • Test messages are made from real or lightly masked patients
  • A code that was mapped wrong shows up in production, on a real patient's order
In the real world

Under US health privacy law, any vendor that handles patient records on a provider's behalf has to sign a business associate agreement before it starts. Every extra party in an interface build is another agreement, another review, and another place a record can sit.

With AIP-MCP, start to finish (illustrative)

  1. Set upEach side, separately

    The hospital installs AIP-MCP inside its own network, next to the records system. The lab does the same on its side. No third party sits between them.

  2. DescribeEach side, separately

    The hospital describes one thing, the lab order it sends. The lab describes the order it accepts. Both come from interface specifications that already exist. Charts, results and billing are simply not in the description.

  3. RedactAutomatic

    Before anything leaves the hospital, every value is reduced to its shape. The mapper learns that a name field is a string. It never learns a name.

  4. ProposeThe tool

    No field here can be paired safely from its name and type alone, so the tool pairs none of them. It hands every pair back as a question it has no business answering.

    Hospital emitsStatusLab expects
    mrnconfirmed by a personpatient_id
    family_nameconfirmed by a personlast_name
    given_nameconfirmed by a personfirst_name
    test_codeconfirmed by a personpanel_code
    (nothing)confirmed by a personordering_site
    sexconfirmed by a personsex
    priorityconfirmed by a personurgency

  5. DecideOne person per side

    An interface analyst at the hospital and one at the lab confirm the field pairs and the site code, and agree that F, M and U become female, male and unknown, and that STAT means urgent. They exchanged code lists, not patients.

  6. CheckAutomatic

    Before it may run, the bridge is independently checked, without any real patient's record. The signed result shows which bridge was checked and the verdict, so an auditor can confirm it later. Before anything is saved, each order is also checked against the lab's own published schema.

  7. RunRunning

    Orders pass through the sealed bridge into the lab's format. The only parties that ever hold the record are the two that always had to.

    Leaves the hospital

    mrn4471902
    family_name"Whitfield"
    given_name"Dana"
    sex"F"
    test_code"CBC-D"
    priority"STAT"

    Arrives at the lab

    patient_id"4471902"
    last_name"Whitfield"
    first_name"Dana"
    sex"female"
    panel_code"CBC-D"
    urgency"urgent"
    ordering_site"NGH-01"

  8. HealMonths later

    The hospital's records vendor ships an upgrade that renames test_code to order_code. The break is caught at the boundary, not on a patient's order. The rename is confirmed by one person, the bridge is rebuilt and checked again before it goes live, and the lab has nothing to do.

No patient record left the hospital to get the interface built.

The people who mapped the fields worked from a shape, not a patient.

Every bridge that runs carries a signed record of the checks it passed.

Scenario

An appliance maker sells through forty independent distributors. To plan production it needs monthly sales per product from all of them. Every distributor runs a different ERP, counts in cases where the manufacturer counts in units, and uses its own region codes.

Objective

One clean monthly feed, in the manufacturer's format, from all forty, without asking any distributor to open its ERP, its customer list or its pricing to the company that also sells to its rivals.

How this goes today

  • Spreadsheets emailed at month end, every one in a different layout
  • An analyst re-keys and reconciles them by hand, every month
  • Distributors refuse a direct connection, because the same system holds their customers and margins
  • One distributor changes its export and the totals are quietly wrong until someone reconciles
In the real world

In October 2020 Public Health England failed to report nearly 16,000 positive COVID-19 cases on time. Results were being passed between systems as spreadsheet files, and an old file format silently dropped the rows that did not fit.

With AIP-MCP, start to finish (illustrative)

  1. Set upManufacturer, once

    The manufacturer installs AIP-MCP and describes the one thing it wants to receive: a monthly sales line. That description is written once and reused for every distributor.

  2. DescribeEach distributor

    Each distributor installs it on its own side and describes only its monthly sales export. Customer and price tables are not in the description, so they are not in the shape, so there is nothing about them to leak.

  3. RedactAutomatic

    Product codes, quantities and regions are reduced to their types before anything leaves the distributor. The manufacturer's side does the same.

  4. ProposeThe tool

    Forty different exports, one target. This is distributor 17.

    Distributor emitsStatusManufacturer expects
    skuconfirmed by a personproduct_code
    periodconfirmed by a personmonth
    (nothing)confirmed by a persondistributor_id
    cases_soldproposed, corrected by a personunits_sold
    regionconfirmed by a personterritory

  5. DecideThe distributor

    The tool pairs cases_sold with units_sold on its own, and that pairing is wrong: a case holds 12 units. This is why a person reviews every bridge. The distributor corrects it, confirms the other field pairs, and says that NE is the north-east territory. The bridge is updated.

  6. CheckAutomatic

    Each of the forty bridges is independently checked and signed before it may run. A bridge that fails never goes live, and the other thirty-nine are unaffected. Every output is also checked against the manufacturer's own published schema.

  7. RunRunning

    Sales lines from every distributor come out in one format. Nobody re-keys anything.

    Leaves distributor 17

    sku"HX-2200"
    cases_sold40
    period"2026-08"
    region"NE"

    Arrives at the manufacturer

    product_code"HX-2200"
    units_sold480
    month"2026-08"
    territory"north-east"
    distributor_id"D-017"

  8. HealMonths later

    Distributor 12 upgrades its ERP and cases_sold becomes qty_cases. That one bridge stops, is rebuilt and is checked again. If the new name cannot be matched with confidence, it is held for a person rather than guessed.

Forty feeds in one format, with no month-end re-keying.

No distributor opened its ERP, its customers or its prices to the manufacturer.

A changed export stops at the boundary instead of reaching the forecast.

Who it's for

Wherever trust is the constraint, not effort.

If both parties will hand their data to a shared integrator, conventional tools win. This is built for the cases where they won't.

Software vendors

Onboard a customer's system

Connect the system your customer already runs without your platform ever holding their records, and without a services engagement per account.

Partner networks

Many partners, one schema

Normalize data from distributors, suppliers or franchisees while each keeps its internals private.

Regulated & cross-border

Connect what legally can't mix

Link entities separated by residency or privacy rules, where records cannot leave a region even inside one company.

Competitors

Exchange without exposure

Share operational data with rivals through a bridge that never holds either side's records.

What you get

The benefit, plainly.

0

Records exposed

Neither counterparty, nor anyone building the bridge, ever sees a real value.

1

Description per system

Describe what you have once. Every new counterparty reuses it, with no new disclosure.

1

Person, only when needed

When a partner changes format, the break is caught before bad data moves. The bridge is rebuilt and checked again, or held for a person if the change is ambiguous.

Pilot

Try it on one integration you are stuck on.

AIP-MCP is a command-line tool that runs on your own machine, offline. A pilot uses records you export from your own systems. We never receive them, and it needs no production access, no credentials and no network changes.

What you bring: the API specs (OpenAPI 3, as JSON) for the two systems you want to connect, one sample record exported from each, and a few hours from one engineer.

What you get: a working, verified bridge for that integration, the short list of decisions it handed to your team, and the signed record of the checks it passed, which you can show your security reviewers.

Request a pilot

What it will never do

  • Reach the network from a bridge
  • Guess what a category means
  • Go live after an ambiguous change

Built in four months by one founder, Achuthan Ram. 1,020 automated tests, including deliberately hostile inputs the tool is required to reject. US provisional patent filed May 2026. A working prototype, not a hosted service.