Shape Commons
to the way you work.
A capability is a small, signed package that gives a dataset its behavior: how data gets in, which records it accepts, and how people and tools read it. Commons stores and synchronizes the bytes; capabilities and applications give them meaning.
Any kind of data. One way to hold it.
Commons holds one thing: bytes. Any format is converted to bytes on the way in and back to its own shape on the way out, so structured and unstructured data share the same storage and sync.
Format-aware work sits above that layer: ingestors parse inputs, schemas enforce record rules, materializers and applications interpret the data for views, search, queries, and assistant tools.
Reading or validating a particular format still needs the right capability or application, within resource limits.
Bring data in. Set the rules.
Put it to work.
Each part of a capability fits one of three slots. The slot decides where it runs, so a package can bundle all three without blurring the boundaries.
One ingestion per dataset. Schema on every write. As many materializers as readers need.
Agree the model. Keep the systems.
A network can use one shared capability to apply its collection and validation model, without everyone ingesting or presenting data the same way.
The ecosystem specifies what participating datasets collect. Ingestion maps permitted inputs into that model, whether the source is a file, an API, or a stream.
Schema behavior checks the agreed records and keys at write time. Consistency comes from adopting the shared capability, not from bytes acquiring meaning on their own.
Participants choose their own materializers and applications. Shared validation doesn’t require identical screens or outputs.
Bring the source you already have.
Ingestion is the first slot: it brings data into a dataset in whatever form the source provides and hands each record to the schema for checking.
Five sources ship with Commons. File imports run once; APIs and streams keep going. If your source is different, write your own ingestion capability and attach it the same way.
Parse a new format or reshape records on the way in.
Deliveries accepted on the node sidecar.
One record per row, keyed on a column.
JSON or NDJSON, one record per object.
Fetch an endpoint on a schedule.
Follow a server-sent event stream.
Add records by hand or through the node sidecar.
Read the same data in different ways.
Shipped materializers run in the App, not in the node’s API sidecar.
Records as a table, one column per field.
Search the words in your records with an on-device index.
Filter and sort tabular records by column values.
Let an AI assistant list, read, and search a dataset through commons mcp.
Give your dataset tools an AI assistant can use.
MCP is part of the capability model. Attach a signed release and a compatible assistant can list, read, and search the dataset through commons mcp.
Custom mcp capabilities add task-specific tools, and a package can combine them with ingestion, schema, views, search, and query behavior. MCP materializers run in reading Apps, never in the node’s API sidecar.
Where a workflow needs historical lookup or version comparison, an application or custom tool exposes the relevant versions; check what the release you attach actually provides.
"supplier 2041"1 matchrecord/2041v118Signed once.
Reused anywhere.
Each release holds a manifest, an icon, and either WebAssembly code or a declarative description. Releases are published like data and signed by their publisher; a dataset attaches the releases it needs.
One release can bundle several kinds of behavior. Its parts still run in their own platform-enforced slots: bundling never moves an App materializer into a server runtime.
Useful behavior, bounded access.
A signed release identifies its publisher. It is not a guarantee that the logic is correct.
Memory and CPU limits apply to all capability code. Test on representative data before attaching to an important dataset.
No network access unless specific hosts are granted. Private network addresses are always refused.
Message acceptance depends on available memory and disk. Large-message support isn’t unlimited processing or storage.
Build it. Check it.
Ship it signed.
Start from a starter for the kind you need, build reproducibly, and check every part in the real sandbox, the same one the App uses. Then publish a signed release and attach it to a dataset.
In App developer mode you can try a release on scratch datasets before anyone depends on it. Developer checks and App previews run the same view, search, and query engines, with byte-for-byte golden tests.
Capabilities extend
what Commons can do.
Commons stores, versions, and syncs data. Everything specific to a domain or a network is added as a capability: how data is collected, which records are valid, how it is read, and how other systems interact with it.
Coming soon, two capabilities bring open-network protocols into that model. Each packages the network’s collection rules, validation, and views together with its protocol interface, so joining a network doesn’t mean changing your systems.
Beckn
Discovery and transaction interfaces for open commerce networks, alongside the ecosystem’s collection model, write-time validation, and App-side views. Participants keep their own input and output formats.
About Beckn ↗DeDi
Verifiable public-registry interfaces, alongside registry collection, validation, and materialization. Shared dataset rules connect registry interactions to the information participants maintain and use.
About DeDi ↗Two doors to the data.
Each in its place.
Outside programs and network protocols reach a dataset through the node’s API interface. People and assistants read it through materializers in the App that holds the local copy.
Open-network capabilities add their protocol behavior at the API interface while keeping their ingestion, schema, and materialization parts. Nothing moves a materializer onto the node.
Share the preparation,
not just the data.
Clean, combine, or enrich permitted data with your own tools or custom ingestion, then publish the result as its own Store. Others subscribe to that instead of repeating the work.
You remain the publisher of what you prepared, responsible for its meaning and quality. When a source changes, you decide whether to re-run the preparation and publish a new version; nothing downstream is rebuilt silently.
Explore the next layer.
Build your own capability, see how Commons keeps it safe, or join the waitlist for early access.