Skip to main content

Alpha roadmap: pattern recognition and the next providers

· 8 min read
Ilker Yesilkaya
Creator of Nodal Framework
Two provider graph streams rise into a shared analytics shell where paths form communities and temporal transitions.
Nodal.PatternRecognition sits above providers as an optional analytics shell, turning canonical paths into explainable discoveries.

Nodal Framework is still an alpha, which is exactly the right time to test its most ambitious architectural claim: a provider-neutral graph model can support portable intelligence without flattening the native strengths of each graph engine.

P2 remains the production-hardening track. P3 starts the optional Nodal.PatternRecognition package. P4+ records the research horizon so experimental ideas do not silently become compatibility promises.

Nodal.PatternRecognition is not another database provider. It is an optional analytics shell above every provider: Neo4j, TigerGraph, and future engines keep their own query languages, transports, and native accelerators, while the shell consumes Nodal's canonical nodes, relationships, paths, events, and capability declarations. Provider pushdown is an optimization; the analysis contract and its evidence remain portable.

Building one .NET model for multiple graph engines

· 2 min read
Ilker Yesilkaya
Creator of Nodal Framework
Abstract connected graph illustrating the Nodal Framework architecture.
The Nodal Framework Journal documents architectural decisions, constraints, and lessons learned.

Graph databases share nodes and relationships, but their query languages, transports, transaction boundaries, and response formats are not interchangeable. Nodal Framework began with a simple rule: the domain should be portable, while execution should remain native.