diniscruz.ai / writing / Cyber-Security

Using Memory_FS to Build a File-Based Representation of the GDPR Standard

By Dinis Cruz and ChatGPT Deep Research · · 28 min read

PDF LinkedIn post

Contents · 6 sections
  1. Abstract
  2. Introduction
  3. Methodology
  4. Implementation
  5. Future Work and Advanced Concepts
  6. References

Abstract

This white paper presents a method for converting the General Data Protection Regulation (GDPR) text into a structured, file-based representation using the Memory_FS framework. Targeted at technical professionals in compliance, data privacy, and regulatory data management, it outlines how to parse the official GDPR document into a hierarchical set of files (down to each article paragraph or bullet point) stored in Memory_FS. Each regulatory element is captured using Memory_FS’s three-file pattern – content, config, and metadata – providing a robust foundation for further processing. We detail the motivation for modeling GDPR as a graph and how Memory_FS serves as the foundational layer for this transformation. The methodology covers parsing strategies for the GDPR text, organizing content in Memory_FS, and ensuring fidelity through round-trip conversions (to Markdown and PDF). Implementation guidance is given with code examples illustrating how to ingest the GDPR document into Memory_FS and subsequently export or utilize the data. We also discuss how the resulting Memory_FS output can feed into graph databases (such as MGraph-DB) to generate knowledge graphs of the law, including storing intermediate representations (ZIP or SQLite) for cloud deployment. The paper highlights the advantages of Memory_FS’s pluggable storage backends (in-memory for development, ZIP/SQLite for versioned releases, S3 for scalable deployment) and introduces the concept of “G³” (Graphs-of-Graphs-of-Graphs), where Memory_FS archives are nested to enable recursive metadata structures.

Introduction

Modern compliance and data privacy initiatives demand structured regulatory data for robust analysis and automation. The GDPR, with its 99 Articles and 173 Recitals, is a prime example of a complex legal text that benefits from structured representation. For technical teams, representing such regulations in a machine-readable, hierarchical form enables easier querying, traceability, and integration with tools like knowledge graphs. Graph-based models for laws allow connecting related provisions, mapping obligations to controls, and visualizing relationships (e.g. which Recitals relate to which Articles) – essential for compliance management. Graph technology is well-suited for scenarios where relationships are as important as the data itself, and GDPR’s provisions are highly interlinked (articles reference each other, recitals contextualize articles, etc.).

Memory_FS provides an ideal foundation for this task. Memory_FS is a type-safe in-memory filesystem abstraction that offers a unified interface to store and retrieve files across multiple backends. It was designed with features that align with the needs of representing structured documents: strong typing and validation, a flexible folder/file model, and pluggable storage (memory, local disk, databases, cloud). Critically, it implements a “three-file pattern” wherein each logical file is backed by three physical files: a content file (holding the data), a config file (with file metadata and configuration), and a metadata file (with auto-generated metadata like hashes and timestamps). This pattern ensures each piece of information is richly described and versionable, which is advantageous for storing legal text with traceability.

This paper details the motivation and process for representing the GDPR as a graph of files using Memory_FS. We first discuss the methodology for deconstructing the GDPR document into a hierarchical filesystem reflecting its structure (Chapters, Articles, paragraphs). Then we dive into the implementation: using Memory_FS to create and manage these files, preserving the legal document’s structure down to each paragraph or bullet point. We demonstrate how to perform round-trip conversions – ingesting the official text into Memory_FS, exporting it to a convenient format like Markdown, and even regenerating a PDF – to verify fidelity and enable collaboration. Next, we outline how the Memory_FS output can be used to build a graph database representation (for example, loading into MGraph-DB, a memory-first graph database) and how intermediate formats (such as a ZIP archive or SQLite database) can facilitate cloud-based deployments of the data. We highlight the use of different Memory_FS storage providers in various stages: in-memory for development/testing, and persisted (on disk or cloud) for production scaling. Finally, we introduce an advanced concept dubbed G³ (Graphs of Graphs of Graphs) – a strategy for nesting Memory_FS instances within each other to create recursive graph structures. This concept shows how one can manage multiple layers of structured data (e.g., a corpus of standards) in a unified framework, which points to future applications beyond a single regulation.

Methodology

