`nexyron.abstraction_match`

Generic Description

nexyron.abstraction_match resolves one registered abstraction into the virtual subject set that belongs to that abstraction.

CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.abstraction_match'
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

An abstraction is not only a label description. When it has a source_query, that query is the contract for the subjects that belong together as one semantic set. nexyron.abstraction_match executes that contract and returns the subject rows that later features, snapshots, datasets, models, and policies should use.

For convenience, the same resolver is available through kind-specific sugar procedures:

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

The sugar forms are actor(...), event(...), stage(...), society(...), and environment(...). They check that the resolved abstraction has the matching kind.

Registered abstractions can also be used as row-backed Cypher pattern endpoints:

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

This is different from procedure sugar. CALL actor(Member) yields rows from the resolver procedure. CALL event(VisitEvent) does the same for temporal occurrence contracts. MATCH (m:actor(Member)) or MATCH (v:event(VisitEvent)) binds the variable as a virtual row map produced by the abstraction's source_query, and relation traversal uses the registered abstraction relation's relation_query.

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_match(...) 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

This procedure is the runtime bridge between the catalog definition and feature generation. A source_query should return every current subject in the abstraction with a stable subject_id. It may also return node_id when one graph node is the clear owner, and path when the abstraction is path-backed.

For EVENT abstractions, the source query must also return occurred_at. The event variable then exposes both event.subject_id and event.occurred_at, plus any extra source-query fields such as actor, stage, target, outcome, or payload columns.

Feature queries still return ordinary rows, but their subject_id values are now expected to line up with this resolver. Source-query-backed abstractions are used by snapshot building to seed and validate feature rows.

Virtual abstraction patterns reuse the same source-query and relation-query contracts, so they are best understood as query expressions over registered contracts. The variable produced by (m:actor(Member)) is a map of source-query columns, not a stored node. A relationship variable such as r in -[r:contains_members]-> is a map of relation-query columns, not a stored edge. That shape lets normal Cypher filtering and return expressions work:

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

The canonical relation direction is the direction registered on the owner abstraction. For example, a Store relation named contains_members targets Member and returns source_id as the store and target_id as the member. A query may still traverse the same relation from member to store; the relationship map includes traversal_direction so callers can see whether the match used canonical or reverse endpoint order.

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_match'
RETURN name,
       [p IN parameters | p.name] AS parameter_names,
       output_columns
ORDER BY name

Real Use Cases

Real Limitations And Tradeoffs