`nexyron.abstraction_register`

Generic Description

nexyron.abstraction_register register or replace one abstraction definition

CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.abstraction_register'
RETURN name, description, parameters, output_columns

Abstraction-platform registry procedures create, list, read, and inspect named contracts such as abstractions, features, datasets, snapshots, models, policies, interventions, scenarios, and split policies.

Consumer-Level Explanation

This procedure is part of the abstraction catalog contract layer. Use it when you want to define or inspect named abstraction assets that other runtime procedures will consume later.

Parameters

Output Columns

Example Contract Prerequisite

The executable Cypher blocks on this page query nexyron.procedures() so they work in an empty database and stay synchronized with the live procedure registry. A direct CALL nexyron.abstraction_register(...) requires the named abstraction contracts, artifacts, features, snapshots, datasets, models, or policies referenced by that call to exist first; otherwise the runtime correctly fails with an unknown-contract error rather than inventing state.

Conceptual Explanation

The important thing about nexyron.abstraction_register is that it registers executable semantic sets and executable semantic relations, not just label aliases. When source_query is present, CALL nexyron.abstraction_match({name: ...}) runs that query to produce the virtual subject set for features and snapshots. The same contract can also be used directly inside Cypher as a row-backed virtual pattern:

description is human-facing text. Runtime-owned machine state belongs in options, and is returned as options_json. Lens definitions use this split so the Lens remains one durable abstraction while its lens_plan stays structured and the visible description stays readable.

CALL nexyron.procedures()
YIELD name, parameters, output_columns
WHERE name = 'nexyron.abstraction_register'
RETURN name,
       [p IN parameters | p.name] AS parameter_names,
       output_columns
ORDER BY name

In that pattern, m is not a stored graph node and s is not a stored graph node. Each is a map built from the row returned by its abstraction source_query. The relationship is not a stored graph edge either. It is a map built from the row returned by the registered relation's relation_query.

The actor, stage, and society abstractions form a containment hierarchy. Actors belong to stages, and stages belong to societies. A stage abstraction should therefore include a relation contract to the actor abstraction it contains, with source_id equal to the stage subject and target_id equal to the actor subject. A society abstraction should include a relation contract to the stage abstraction it contains, with source_id equal to the society subject and target_id equal to the stage subject.

EVENT abstractions model temporal occurrences such as visits, clicks, purchases, messages, workflow steps, interventions, responses, support tickets, or state transitions. A source-query-backed event abstraction must return the event identity as subject_id and the event timestamp as occurred_at. Additional columns such as actor_id, event_type, stage_id, environment_id, target_id, outcome, or payload fields become available to virtual pattern queries, feature contracts, Lens evidence, and reports.

This matters because stage and society features are scoped through those relations. A stage-level metric over actors must aggregate only the actors contained by that stage. A society-level metric must aggregate only the stages in that society and the actors reached through those stages.

Abstraction Builder validates generated abstraction contracts before executing dry-run samples. source_query and relation_query values must be direct, sampleable set contracts: no CALL, UNION, LIMIT, SKIP, ORDER BY, or materialized collection contracts. Relation queries must return explicit AS source_id and AS target_id expressions so dry run can add a source predicate before execution instead of materializing the full relation set for every sampled subject.

Virtual patterns reuse those same contracts after registration. A variable bound as :actor(Member) exposes every column returned by the Member source query. At minimum that means subject_id, and often node_id, path, or useful source-query fields. Property access such as m.churn_risk first reads a returned source-query column. If no such column exists and a materialized feature with that field-like name exists for the abstraction, the runtime resolves the latest feature value for m.subject_id; with query-level ASOF, it resolves the latest value at or before the query timestamp.

The same applies to :event(VisitEvent): the bound variable is a row map with subject_id, occurred_at, and any other source-query columns. That makes event abstractions useful for ordered journeys, recency/gap features, response timing, action attribution, and report evidence without forcing callers to duplicate the raw event-table query.

Relationship variables behave the same way. MATCH (s:stage(Store))-[r:contains_members]->(m:actor(Member)) binds r as a map containing the relation query columns plus runtime metadata such as relation_name, canonical source_id, canonical target_id, query-direction from_id, query-direction to_id, and traversal_direction. The registered relation is canonical from the owning abstraction to target_abstraction, but Cypher traversal can also match the reverse endpoint order when the same relation connects the two abstraction sets.

More Detailed Explanation

In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with YIELD and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven abstraction procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.

Advanced Example

CALL nexyron.procedures()
YIELD name, parameters, output_columns
WHERE name = 'nexyron.abstraction_register'
RETURN name,
       [p IN parameters | p.name] AS parameter_names,
       output_columns
ORDER BY name

Real Use Cases

Real Limitations And Tradeoffs