Representing GDPR as a Graph of Files: The first step is to define how the GDPR document’s structure will map to a filesystem hierarchy. The GDPR’s text is organized into Chapters, Sections (in some cases), Articles, and within articles, paragraphs and sub-points. We preserve this hierarchy by treating each structural unit as a folder or file in Memory_FS. The motivation is to capture the law in atomic units (individual provisions) that can be independently referenced, yet maintain the context of the larger hierarchy (which article a paragraph belongs to, etc.). By modeling each unit as a file node in a graph (the file system is inherently a tree structure), we lay the groundwork for building a full knowledge graph of the regulation.

Designing the Hierarchical Structure: We choose to represent top-level groupings (like Chapters or Sections) as directories, and individual provisions (Articles and paragraphs) as files. For example, “Chapter 1 – General Provisions” can be a folder containing files for each article in that chapter. Each Article might be a subfolder containing files for each paragraph if fine-grained access to paragraphs is needed. Alternatively, each Article could be a single file if the text is short, but GDPR articles often have multiple numbered paragraphs and lettered sub-points, so representing each as a separate file makes it easier to link or annotate them individually. This approach aligns with the note that most GDPR Articles have numbered paragraphs and sub-paragraphs, which we model as distinct file nodes. The hierarchy ensures that context isn’t lost: a paragraph file’s path encodes its location (e.g., GDPR/Chapter_1/Article_5/Article5-Paragraph2.md could represent Article 5, paragraph 2). We preserve article and paragraph numbering in file names or IDs to maintain readability and ordering.

Parsing the Official Document: To build this hierarchy, we parse the official GDPR text (available as PDF via EUR-Lex, or websites like gdpr-info.eu). Parsing involves extracting the structure: identifying chapter titles, article headings, and paragraph breaks. This can be done with text processing: for example, detecting lines that match the pattern “Article X” (with X as a number) as article boundaries, and numerical or alphabetical labels as paragraph or sub-point boundaries. Tools like PDF text extractors or even regex on provided text can assist in splitting the document. The parsing logic must capture the nested structure correctly (for instance, an article may have paragraphs labeled 1., 2., etc., and within those, points (a), (b), etc.). We also capture Recitals (the prefatory statements numbered 1–173) as part of the structure – these could be stored in a separate top-level directory “Recitals” with one file per Recital, since each Recital is typically a distinct paragraph of text.

Using Memory_FS Three-File Pattern: Each identified text unit (e.g., a particular paragraph of an article) will be stored following Memory_FS’s three-file pattern. Concretely, for each unit we create:

The choice of file format for content is important. We use Markdown (.md) for textual content because it can preserve formatting (lists, headings, emphasis) and is easily convertible to other formats (HTML, PDF). Memory_FS natively supports a Markdown file type via Memory_FS__File__Type__Markdown, which ensures content is handled as UTF-8 text and can be serialized/deserialized without losing structure. Alternatively, plain text could be used (Memory_FS__File__Type__Text), but Markdown allows us to keep bullet lists or references in format.

Preserving Structure and Metadata: We ensure each file’s config contains a logical identifier that encodes its position (for example, an ID like "Art5-para2" or a composite key). Memory_FS’s type-safe IDs (Safe_Id) can be used to enforce valid naming. The config can also include a human-readable title or reference (e.g., “Article 5 Paragraph 2”) if needed for documentation. The hierarchical placement (via directories or path prefixes) will already convey the structure; for instance, the path GDPR/Chapter_2/Article_5/Art5-para2.md inherently tells us the context. We leverage Memory_FS path strategies to handle these directories. Specifically, we can use a custom path strategy or explicitly set the file_paths in the file’s config to include the directory path. For example, specifying file_paths=["GDPR/Chapter_2/Article_5"] for a file config will place that file (and its config/metadata) under the desired folder structure. Memory_FS’s Path__Handler__Custom allows user-defined hierarchical paths for files, which we use to mirror the legal document outline in the filesystem.

Round-Trip Conversion Approach: A critical part of the methodology is ensuring that our file-based model is faithful to the source and can be converted back into a human-readable document. We plan a round-trip:

  1. Ingestion – the original GDPR PDF/Word is parsed into Memory_FS (as described above),
  2. Export – the Memory_FS content is then programmatically exported to a compiled format like a Markdown document or PDF. The export entails iterating through the structured files in the correct order and reconstructing the text (in Markdown we can also include the hierarchical headings).
  3. Verification – the generated Markdown or PDF is compared to the original to verify no text was lost or altered. This round-trip ensures our parsing logic captured everything and the Memory_FS representation is complete. It also demonstrates the utility of the structured data: once in Memory_FS, we can produce updated outputs (for instance, a company-specific GDPR handbook with annotations) easily by traversing the file graph.

