Keep your systems.
Change how you share.
Publish selected data through a local Commons Store. Others subscribe, work from their own copies, and receive your later changes. Your systems stay as they are.
A Store is the shared data, not a replacement for your system.
A Store is a local, versioned collection of the records and files you choose to share.
Your system stays the source of record. You choose what to publish and who may use it.
Published changes sync between Stores. Earlier versions are kept for as long as you agree.
Applications read the received copy in your own environment. Several can share it.
Different environments.
Equal ability to participate.
A Commons instance can run in a data center or on a laptop, with mobile support planned. It can publish datasets, subscribe to others, and serve data it is authorized to share. Publishing and subscribing are roles an instance takes, not separate classes of infrastructure.
Your organization decides how those instances are deployed. A field team can collect data on laptops, with mobile support planned. Colleagues can work with local datasets on laptops. Dedicated or shared nodes can support distribution, with replicas placed where the workflow needs them.
These arrangements can coexist. You do not have to move everyone onto the same infrastructure to keep their shared data connected.
Each instance holds its own Store. Roles follow permissions, not device type.
Use laptops (and mobile devices, once supported) for collection and contributions, subject to the dataset’s permissions and validation rules.
Subscribe to datasets in the environments where people and applications use them. An instance can also publish the results of its own work.
Use dedicated nodes, shared nodes, and replicas according to the workflow’s distribution and availability requirements.
Examples of how instances can be used, not restrictions on what each device type can do.
Any kind of data.
One way to share it.
A Store holds one thing: bytes. Records, documents, images, and streams are converted to bytes on the way in and back to their own format on the way out, so any kind of data can share the same storage and sync.
Ingestors interpret source formats. Schema capabilities check records and keys on every write. Materializers and applications turn stored data into the views, search results, and outputs people need.
Being able to store a format isn’t the same as having a reader for it. Supported formats depend on the attached capabilities, within resource limits.
Sharing continues after the first delivery.
Choose the records another team needs, the ingestion capability, and the schema rules, then set access. Subscribers receive a local copy.
When you publish a change, subscribers receive the update instead of each working out what changed.
Your source integration and the consuming application still do their own parts.
Read your own copy.
Even offline.
Applications read the copy they already hold, without asking the publisher on every read. It keeps working when the source or connection is down.
Offline does not mean up to date.
The copy holds its last received version and syncs again when the connection returns. The application decides whether that version is fresh enough.
One source. Many uses.
Today, every consumer builds its own link to the register, and the intermediary’s cleanup work helps nobody else. With Commons, one publication serves everyone, and the work one organization adds becomes something others can subscribe to.
Take the role your workflow needs.
One organization can hold several at once.
Bring entries from field teams, partners, or devices into an agreed Store, within its permissions and checks.
Programs, field teams, networksChoose what to share and who may read, write, or host it. Keep publishing changes from the system you already run.
Registers, agencies, certifiersHold a local copy, use it across your applications, and receive each new version as it is published.
Banks, insurers, applicationsAdd sources, views, queries, or application interfaces, or publish a prepared result for others to subscribe to.
Intermediaries, developersWorks alongside the systems you already use.
Sources feed a Store. Capabilities shape it. Your applications, analytics, and AI read it locally. Nothing has to be replaced.
Give each dataset the behavior it needs.
A capability is a small, signed package with up to three parts. The slot decides where each part runs, whether the release is built in or made by your team.
Attach one to a dataset and it takes effect everywhere that dataset is written or read. Swap it for another release and the data stays where it is.
Shipped capabilities cover CSV, JSON, polled APIs, and live streams on the way in, and tables, full-text search, queries, and assistant tools on the way out.
Keep the systems. Share the rules.
An ecosystem can put its collection and validation model into one capability. Participating datasets attach it, so different source formats and local views follow the same rules, without anyone changing systems.
Coming soon: Beckn and DeDi capabilities add protocol interfaces at the node’s API layer. They keep their ingestion, schema, and materialization behavior; protocol support isn’t just another importer.
Current records and their history, available to AI.
A local dataset can support reporting, operational applications, and AI workflows alike. Published updates give AI a path to refresh its inputs; retained record versions give it context for comparisons and earlier decisions.
MCP capabilities give assistants tools to list, read, and search the dataset. Applications or custom capabilities expose any further historical operations and choose the records and versions relevant to the task.
Start with a relationship, not a migration.
Choose one source, the people who maintain it, and a team that depends on it. A focused evaluation shows what becomes reusable.