Scalability
Adding an eighth party.
Joining is a checklist, not a project. Nothing changes for the parties already connected.
Sign the agreement
Which contracts, which fields, for what purpose, for how long. It becomes policy in the exchange the same day.
Federate identity
The party registers its own identity provider. No new accounts are created for its staff; no shared passwords exist.
Deploy the adapter
From the region's template, into the party's own account. Map vendor fields to the contract; apply the classification.
Pass conformance
The sandbox checks every published record against the contract version and the field rules. Fail, and nothing is accepted.
Each step touches only the new party and the exchange. The seven already connected do not redeploy, re-key or re-sign. That is what makes adding a party constant work rather than work that grows with the size of the region.
Small parties take a lighter path. A scooter operator publishing an open GBFS feed may need no adapter beyond a URL and an identity. A small agency with a vendor export needs the adapter and nothing else: no lakehouse, no platform. The design does not force a large agency's complexity on anyone.
Leaving is the same list in reverse. Revoking a contract stops the flow; the audit trail records what was shared while it was in force.
- Touched on join
- The new party, the exchange's registry and policy
- Untouched
- Every other party, every regional product
- Blocking gate
- Conformance tests on the contract version
- Minimum party
- One identity provider, one feed URL