---
title: nexyron.abstraction_graph.project
url: https://nexyron.tech/docs/cypher/procedures/catalog-and-projections/nexyron-abstraction-graph-project
description: nexyron.abstraction graph.project refreshes the abstraction LPG mirror and creates a named graph projection for algorithms.
---

# nexyron.abstraction_graph.project

## Generic Description

`nexyron.abstraction_graph.project` refreshes the abstraction LPG mirror and creates a named graph projection for algorithms.

```cypher
CALL nexyron.abstraction_graph.project({name: 'abstraction_graph'})
YIELD name, node_count, edge_count
RETURN name, node_count, edge_count
```

Catalog and projection procedures manage projected graphs, aggregate views, procedure metadata, and abstraction graph projections used by analytical workflows.

## Consumer-Level Explanation

Use this before running graph algorithms over the abstraction catalog graph itself.

```cypher
CALL nexyron.abstraction_graph.project({name: 'abstraction_graph'});
CALL nexyron.connected_components({graph: 'abstraction_graph'});
CALL nexyron.leiden({graph: 'abstraction_graph'});
```

The projection includes active abstraction nodes and active abstraction relationships created from live knowledge assertions. It excludes stale materializations by using query membership internally. Relationship defaults come from source-grounded knowledge assertions between `ACTOR`, `STAGE`, `SOCIETY`, `ENVIRONMENT`, and `LENS` abstractions, not from artifact lineage or legacy edge prototypes.

## Conceptual Explanation

`nexyron.graph.project` already projects ordinary LPG data. `nexyron.abstraction_graph.project` is a convenience layer for the abstraction catalog read model:

1.  Refresh the abstraction catalog into LPG nodes and relationships.
2.  Project `__AbstractionActive` nodes.
3.  Project active materialized source-grounded knowledge assertion relationships.
4.  Replace an existing projection with the same name so repeated calls are idempotent.

## 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 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.abstraction_graph.project({
  name: 'abstraction_quality_graph',
  relationship_types: ['RELATE_TO', 'INDICATES', 'INSTANCE_OF']
});

CALL nexyron.pagerank({graph: 'abstraction_quality_graph'})
YIELD node_id, score
MATCH (n)
WHERE id(n) = node_id
RETURN n.name, n.artifact_kind, score
ORDER BY score DESC
```

## Real Use Cases

-   Cluster concept graphs to detect duplicated or disconnected knowledge areas.
-   Run centrality over real abstraction and knowledge assertion structures without mixing in report or analysis-run artifact records.
-   Compare knowledge graph density before and after assistant ingestion.
-   Detect disconnected knowledge areas while keeping report and analysis-run artifact lineage in artifact metadata instead of graph assertions.

## Real Limitations And Tradeoffs

-   Projection snapshots are in-memory algorithm inputs. Refresh the projection when the abstraction catalog changes.
-   The materialized graph intentionally uses hidden labels so it does not collide with business labels.
-   Algorithm meaning depends on semantic modeling quality. A community in this graph is a community of abstraction artifacts, not necessarily a community of business subjects.