Most systems know far more than they are able to express.

We validate data shapes with types or schemas, but the meaning of the system — domains, responsibilities, constraints, expectations — lives in conventions, naming habits, and people’s heads.

That’s a knowledge problem.

Atlas explores a simple idea: what if system information itself was a knowledge graph?

A system is already composed of entities and relations. Treating it explicitly as a graph makes architectural meaning queryable, verifiable, and evolvable.

Atlas builds on a simple premise: identity should be defined by what something means, not where it lives.

Instead of encoding meaning into long, brittle identifiers like:

:com.app.endpoint.request.post.payload.user.profile

Atlas uses compound semantic identities: sets of orthogonal aspects, such as:

• :endpoint/post
• :request/payload
• :user/profile

This shift matters because:

• identity becomes composable
• naming stops being a guessing game
• meaning becomes queryable across dimensions

You stop asking “where is this defined?” You start asking “what kind of thing is this?”

This approach follows familiar ideas from clojure.spec, RDF, and contract systems:

• namespaced keywords
• open registries
• global discoverability

But instead of forcing meaning into a single linear name, compound identities allow systems to communicate more than types alone ever could.

You can now ask:

• show me all endpoints
• endpoints related to user profiles
• endpoints that do not touch user profiles
• write operations that require authentication

Architecture becomes explorable rather than inferred.

Once meaning is explicit, verification becomes a graph query.

Examples of semantic invariants:

• any endpoint handling user email must require JWT authentication
• no component may skip a tier boundary
• every dependency must exist and be reachable

These checks validate semantic consistency, not runtime behavior:

• dependency legality
• tier boundaries
• data-flow satisfiability
• protocol usage
• cross-cutting requirements

They run after code is loaded but before the system starts, preventing a semantically invalid system from executing.

Semantic entities are not just documentation. They can be used at runtime.

If you can identify an entity by its semantic identity, you can:

• resolve it from the registry
• inspect its properties
• adapt execution based on its meaning

For example:

• a router receives a request
• it resolves an endpoint entity by semantic identity
• it retrieves the associated handler
• execution is shaped by the entity’s aspects and metadata

At runtime, this enables:

• routing driven by semantic identity rather than hardcoded tables
• middleware selection based on entity aspects
• adaptive behavior (auth, rate limiting, tracing) inferred from semantics
• uniform execution paths across differently shaped endpoints

Execution becomes data-driven by meaning, not just by control flow.

This is not dynamic magic — it’s the same idea as loading specs, multimethods, or Integrant components before execution. Atlas simply extends that pattern to architectural semantics.

The hard part is not building the graph — it’s authoring and maintaining it.

Semantic authoring is difficult if all you see is raw data spread across a codebase. That’s why Atlas includes tooling to surface meaning where developers work:

• semantic aspect discovery and autocomplete
• navigation across relationships
• real-time invariant feedback
• visual exploration of architecture

Correctness becomes ergonomic instead of burdensome.

Atlas is not about frameworks or enforcement, it’s about expressivity.

Types prove facts. Semantic graphs communicate understanding.

As systems scale, behavior usually still works — but understanding fails first.

Atlas is an experiment in making that understanding explicit, queryable, and executable.

Architecture as data. Semantics as infrastructure.

There are more things and details to discover on atlas, if you are interested you can take a look here