Knowledge Graphs For UAIX Project Handoff

UAIX Project Handoff already has most of the *ingredients* of a knowledge graph, even though UAIX does not currently publish Project Handoff itself as a formal RDF or property-graph standard. The public spec defines a...

Metadata

Field	Value
Source site	uaix.org
Source URL	https://uaix.org/
Canonical AIWikis URL	https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-41d1594c/
Source reference	raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/knowledge-graphs/Knowledge Graphs for UAIX Project Handoff.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-06T14:51:59.9736194Z
Content hash	sha256:41d1594ce6ae7787201ac31eff4fab49635c6bc89868aeee3048719fe50955c4
Import status	unchanged
Raw source layer	data/sources/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-improve-41d1594ce6ae.md
Normalized source layer	data/normalized/uaix/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-06-improve-41d1594ce6ae.txt

Current File Content

Structure Preview

• Knowledge Graphs for UAIX Project Handoff
• Executive Summary
• Foundations of Knowledge Graphs
• Mapping UAIX Project Handoff Into a Graph
• Ontology, Identifiers, Provenance, and Validation
• Tooling, Databases, and Export Formats
• Query Patterns, Workflows, and Implementation
• Testing, Migration, and Roadmap

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 41032
• Preview characters: 11982

# Knowledge Graphs for UAIX Project Handoff

## Executive Summary

UAIX Project Handoff already has most of the *ingredients* of a knowledge graph, even though UAIX does not currently publish Project Handoff itself as a formal RDF or property-graph standard. The public spec defines a durable handoff bundle centered on `AGENTS.md`, `readme.human`, and typed `.uai` records, and the related AGENTS spec already describes optional IDs, provenance, access controls, and a `links` structure for interconnected knowledge. Just as importantly, UAIX currently positions this pattern as **portable project memory** and a **draft public handoff pattern**, not as a runtime orchestrator or an endorsed graph product. That strongly suggests the safest architecture is to treat the graph as a **derived projection** from canonical UAIX files, not as the authoring source of truth. citeturn1view0turn2view0turn19view1turn28view3

If the goal is to “deep-dive” into knowledge graphs rigorously, the most important conceptual split is between the **RDF/OWL stack** and the **property-graph stack**. RDF gives you globally identified facts, standard serializations such as JSON-LD, Turtle, and RDFa, W3C-standard query and validation via SPARQL and SHACL, and clean interoperability for provenance and metadata. Property graphs give you nodes, directed typed relationships, and key-value properties on both nodes and edges, along with very strong operational tooling and excellent interactive exploration in systems such as Neo4j. For UAIX, both stacks are useful, but they solve slightly different problems. citeturn12view1turn11view1turn11view2turn16view5turn26view2turn17view1

The most robust implementation path is to make **JSON-LD the canonical semantic export**, because JSON-LD is explicitly designed as a JSON-based Linked Data syntax that integrates smoothly with existing JSON systems, while UAIX’s `.uai` proposal already frames `.uai` files as structured JSON- or YAML-style documents with machine-readable fields. From that canonical export, derive **Turtle** for human review and SPARQL stores, and optionally derive a **property-graph projection** for Neo4j, JanusGraph, or Neptune openCypher workloads. This “RDF-canonical, property-graph-projected” pattern minimizes semantic drift while still serving developer-facing graph tooling. citeturn11view2turn19view1turn16view4turn11view12

For ontology design, keep the first version deliberately small. A minimal UAIX ontology only needs a few classes such as `Project`, `HandoffBundle`, `Artifact`, `ContextRecord`, `Constraint`, `Decision`, `WorkItem`, `Check`, `AgentRun`, and `Claim`, plus relations such as `references`, `appliesTo`, `affects`, `requiresCheck`, `blockedBy`, `wasGeneratedBy`, `wasDerivedFrom`, and `approvedBy`. Reuse **PROV-O** for provenance rather than inventing a new provenance vocabulary, and stay close to **RDFS plus a little OWL 2 RL** rather than starting with a large expressive ontology. citeturn11view4turn11view5turn13view4

