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:

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:

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

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:

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:

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.