By outlining these steps before implementation, we ensure that the approach is robust. The end result of the methodology is a plan to have each GDPR provision as a node in a file graph, stored with content and rich metadata. This forms the basis for a knowledge graph and further automated processing, as described in later sections.

Methodology Summary

With this methodology established, we proceed to implement the process, providing concrete examples and code snippets to illustrate how Memory_FS is used to achieve the above.

Implementation

Parsing the GDPR Document into Memory_FS

Document Ingestion: We begin by acquiring the GDPR text. For reproducibility, one can use the official PDF from EUR-Lex or an existing text source (some websites provide the full GDPR text in HTML). Using a PDF parsing library (or manual copy if needed), we extract the text while preserving indicators of structure. Pseudo-code for parsing might look like:

text = extract_text("GDPR.pdf")  # use a PDF text extraction utility
sections = split_into_sections(text)  # custom logic to split by Chapter/Article

The function split_into_sections would implement rules to detect lines like “Chapter 1”, “Article 5”, etc., and break the text accordingly. For example, whenever a line matches the regex ^Article\s+(\d+), that indicates a new Article. The following lines up to the next article heading belong to that article. Within an article, paragraphs are often numbered (“1. …”, “2. …”) – we can further split those. Many articles contain lists labeled (a), (b), … which we treat as sub-paragraphs. We handle those by splitting paragraphs by patterns like “(a) ” if needed. Each identified unit (be it a full Article or an individual paragraph) will be represented as a node in Memory_FS.

Creating Memory_FS Files: With the text units identified, we instantiate a Memory_FS object and create file entries for each unit. Below is an example code snippet illustrating how to create Memory_FS entries for a single paragraph. In practice, this would be inside loops iterating over chapters/articles/paragraphs:

from memory_fs.Memory_FS import Memory_FS
from memory_fs.file_types.Memory_FS__File__Type__Markdown import Memory_FS__File__Type__Markdown
from memory_fs.schema.Schema__Memory_FS__File__Config import Schema__Memory_FS__File__Config

# Initialize the in-memory filesystem
memory_fs = Memory_FS()

# Example: Save Article 5, Paragraph 2 text into Memory_FS
paragraph_text = "2. The controller shall ... (text of Article 5(2))"
file_config = Schema__Memory_FS__File__Config(
    file_id="Art5-Para2",  # a unique ID for the file
    file_type=Memory_FS__File__Type__Markdown(),
    file_paths=["GDPR/Chapter_2/Article_5"]  # hierarchical path within the FS
)
memory_fs.save().save(paragraph_text, file_config)

In this snippet, Memory_FS__File__Type__Markdown() is used to specify that the content is Markdown text. The file_paths parameter is a list of directory paths within the Memory_FS storage where this file should be saved – here we indicate the file lives under GDPR/Chapter_2/Article_5. Memory_FS will ensure that the content, config, and metadata files for Art5-Para2 are all stored in that directory, with appropriate naming (e.g., Art5-Para2.md, Art5-Para2.md.config, Art5-Para2.md.metadata). The first call to memory_fs.save().save(data, config) will automatically generate the trio of files: a config JSON (immutable after creation, containing file identity and settings), the content file with the paragraph text, and a metadata file with properties like content length and a hash. Each subsequent save (if content is edited) would update the content and metadata files, but not the config (since config is fixed per file identity).

We repeat this process for all content units. For instance, we create a file for each Recital (with file_paths=["GDPR/Recitals"] and IDs like “Recital-1”), for each Article title or full article text (if storing as a whole), and for each paragraph within articles. In a structured approach, one might create a directory for each Article and store each paragraph as a separate file within it, as shown. Alternatively, to simplify, one could store each article’s entire text as a single Markdown file (with internal headings or list for paragraphs); however, we choose granular files to enable fine-grained graph nodes and easier cross-referencing of specific clauses.

Configuring File Metadata: The Schema__Memory_FS__File__Config we instantiate typically includes the file’s unique ID, type, and path as shown. Additional metadata (like human-friendly names, cross-references) can be embedded in various ways:

Memory_FS ensures strong consistency across these three files. Using its API, we can check existence or retrieve info easily. For example, after creation, memory_fs.load().load_data(file_config) would load and return the paragraph text we saved, and memory_fs.data().exists(file_config) would indicate the file’s presence. These high-level APIs wrap around the core File_FS operations (create, exists, delete, etc.), simplifying file handling. This means once our parsing loop populates Memory_FS, we have an in-memory repository of GDPR content that we can query or manipulate with simple calls.

Bulk Insertion and Automation: In practice, creating hundreds of files (99 articles plus recitals and subdivisions) is feasible through loops. We can optimize by reusing Schema__Memory_FS__File__Config objects or caching frequently used components (like the Markdown file_type object). Memory_FS is efficient in-memory; creating many small files in memory is not expensive. If needed, the process can be batched or transactional. For example, one could accumulate all file configs and content first, then save them in one pass. Memory_FS could also potentially use transactions to ensure that either all files are saved or none (this feature might tie into future transaction support). For initial implementation, straightforward iterative creation is sufficient.

Round-Trip Conversion (Export to Markdown/PDF)

Once the GDPR content is stored in Memory_FS, we validate the representation by reconstructing the document from it. This round-trip conversion demonstrates that our file-based model retains all information and ordering.

Export to Markdown: We traverse the Memory_FS structure in the logical order of the document. Because we used directory names and file IDs that sort in the correct sequence (e.g., “Chapter_1” comes before “Chapter_2”; within a chapter directory, “Article_5” comes before “Article_6”; within an article, “Para1” before “Para2”, etc.), we can rely on lexicographic order of file paths to assemble the content. Memory_FS provides a method files__paths() that can list all stored file paths. We can filter/sort that list, or we can navigate directory by directory using a known structure.

For example, to reconstruct Chapter 2’s text:

chapter2_paths = [p for p in memory_fs.storage.files__paths() if p.startswith("GDPR/Chapter_2/")]
for path in sorted(chapter2_paths):
    content = memory_fs.storage.file__str(path)  # get file content as string
    append_to_markdown(chapter2_markdown, content)

Here, memory_fs.storage.file__str(path) reads the content file bytes and decodes to string. We then append to an output, adding appropriate Markdown headings for chapter and article titles if those are stored separately. (If we saved article titles as separate files or as part of the first paragraph file, we handle that accordingly). In the simplest approach, if each article’s first paragraph file actually contains the article title as part of content (e.g., in Markdown "# Article 5 – Title" followed by the text), then the export is straightforward concatenation in order.

After assembling all chapters into a Markdown text, we have a full Markdown version of GDPR. This can be checked for consistency. Each article and paragraph should appear exactly as in the original, just now each piece came from our structured store.

Conversion to PDF: To complete the round-trip, we convert the Markdown to PDF. This can be done with existing tools (for instance, using pandoc or a Markdown-to-PDF library). The specifics are outside the scope of Memory_FS, but an example command might be: pandoc GDPR.md -o GDPR_Reconstructed.pdf. The expectation is that GDPR_Reconstructed.pdf should match the official PDF (barring minor formatting differences). This demonstrates that our Memory_FS representation did not lose any content and that it could serve as a reliable source of truth.

Benefits of Round-Trip: This flow not only validates correctness but also opens up useful workflows:

In summary, the implementation of round-trip conversion confirms that Memory_FS acts as a lossless intermediate representation for the GDPR document, enabling both programmatic transformations and human-readable outputs as needed.

Generating a Graph Database from Memory_FS Output

With GDPR content structured in Memory_FS, we can now leverage it to create a graph representation – turning the file hierarchy into nodes and edges in a graph database. The impetus for this is to enable complex queries like “show all references to consent across the regulation” or “link Recital 50 to the Articles it explains”. While Memory_FS itself organizes data in a tree, a graph database can store richer relations (including cross-links that are not strictly hierarchical).