For identifiers, use stable HTTP URIs for enduring entities and immutable snapshot URIs for bundle versions or release states. Do **not** rely on blank-node identifiers for durable UAIX records, because W3C’s RDF spec is explicit that blank-node identifiers are locally scoped to a file or store and are not persistent or portable. UAIX’s own public material already points toward stable IDs, checksums, bytes, source templates, and trust boundaries, which makes a persistent-ID strategy a natural extension rather than a conceptual leap. citeturn13view5turn24view0turn24view1turn22view0turn22view1turn19view1

On storage choices, the short recommendation is straightforward. Choose **Neo4j** if the main need is developer productivity, Cypher, visualization, and operational graph exploration. Choose **Amazon Neptune** if you want a managed service that can serve both RDF/SPARQL and property-graph workloads in one platform. Choose **JanusGraph** if you expect very large distributed property graphs and are comfortable with more operational complexity. Treat **Blazegraph** mainly as an RDF/SPARQL compatibility option for existing environments, not as the default greenfield choice, because its public GitHub repository was archived in March 2026. citeturn26view2turn17view0turn11view12turn11view9turn20view4turn20view5turn18search11turn11view8turn20view0turn15view0turn15view1

The migration plan should be phased. First, normalize current UAIX files and assign stable IDs. Second, emit JSON-LD and Turtle while preserving UAIX JSON Schema validation. Third, add SHACL for graph validation and stand up an RDF query endpoint. Fourth, project the same source into a property graph for operational UI and Cypher workflows. Fifth, wire provenance, approvals, and release evidence into graph queries and dashboards. That path matches UAIX’s own emphasis on verification plans, reviewable context, checksums, human approval, and evidence-backed claims. citeturn23view0turn23view3turn22view4turn22view0turn2view4

## Foundations of Knowledge Graphs

A rigorous deep-dive into knowledge graphs starts with the data model. In the RDF model, an RDF graph is a set of triples, and a triple is a 3-tuple of **subject**, **predicate**, and **object**. Subjects are IRIs or blank nodes, predicates are IRIs, and objects can be IRIs, blank nodes, literals, or—in RDF 1.2—triple terms. W3C also distinguishes an RDF document from an RDF graph: the same graph can be serialized in different concrete syntaxes such as JSON-LD, Turtle, RDFa, N-Triples, or TriG without changing its meaning. citeturn12view1turn12view5turn12view2

In the property-graph model, the core primitives are different. Neo4j’s official documentation describes a property graph as nodes connected by relationships, where nodes describe domain entities, relationships describe directed typed connections between source and target nodes, and both nodes and relationships can carry key-value properties. This is close enough to RDF to support many of the same use cases, but it is not the same abstraction. RDF is facts-first and standards-first; property graphs are typically traversal-first and operational-tooling-first. citeturn26view2

The next layer in a deep-dive is the difference between **vocabularies** and **ontologies**. RDF Schema provides a data-modeling vocabulary for RDF data, which is often enough when the goal is to define classes and properties with very light semantics. OWL 2 goes further: W3C describes it as an ontology language with formally defined meaning, providing classes, properties, individuals, and data values, and notes that OWL ontologies are primarily exchanged as RDF documents. In practice, that means RDFS is usually the right baseline for a first UAIX graph, while OWL should be introduced selectively where you truly need richer constraints or inference. citeturn11view5turn11view1

For knowledge graphs that matter operationally, **identifiers**, **provenance**, and **validation** are not optional extras. W3C’s Data on the Web Best Practices says that URIs should be used to identify resources and that resources should be published with stable URIs so they can be referenced and linked. W3C’s PROV family defines provenance as information about entities, activities, and people involved in producing data or things. W3C’s SHACL defines a language for validating RDF graphs against a set of conditions expressed in a shapes graph. Together, these three layers answer three separate questions: *what is this thing*, *where did it come from*, and *does it conform to the rules*. citeturn24view0turn11view4turn12view6

A practical deep-dive path therefore looks like this: first learn RDF triples, IRIs, literals, and datasets; then learn RDFS and a lightweight OWL profile; then learn provenance with PROV-O; then learn graph validation with SHACL; and only after that choose operational storage and query tooling. For the property-graph side, the parallel path is nodes, labels, typed relationships, properties, schema constraints, and Cypher or Gremlin. Because openCypher is evolving toward ISO GQL, it is also useful to treat modern property-graph querying as a standardizing ecosystem rather than a single-vendor language. citeturn12view1turn11view4turn12view6turn26view2turn17view1

