classifications

The atom-type registry — 37 canonical entity types, each recommending a small validated field set by pointing at schema.org.

@0xintuition/classifications answers the second question in the data model — what atom data do we recommend? It is the atom-type registry: 37 entity types in 7 categories — book, music-recording, person, software-application, ethereum-account, and the rest — each mapping to a schema.org type and recommending a small, validated set of fields to capture at creation. The full registry is browsable at /classifications.html, one page per type — e.g. company.

Where @0xintuition/schema-org is the superset of everything that could describe an entity, classifications are the curated surface: the fields Intuition recommends, so every app captures the same shape and the data lines up later.

Three tiers, nested#

For any classification, the field sets nest: required ⊂ recommended ⊂ available.

The available superset is never copied into classifications — it is derived on demand from @0xintuition/schema-org.

The pointer model#

A classification points at schema.org by name; it never copies schema.org's property model:

// A classification points at schema.org by name —
// it never copies schema.org's property model.
schemaOrg: { context: "https://schema.org/", type: "Book" },
fields: [
  { key: "name",   schemaOrgProperty: "name",   required: true  },
  { key: "author", schemaOrgProperty: "author", required: false },
  { key: "isbn",   schemaOrgProperty: "isbn",   required: false },
  { key: "sameAs", schemaOrgProperty: "sameAs", required: false },
]

// schemaOrgProperty: "name" does NOT claim name belongs to Book.
// It means: for Intuition's book atom, recommend the schema.org
// property named "name". Provenance still comes from schema-org.

Define once, point to it. Nothing is duplicated, so nothing can drift — and a build-time validator confirms every referenced type and property actually resolves against the pinned vocabulary. Anti-drift by construction.

In practice, use the builders#

Classifications describe shapes; @0xintuition/primitives wraps them with one typed builder per entity — the most ergonomic way to produce these shapes:

import { buildSoftwareApplication } from "@0xintuition/primitives";

const atomData = buildSoftwareApplication({
  name: "Next.js",
  url:  "https://github.com/vercel/next.js",
  applicationCategory: "WebFramework",
  programmingLanguage: "TypeScript",
});
// → validated, canonical JSON-LD with "@type": "SoftwareApplication"
//   and "@context": "https://schema.org/"

The output is identity-stable JSON-LD — the exact bytes that get hashed by calculateAtomId and, when published, written to the MultiVault. Schemas are hosted on schema.intuition.systems and versioned via the JSON-LD @context field.

Validator, not executor. The classifications package validates and shapes the JSON; it doesn't move bytes onchain or write to a database for you. That's your app's job. The point is everyone uses the same shape so the data lines up later.

The metadata-predicate matrix#

Classification fields decide what's embedded in the atom at creation. Which verbs are recommended for claims about the atom later is a separate decision, made in the predicates package — and every classification formally references it. Each classification spec ships metadataPredicates, its recommended verbs, plus a typed matrix: for each (classification, predicate) pair, the kind of object the edge expects.

import {
  getMetadataPredicatesFor,
  getMetadataPredicateMatrixFor,
} from "@0xintuition/classifications";

// The verbs recommended for enriching a company atom
const verbs  = getMetadataPredicatesFor("company");

// And what each verb expects on the other end
const matrix = getMetadataPredicateMatrixFor("company");
// company —founder→         expects a `person` classification
// company —hasDescription→  expects a string literal

The matrix is what makes enrichment typed end to end: an app enriching a company atom knows that a founder edge should point at a person atom, not a string — and that hasDescription takes a literal, not an atom. Tooling can validate claims before they're written, and generic UIs can offer the right input for each verb. Browse it per type on the reference pages, e.g. company.

The two columns — atom data and triple metadata — are related, but the decisions are independent. See Triples & Predicates.