---
title: CREATE ABSTRACTION
url: https://nexyron.tech/docs/cypher/clauses/schema-and-admin/create-abstraction
description: CREATE ABSTRACTION registers a first class abstraction in the Nexyron catalog. It is the schema level way to say that a concept such as an actor, event, stage, society, environmen
---

# CREATE ABSTRACTION

## Generic Description

`CREATE ABSTRACTION` registers a first-class abstraction in the Nexyron catalog. It is the schema-level way to say that a concept such as an actor, event, stage, society, environment, or lens is not just an application convention but a named object the runtime can discover later.

Example:

```cypher
CREATE ABSTRACTION ACTOR Member FOR LABEL User TAGS (fitness, retention)
```

## Consumer-Level Explanation

Use this when you want to model abstraction graph nouns explicitly.

Without it, you can still have `:User` nodes and `:Facility` nodes, but the database does not know that one label is meant to be an actor abstraction and another is meant to be an environment abstraction. `CREATE ABSTRACTION` makes that intent explicit so later procedures, knowledge assertions, features, interventions, scenarios, lenses, and analytics can refer back to stable abstraction names.

Lens abstractions use the same catalog object. A durable user intent is not a separate public node shape; it is a `LENS` abstraction with a description and optional queries:

```cypher
CREATE ABSTRACTION LENS ChurnInvestigation
DESCRIPTION 'Understand why customers churn and identify useful separation rules.'
TAGS (assistant_generated, intent)
```

For Lens records, `description` remains the plain-language purpose. Runtime planning state, such as the selected target, analysis rules, and build plan, is stored as structured abstraction options by the Lens registration procedure rather than embedded as JSON text in the description.

## Conceptual Explanation

This clause sits between normal graph typing and higher-level ML/simulation tooling.

-   graph labels still carry the actual node data
-   temporal properties still carry changing state
-   abstraction declarations carry the abstraction role of a concept in the platform
-   event declarations carry reusable time-grounded occurrence sets that can be linked to actors, stages, environments, outcomes, interventions, and reports
-   lens declarations carry a durable viewpoint or intent through which other abstractions may be selected, represented, or reported

That matters because later platform layers often need to ask questions such as:

-   which abstraction does this feature belong to?
-   which interventions target actors?
-   which scenarios operate on environments?

`CREATE ABSTRACTION` gives those later layers a stable catalog anchor.

An abstraction may be concept-only or source-backed. A concept-only abstraction has a name and description but no subject selection query yet. A source-backed abstraction adds `FOR LABEL` or `SOURCE QUERY` so the runtime can expand the concept into concrete graph subjects. `REVERSE QUERY` and `REPRESENTATION QUERY` are optional helpers for reconstructing or displaying the graph behind an abstraction result.

## Advanced Example

```cypher
CREATE ABSTRACTION ENVIRONMENT FacilityContext FOR LABEL Facility TAGS (ops, capacity)
```

This does not materialize any new graph projection and it does not rewrite the `:Facility` data itself. It only declares that `Facility` is a environment abstraction.

More complete source-backed example:

```cypher
CREATE ABSTRACTION IF NOT EXISTS ACTOR Member
FOR LABEL User
DESCRIPTION 'A person who can visit, subscribe, churn, or receive retention actions.'
SOURCE QUERY 'MATCH (u:User) RETURN u.user_id AS subject_id, u AS subject'
REVERSE QUERY 'MATCH (u:User {user_id: $subject_id})-[r]-(n) RETURN u, r, n'
REPRESENTATION QUERY 'MATCH (u:User {user_id: $subject_id}) RETURN u'
TAGS (fitness, retention)
```

Event abstractions are source-query-backed temporal occurrence contracts. The event identity is still returned as `subject_id`, and the event time must be returned as `occurred_at` so Lens/report, feature, and temporal workflows can treat the rows as ordered behavior:

```cypher
CREATE ABSTRACTION IF NOT EXISTS EVENT VisitEvent
DESCRIPTION 'One member visit occurrence.'
SOURCE QUERY 'MATCH (v:Visit) RETURN v.visit_id AS subject_id, v.started_at AS occurred_at, v.member_id AS actor_id, v.facility_id AS stage_id'
REPRESENTATION QUERY 'MATCH (v:Visit {visit_id: $subject_id}) RETURN v'
TAGS (behavior, occurrence)
```

## Real Use Cases

-   Declaring `ACTOR Member` so retention features can attach to one stable abstraction name instead of repeating label-specific conventions in every procedure call.
-   Declaring `EVENT VisitEvent` so behavioral sequences, journey reports, intervention responses, and event-derived features have one stable occurrence surface.
-   Declaring `LENS ChurnInvestigation` so an assistant, report, and analytic can share the same durable intent without creating a parallel intent object.
-   Declaring `SOCIETY ClassCohort` so social or cohort-derived features have a clear abstraction home.
-   Declaring `ENVIRONMENT FacilityContext` so occupancy, schedule, and equipment context can be modeled as an explicit non-actor surface.

## Real Limitations And Tradeoffs

-   This clause only registers metadata. It does not build snapshots, feature materializations, intervention events, or scenario overlays by itself.
-   The current implementation supports `ACTOR`, `EVENT`, `STAGE`, `SOCIETY`, `ENVIRONMENT`, and `LENS`.
-   Source-query-backed `EVENT` abstractions must return `occurred_at` explicitly. Use actor, stage, target, environment, or payload columns as additional source fields when the schema exposes them.
-   Concept-only abstractions are useful for knowledge and intent capture, but they do not resolve to concrete business subjects until they receive a label, source query, or another resolver path.
-   The declaration is intentionally lightweight. If you need executable feature, analytic, report, model, or policy configuration, use the abstraction definition DDL on top of it.