Platform · Jubi Atlas

Your business, made legible to the AI.

Most enterprise AI guesses because it has nothing to ground against. Atlas is what it reads from instead — canonical metrics, glossary terms, entity relationships, and the permission rules Guardian protects. Written down once, owned by the people who actually know.

Metrics Glossary Tables one canonical gross_margin

Defined once · Owned by your team · Read on every request

One platform — three parts JubiStudio workspace + JubiGuardian protects + JubiAtlas grounds shared identity · shared audit · shared brand
01 · The three layers

Three things every business already knows. Written down once.

Every business already has these definitions somewhere. They sit in spreadsheets, in people's heads, in a wiki page nobody has opened in a year. Atlas is where they finally live in one place, kept by the people who own them, where the AI can read them.

01 · Canonical metrics

One definition of revenue. Not eleven.

Verified formulas live in Atlas, and the AI uses them rather than guessing from column names. When finance changes the formula, the answer to "what's our gross margin?" changes everywhere at once.

Defined once: finance.gross_margin_quarterly. Owned by finance, versioned, with the date it was last verified.
  • Named formulas
  • Versioned definitions
  • Single owner per metric
  • Verified-on date
  • Cited in answers
  • Reused everywhere
02 · Glossary & entities

What the words mean, and how the data joins

The AI knows what churn means in your business, and whether customer, account, and buyer name the same thing or three different ones. Entity relationships are written down, so the join is something Atlas already knows rather than something the model invents.

Defined once: "churn" = no order in 60 days, and customer ↔ account (1:N) with the join spelled out.
  • Glossary terms
  • Aliases & "not this"
  • Entity edges
  • Explicit join paths
  • Scoped per workspace
  • Owned by a team
03 · Permission semantics

Who can see which field, and how

Atlas defines field-level visibility: who can read which columns, under what conditions, with what masking. Guardian protects it on every request. The AI cannot hand back what the user isn't cleared to see, and a summary or an inferred figure doesn't slip past it either.

Defined once: customer.email is PII. Visible to the account owner, masked for everyone else, with no summary path around it.
  • Field-level classes
  • Visible-to rules
  • Masking policies
  • No inference path
  • Read by Guardian
  • Logged per decision
In the product

Analysts edit the semantic layer directly in Context Studio: glossary terms, metric definitions, and playbook content, alongside browsing and scoping the model. The definitions live in one place, and every answer reads from them.

02 · Defines vs protects

Atlas defines. Guardian protects.

Two responsibilities, two components. Atlas writes down what your business means and who can see what. Guardian checks each call against those definitions as it happens, then logs the decision.

Atlas definesslow · curated

Metric formulas, glossary terms, entity edges, and permission semantics. Analysts and data governance edit them on purpose, then version and own them. Defining something is a deliberate act, done once and reused, not redone for every call.

  • Canonical metric formulas
  • Field-level permission rules
  • Owned, versioned, dated
Guardian protectsfast · per-request

For each call, Guardian reads who is asking, looks up what Atlas says they're allowed to see, and checks the model's answer against the canonical definitions. It runs constantly, and it runs the same way every time.

  • Identity bound to the request
  • Answer checked against Atlas
  • Decision logged for replay
Why the splitthe point

Mixing definition and protection is what produces shadow AI: rules that live nowhere and get applied differently each time. Keep them apart and the same question starts giving the same answer.

  • Rules live in one place
  • Protection is consistent
  • Answers are reproducible
The resultgrounded

The user gets an answer or a refusal, with a citation, replayable end to end. Atlas decides what is true and who may see it. Guardian makes sure that is what actually happens.

  • Answer or refusal, cited
  • Replayable end to end
  • Same question, same answer
03 · Coverage

What lives in Atlas. What doesn't.

Atlas is a layer of meaning over your data, not a copy of it. The boundary is deliberate. Definitions live here; the data itself stays exactly where it already is.

In Atlas The layer of meaning
  • Canonical metric definitions and named formulas
  • Glossary terms, aliases, and what a term is not
  • Entity relationships and the join paths between them
  • Field-level permission semantics and masking rules
  • Ownership, versions, and the verified-on date for each entry
Curated by analysts, scoped per workspace. The AI reads these instead of guessing from column names.
Not in Atlas What stays elsewhere
  • The raw rows. Your warehouse and Jubi Data remain the system of record
  • Query execution, which runs against the source under the user's own access rights
  • Protection at request time. That is Guardian's job, reading these definitions
  • Identity and group membership, which come from your identity provider
Atlas never becomes a second copy of your data, and it never holds credentials. It describes the records; it does not store them.
04 · How it fits

Studio reaches. Guardian protects. Atlas grounds.

Atlas sits at the end of the path. The user sees one thread. Underneath, the platform sees a question, a policy decision, and an answer grounded in Atlas rather than guessed at.

Studio
user asks
Guardian
identity · policy · audit
Atlas
metrics · glossary · permissions

Studio is the surface where the user sits. Guardian is the gate the call passes through, with the answer and the decision both kept on the record. Atlas is the layer underneath, the meaning the AI reads instead of guessing. No one of the three does much on its own. See the platform architecture → for the full diagram.