Database

Atlas uses a constant outer format called an Envelope. That gives the network one reliable shape for verifiability and transport, no matter what the content actually means.

A registry or app can first validate the envelope itself, then move on to interpreting the content inside it. Verification stays predictable even when the meaning differs between a profile, a credential, a catalog, an attachment, or some domain-specific record.

The result is simpler tooling. You do not reinvent transport logic every time you define a new kind of data.

Atlas uses schema.org types for the broad semantic skeleton. That gives the network a shared starting point for what a document is supposed to represent.

Then Atlas narrows that meaning with JSON schema validators and additionalType identifiers. Those stricter rules tell a registry or process exactly what fields it expects and whether an envelope is eligible to be accepted.

The same layer can also describe how the record should behave over time, for example latestOnly, latestWithHistory, appendOnly, workflow, or attachment. That means a registry does not have to guess whether it should replace, accumulate, sequence, or simply store the envelope.

Atlas does not require every registry to become equally good at every possible kind of data. A registry can specialize around the types it wants to store, query, and serve efficiently.

That lets operators build targeted indexes and targeted product features. One registry may focus on identity-related data, another on domain credentials, another on some workflow-heavy niche. This is one reason Atlas can feel more like a practical database network than a universal blob store.

It is similar to how large engineering teams use microservices: shared contracts at the edges, specialized behavior inside each service.

Some envelopes are not just records. They are steps inside a process. Atlas handles that by documenting workflows: what envelopes need to exist, what conditions must be met, and what can move a process into its next state.

That makes the behavior inspectable. Instead of hiding all the logic in a private backend, Atlas can describe the expected transitions in a way operators and builders can follow.

Once the workflow is documented, registries know what they are allowed to process, and app builders know what they should expect to happen next.

Atlas does not hard-code one database engine into the protocol. A registry can use any implementation it wants as long as the API layer stays compatible with the required envelope structure and filters.

In Atlas's main app implementation, each node runs PostgreSQL. That is a practical implementation choice, not a rule the whole network is forced to copy.

PostgreSQL works especially well here because Atlas can combine fast GIN indexes on JSON structures with classic relational features. That helps registries link related envelopes, build materialized views, and answer useful questions quickly.

In practice, those materialized views can represent how a registry currently sees an identity: whether it appears to be a verified human, what competences it recognizes, what balance it sees, and for registries, how much data fidelity they currently appear to have based on what they have synced from the network.

Guides are specialized registries used for network routing. They store DataCatalog envelopes and verify a registry's totalBurn across freshness windows together with its declared supported data types.

Shelters are different. They are primarily the user's own local disk space, supporting all data types and acting as a personal inbox and outbox. Remote shelters can provide redundancy for availability when the user is offline. Guides do not index shelters.

Between those roles sit the ordinary registries that specialize in storing and serving chosen kinds of data. These are typically run by app builders who need specific data types for their application features — they prefer operating within shared infrastructure rather than proprietary silos, gaining access to the network's data in exchange for neutral sharing.

None of these infrastructure roles are verified humans, so they do not receive FairShares income and do not act in the human trust allocation role. Still, like any identity, they can be targets of trust signals, and a registry's reputation can also be inferred from its public operators declared (and proven) in its DataCatalog.