---
title: `nexyron.abstraction_match`
url: https://nexyron.tech/docs/cypher/procedures/abstraction-platform/registry/nexyron-abstraction-match
description: nexyron.abstraction match resolves one registered abstraction into the virtual subject set that belongs to that abstraction.
---

# `nexyron.abstraction_match`

## Generic Description

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

```cypher
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:

```cypher
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:

```cypher
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

-   `name`: Abstraction name. Required.
-   `subject_id`: Optional subject identifier filter.

## Output Columns

-   `abstraction`
-   `kind`
-   `subject_id`
-   `node_id`
-   `path`
-   `source`

## 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:

```cypher
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

```cypher
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

-   Resolve the current member set before computing retention features.
-   Resolve the current event set before computing recency, cadence, journey, intervention-response, or temporal outcome features.
-   Bind a stage abstraction to all gyms, classrooms, stores, or facilities that can hold actors.
-   Audit whether a feature query returns subjects outside its owning abstraction.
-   inspect or operate named abstraction contracts without reconstructing hidden prompt context in the frontend
-   keep feature, dataset, snapshot, model, policy, and artifact workflows on the backend contract path

## Real Limitations And Tradeoffs

-   `CALL actor(Member)` is procedure sugar. `MATCH (m:actor(Member))` is pattern syntax. Both use the registered abstraction contract, but they enter the query pipeline differently.
-   Virtual pattern variables are maps. They support map-style property filtering and return expressions, and missing source-query fields may resolve through materialized abstraction features. They are not mutable stored nodes or edges.
-   Path aliases and variable-length virtual abstraction relationships are not supported yet.
-   Label-only abstractions can be resolved, but automatic snapshot seeding and membership validation are driven by `source_query` contracts so older label-only definitions keep their previous behavior.
-   An abstraction registered with neither a `source_query` nor a `label` has no member set to resolve. Knowledge-pack vocabulary and `LENS` definitions that carry only an analysis intent are registered that way on purpose, and matching one fails with `NEXYRON-V001` instead of returning an empty set, because zero subjects and no declared membership are different answers. Callers that walk the registry should read `source_query` and `label` from `nexyron.abstraction_list` and skip the abstractions that have neither.
-   The resolver does not repair weak source queries. If `source_query` omits subjects or uses unstable identifiers, downstream features inherit that weakness.