`nexyron.abstraction_read`
Generic Description
nexyron.abstraction_read read one abstraction definition
CALL nexyron.procedures()
YIELD name, description, parameters, output_columns
WHERE name = 'nexyron.abstraction_read'
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
name: Abstraction name Required.
Output Columns
namekindlabeldescriptionsource_queryrelation_countrelations_jsontagsoptions_json
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_read(...) 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_read is that it shows the resolver contract behind an abstraction. If source_query is set, that query is what nexyron.abstraction_match uses to produce the abstraction's virtual subject set.
description is the readable description for users and assistants. Structured runtime metadata is exposed separately through options_json; Lens definitions store their durable lens_plan there instead of serializing it into description.
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_read'
RETURN name,
[p IN parameters | p.name] AS parameter_names,
output_columns
ORDER BY name
Real Use Cases
- Register reusable member-retention contracts once, then let snapshots, datasets, models, and policies reference those names instead of duplicating raw Cypher in every workflow.
- Keep admin and product teams aligned around one shared abstraction contract for members, households, facilities, interventions, and churn labels during quarterly retraining cycles.
Real Limitations And Tradeoffs
- This surface is contract-driven. If the registered feature, snapshot, dataset, model, or policy definition is weak, the procedure will faithfully execute that weak contract rather than silently repairing it.
- Catalog procedures define or expose metadata. They do not by themselves build data, score models, or apply interventions.
- Use
nexyron.abstraction_matchwhen you need the resolved subjects rather than the stored definition.