Using MGraph-DB (Memory-First Graph Database): The MGraph-DB (also referred to as MGraph-AI in some contexts) is a graph database designed to work seamlessly with JSON and file-based storage, prioritizing in-memory operation for speed. We can use the GDPR Memory_FS output as input data for such a graph DB. There are two primary ways to do this:

  1. Direct Loading: If the graph database can directly consume the Memory_FS structure (for example, by reading the JSON config files or a consolidated export), we write a loader that goes through each Memory_FS file and creates graph nodes and edges. Each paragraph file becomes a node (with properties like “text” = content, “article” = number, etc.). We also create nodes for higher-level constructs like Articles or Chapters – these could either be explicit nodes or implicitly inferred from grouping nodes.
  2. Intermediate Format: Alternatively, we first export the entire Memory_FS as an intermediate format, such as a SQLite database or a single ZIP file, and then have the graph database ingest that. Memory_FS’s storage abstraction can help here; for instance, one could use the Storage_FS__Sqlite backend (once implemented) to save all files into a SQLite DB. This would yield a file (say gdpr.db) containing tables/entries for all content, config, metadata. A graph tool could then read from this database to create nodes and edges. Similarly, using a ZIP archive (via a Storage_FS__Zip if available, or by zipping the Memory_FS’s content from memory) could package all JSON and MD files into one archive that a graph ingestion script can parse.

Defining Graph Nodes and Edges: In our graph model, we define:

python from mgraph_db import MGraph graph = MGraph() # create nodes and edges using data from memory_fs for para_file in all_paragraph_files: node = graph.edit().add_node(node_id=para_file.file_id, attributes={"text": para_file.content, "type": "Paragraph"})

(This is pseudo-code; actual API may differ, but conceptually we add nodes with attributes.)

Once the graph is constructed, we can persist it using MGraph’s storage (likely also JSON or a file-based snapshot). At this point, we have effectively transformed the GDPR text into a knowledge graph, where each clause is a node and relationships like containment or reference are edges. This graph can then be queried with graph queries (e.g., find all paragraphs related to a certain topic, traverse from a Recital to related Articles, etc.). It can also support advanced use cases like semantic search or linking GDPR to other regulations (if those are also ingested similarly).

Storing Intermediate Representations: As mentioned, intermediate formats help in scaling deployment:

Using these intermediate forms, organizations can deploy the structured GDPR in a cloud environment where it can be accessed via APIs. One could imagine a service that serves parts of GDPR via a GraphQL API, backed by Memory_FS + S3. In fact, Memory_FS’s roadmap includes integration points like a GraphQL/REST API and CLI tools, which would allow querying the filesystem (and thus the regulatory content) in flexible ways. For instance, a GraphQL query could retrieve an article by number, or fetch all paragraphs that contain a keyword, all powered by the structured store.

Validation in Graph Form: A quick verification when generating the graph is to ensure node counts and certain relationships match expectations. For example, ensure that “contains” edges count matches the number of paragraphs per article from the source (Article 5 had X paragraphs, so the Article 5 node should have X outgoing contains edges to paragraph nodes). This cross-checks the integrity of the graph against the Memory_FS source. Since Memory_FS is the source of truth, if any discrepancy is found in the graph, it likely means an error in the graph construction logic, which can be corrected.

In conclusion, the downstream graph generation is a natural extension of the Memory_FS representation. Memory_FS provides the clean, file-granular data needed to populate a graph database effectively. By using intermediate formats and the flexibility of Memory_FS to plug into different storage, we ensure that this step can scale from a local environment (loading from a file or memory) to an enterprise setup (loading from a cloud store or database). The resulting graph (which could be implemented in MGraph-DB or even Neo4j, etc.) becomes a powerful tool for compliance experts, enabling queries that answer complex questions about the regulation’s content and its interrelationships.

Deployment Considerations: Memory_FS Storage Providers

During development and prototyping, we use the in-memory storage of Memory_FS (the default Storage_FS__Memory), which stores files in Python dictionaries in memory. This is fast and convenient for testing, as all operations are simply manipulating in-memory bytes. However, for persistence and sharing of data, Memory_FS supports multiple storage providers via its Storage Abstraction Layer. We leverage these to transition from development to release:

Benefits of Pluggable Storage: The ability to switch storage by changing a single configuration means our implementation is not locked into one environment. We used in-memory for parsing and validation; we can then save to a durable format for distribution. For example, after building the in-memory FS, we could instantiate a new Memory_FS with a SQLite storage and programmatically copy files over (or in the future, Memory_FS might support directly migrating storage). This yields a production-ready artifact. In a continuous integration pipeline, one could automate: parse latest GDPR -> produce Memory_FS -> save to gdpr.zip (zip storage) or gdpr.db (SQLite) -> publish artifact. Consumers of the artifact can either use Memory_FS to load it or use it as input to their database as described. The pluggable layer thus supports both versioned releases (where you want read-only snapshots) and live services (where cloud storage enables concurrent read/write).

Future Work and Advanced Concepts