| Dimension | RDF and OWL stack | Property-graph stack | What it means for UAIX |
|---|---|---|---|
| Core unit | Triple in an RDF graph | Node and directed relationship | UAIX facts such as decisions, constraints, checks, and provenance map cleanly to both, but RDF is more portable |
| Identity | Global IRIs are first-class | Labels and IDs are implementation-specific conventions | UAIX should define stable URIs early |
| Semantics | RDFS and OWL are standardized | Semantics are usually application-defined | UAIX can start small with RDFS-like design and add only a little OWL |
| Validation | SHACL is the W3C standard | Validation is store- or app-specific | Keep UAIX JSON Schema, then add SHACL for graph validation |
| Query | SPARQL | Cypher or Gremlin | Support both when possible: SPARQL for evidence and interoperability, Cypher for exploratory operations |

This comparison synthesizes W3C RDF, RDFS, OWL, SHACL, and SPARQL documents together with Neo4j’s property-graph documentation and openCypher’s positioning toward GQL. citeturn12view1turn11view5turn11view1turn12view6turn11view6turn26view2turn17view1

## Mapping UAIX Project Handoff Into a Graph

The Project Handoff spec defines a concrete bundle structure that is unusually easy to map into a knowledge graph. The public page describes `AGENTS.md` as the “durable front door,” `readme.human` as the human briefing, and typed `.uai` files as the place where durable project knowledge is split into context, stack, architecture, constraints, progress, test plans, and related records. It also states that `@uai[]` references make required context explicit before the next assistant starts work, that `constraints.uai` can be compiled into runtime guardrails and approval gates, and that accepted traces and decisions are written back into `.uai/progress.uai`, `.uai/decisions.uai`, and `AGENTS.md` after work. citeturn3view0turn23view3turn3view7

The AGENTS.md `.uai` linking spec reinforces that graph-friendly structure. It describes `.uai` files as machine-readable JSON/YAML-style documents with fields such as `schemaVersion`, `id`, `version`, `context`, `provenance`, `accessControl`, and `links`; it explicitly includes a `links` array with `rel`, `href`, and `type` and says this “supports interconnected knowledge.” It also states that a Project contains one `AGENTS.md` and any number of `.uai` files, and that agents read `AGENTS.md` plus referenced `.uai` files to acquire knowledge. citeturn19view1turn2view0turn2view2

That means the correct modeling move is **not** to treat each file as a blob and stop there. Instead, model files at two levels at once. At the document level, each file is an explainable, governed artifact with authoring metadata, provenance, checksums, trust boundaries, and references. At the content level, the file is a source for more granular graph nodes such as `Constraint`, `Decision`, `CheckPlan`, `WorkItem`, `Owner`, `Component`, `Risk`, and `Claim`. This two-level pattern is especially important because Project Handoff explicitly distinguishes reviewable durable context from raw chat history and uses verification plans, trust boundaries, and human approval as first-class concerns. citeturn28view0turn23view0turn22view4

```mermaid
classDiagram
    class Project
    class HandoffBundle
    class AgentIndex
    class HumanBriefing
    class UAIRecord
    class ContextRecord
    class ConstraintRecord
    class DecisionRecord
    class MemoryRecord
    class StackRecord
    class ArchitectureRecord
    class ProgressRecord
    class TestPlanRecord

Why This File Exists

This is a memory-system evidence file from uaix.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Knowledge Graphs for UAIX Project Handoff; Executive Summary; Foundations of Knowledge Graphs; Mapping UAIX Project Handoff Into a Graph; Ontology, Identifiers, Provenance, and Validation; Tooling, Databases, and Export Formats; Query Patterns, Workflows, and Implementation; Testing, Migration, and Roadmap. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-326 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Knowledge Graphs For UAIX Project Handoff",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-agent-file-handoff-retired-source-archive-2026-41d1594c/",
    "source_reference":  "raw/system-archives/uaix/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-06/Improvement/knowledge-graphs/Knowledge Graphs for UAIX Project Handoff.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:41d1594ce6ae7787201ac31eff4fab49635c6bc89868aeee3048719fe50955c4",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-06T14:51:59.9736194Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-326",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}