Schema And Admin Clauses

Consumer View

These clauses are how you shape the runtime around your graph instead of only querying the graph itself.

They cover:

• performance structures such as indexes
• integrity rules such as constraints
• graph typing and graph-shape introspection
• temporal-property declarations plus the usual index, constraint, and graph-type controls
• abstraction declarations for graph-native feature and intervention modeling
• lens abstractions for durable user intent and viewpoints
• knowledge assertions for graph-native source-grounded relationships between abstraction endpoints
• abstraction catalog definition clauses for features, interventions, scenarios, snapshots, datasets, models, policies, analysis runs, and reports

Conceptual Explanation

Schema/admin clauses matter because Nexyron is not only a pattern-matching engine. It also has explicit surfaces for:

• telling the planner what to accelerate
• declaring which properties or combinations must stay valid
• describing graph type expectations
• registering time-oriented schemas and temporal-property definitions used by time-aware workloads
• registering first-class abstractions that later procedures can attach features, interventions, and scenarios to
• registering lens abstractions that represent durable user intent as a queryable abstraction viewpoint
• registering knowledge assertions so source-grounded knowledge relationships can participate in normal graph traversal without hiding as metadata arrays
• registering the rest of the abstraction ML and decisioning catalog directly from Cypher instead of only through procedures

Pages

• CREATE INDEX
• CREATE SEMANTIC INDEX
• DROP INDEX
• SHOW INDEXES
• CREATE CONSTRAINT
• DROP CONSTRAINT
• SHOW CONSTRAINTS
• ALTER CURRENT GRAPH TYPE
• SHOW CURRENT GRAPH TYPE
• CREATE TEMPORAL PROPERTY
• SHOW TEMPORAL PROPERTIES
• CREATE ABSTRACTION
• SHOW ABSTRACTIONS
• CREATE Abstraction Definitions
• SHOW Abstraction Definitions
• USING LENS And APPLY ANALYSIS RUN

Practical Guidance

• Use indexes for repeated lookup and filter patterns, not as decoration.
• Use constraints when incorrect data should fail loudly rather than being discovered later.
• Use graph-type clauses when you need explicit shape control and introspection.
• Use temporal-property clauses when time-varying state belongs on node properties.
• Use abstraction clauses when you want abstraction graph nouns such as actors, environments, or lenses to become discoverable catalog objects rather than only labels in application code.
• Use knowledge assertions when a source-grounded knowledge relationship between real abstractions belongs in the graph surface. Reports, analysis runs, wiki pages, models, and rulesets stay in artifact metadata/provenance instead of becoming knowledge endpoints.
• Use abstraction definition clauses when a feature, snapshot, dataset, model, analysis run, report, or policy is truly part of the database contract and should be reviewable as schema rather than only as a procedure payload.