Graphs of Graphs of Graphs (G³) – Nested Memory_FS Structures

One forward-looking concept is G³ (Graphs of Graphs of Graphs), which in our context translates to nesting Memory_FS representations within one another to create layered graphs. Practically, this means we can treat an entire Memory_FS (like our GDPR file graph) as a single file in a higher-level Memory_FS. For instance, imagine we have multiple regulatory standards (GDPR, CCPA, HIPAA, etc.), each parsed and stored as a Memory_FS archive (perhaps each saved as a ZIP or SQLite file). We could create a top-level Memory_FS called “Compliance_Library” and store each regulation’s archive as a binary content file in it. Each of those files (say gdpr.zip stored in the parent FS) carries its own config and metadata, and perhaps metadata indicating it’s a Memory_FS archive of a regulation (a custom file type or a flag in config could denote this). The parent Memory_FS thus becomes a graph of graphs – its files are themselves graphs (the regulations), and you could even nest further if needed (graphs of graphs of graphs).

The benefit of this G³ approach is a recursive metadata structure: the parent layer can store high-level metadata about each graph (e.g., GDPR version, last updated date, jurisdiction), and the child layers (the actual Memory_FS of GDPR) store the fine-grained metadata of the content. This enables complex queries like: “find a concept in all regulations” – one could open each nested Memory_FS in turn and search within, or even index them collectively at the parent level by storing summary info in the parent config. It also mirrors how knowledge graphs can have sub-graphs or partitions; here each Memory_FS archive is an independent sub-graph that can be connected via the containing structure.

Implementing G³ with Memory_FS is straightforward given its design:

As Dinis Cruz notes, G³ is about having “ontologies of ontologies” and ways to connect multiple graphs/domains. In our implementation context, using Memory_FS recursively provides a clean, file-based way to encapsulate and connect these multi-graph structures. It opens the door to composite regulatory graphs – e.g., a European Privacy graph that contains GDPR plus related regulations, each as subgraphs, all managed in a unified system.

Enhancements and Future Features

While the current approach successfully represents GDPR in Memory_FS and exports it, there are several areas for future enhancement:

Broader Applications

While developed for GDPR, the file-based graph representation approach can be applied to any structured text (other laws, standards, policies). The combination of Memory_FS and a graph database provides a pipeline from unstructured documents to a rich, queryable knowledge base. Future work could include applying this to build a “compliance knowledge graph” containing multiple regulations linked by common concepts (using the G³ approach). Another avenue is integrating with AI tools: for instance, using LLMs to automatically summarize each file (paragraph) and storing the summary in a parallel file structure, or using the structured data as a retrieval source for GPT-based question answering. Memory_FS’s type-safe design and serialization support ensures that even if we store complex objects (like embedding vectors for paragraphs, or Type_Safe objects), they can be serialized to JSON or binary and stored alongside the text. This means we could augment the regulatory graph with AI-generated insights without leaving the Memory_FS-managed ecosystem.

In summary, the work done here to represent GDPR in Memory_FS is a foundational step. Future enhancements will deepen the intelligence of the data (through metadata and links) and broaden its accessibility (through APIs and integration into cloud systems). The concept of graphs of graphs will enable scaling to entire libraries of knowledge, maintaining structure at every level. By continuing to leverage Memory_FS’s flexible architecture and extending it where needed, we can build robust, scalable systems for managing and querying complex bodies of text like the GDPR.

References

  1. Memory-FS Technical Debrief (2025) – Architecture and Key Features of Memory_FS, esp. type safety, storage backends, and three-file pattern.
  2. GDPRhub – Overview of GDPR – description of GDPR structure (173 recitals, 99 articles with paragraphs and sub-points).
  3. Neo4j Blog (2018) – Graph Databases as GDPR Compliance Tools – discusses why graph relationships are crucial for GDPR data management.
  4. LinkedIn Post by Dinis Cruz (2025) – On G³ (Graphs of Graphs of Graphs) – explains the concept of connecting multiple graphs and ontologies.
  5. Dinis Cruz (2025) – MGraph-AI introduction – outlines a memory-first graph database approach that complements Memory_FS for persistence and querying of graph-structured JSON data.

Released under CC BY 4.0. First published on docs.diniscruz.ai; this page as markdown.

← Ephemeral GenAI SIEM: A Serverless, Graph-Driven Approach to Security Event ManagementLLM-Driven GDPR Compliance Q&A Graph – Technical Brief →