Knowledge Graphs for UAIX Project Handoff

Full report

On this page

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This comparison synthesizes W3C RDF, RDFS, OWL, SHACL, and SPARQL documents together with Neo4j’s property-graph documentation and openCypher’s positioning toward GQL.

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.

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.

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.

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
    class OperationsRecord
    class StyleRecord
    class Artifact
    class Check
    class WorkItem
    class AgentRun

    Project --> HandoffBundle : hasBundle
    HandoffBundle --> AgentIndex : indexedBy
    HandoffBundle --> HumanBriefing : briefsHumans
    HandoffBundle --> UAIRecord : contains
    UAIRecord <|-- ContextRecord
    UAIRecord <|-- ConstraintRecord
    UAIRecord <|-- DecisionRecord
    UAIRecord <|-- MemoryRecord
    UAIRecord <|-- StackRecord
    UAIRecord <|-- ArchitectureRecord
    UAIRecord <|-- ProgressRecord
    UAIRecord <|-- TestPlanRecord
    UAIRecord <|-- OperationsRecord
    UAIRecord <|-- StyleRecord

    AgentIndex --> UAIRecord : references
    ConstraintRecord --> Artifact : appliesTo
    DecisionRecord --> Artifact : affects
    TestPlanRecord --> Check : requires
    ProgressRecord --> WorkItem : tracks
    AgentRun --> HandoffBundle : loads
    AgentRun --> Check : executes
    AgentRun --> UAIRecord : updates

The following mapping is the smallest useful proposal that remains faithful to the current UAIX spec and starter bundle examples. It is intentionally conservative: it preserves the current public authoring pattern and adds graph structure only where UAIX already exposes strongly typed meaning.

Ontology, Identifiers, Provenance, and Validation

The first UAIX ontology should be minimal, document-centered, and operationally useful. Because the current public Project Handoff pattern is a draft bundle format rather than a formal semantic-web specification, the ontology should stay close to the file roles and workflow roles that UAIX already publishes. That argues for a small custom UAIX namespace for handoff semantics, combined with PROV-O for provenance and standard RDF and OWL infrastructure for typing and validation. It does not argue for a large domain ontology on day one.

A sensible minimal ontology looks like this:

For OWL usage, the disciplined choice is to stay lightweight. W3C’s OWL overview identifies the OWL 2 RL profile as particularly suitable where relatively lightweight ontologies operate directly on RDF triples with rule-based implementations. That is an excellent fit for a first UAIX graph because the first production need is not deep theorem proving; it is consistent validation, queryability, and limited derivation over decisions, constraints, checks, and ownership. In other words, RDFS + selective OWL 2 RL axioms is the right ambition level. Full OWL DL expressivity would add complexity long before it adds value.

The identifier strategy is one of the most consequential design choices. W3C’s RDF and Data on the Web guidance support using stable URIs for resources and warn against local-only identifiers for durable references. W3C also notes that blank-node identifiers are locally scoped to a file or RDF store and are not persistent or portable identifiers. For UAIX, that leads to a clear rule: give every durable record and every extracted entity a stable HTTP URI, use immutable snapshot URIs for versioned exports, and reserve blank nodes only for transient internal structures that will never be externally referenced.

A concrete URI strategy can be very simple. Use one stable URI for the enduring project, one stable URI per enduring entity, and one immutable URI per bundle snapshot. For example, .../project/{slug} for the project, .../artifact/{normalized-path} for files or routes, .../decision/{slug} for enduring decision identities, and .../bundle/{date-or-release-or-commit} for a snapshot. Use hashes, bytes, commit IDs, or bundle manifest values as properties, not as the only identifier, unless you consciously want content-addressed semantics. UAIX starter bundles already expose file bytes, template origins, and sha256 checksums, which makes them ideal provenance properties.

A good RDF storage pattern is to use named graphs. W3C defines RDF datasets as a default graph plus zero or more named graphs. For UAIX, one named graph per bundle or per file is usually enough. That gives you clean isolation for hot context versus cold memory, internal versus external exports, or release-evidence versus draft context. It also aligns well with Project Handoff’s own “Hot Context, Cold Memory” guidance and its trust-boundary model.

For provenance, PROV-O fits naturally. Model every handoff file and every semantic export as a prov:Entity; model agent runs, validation jobs, release packaging, or approval workflows as prov:Activity; and model humans, AI agents, CI systems, or vendor runtimes as prov:Agent. That lets you answer questions such as “which decision was updated by which run,” “which export was derived from which file,” and “what evidence backs this public claim.” Because PROV-O was designed precisely to represent and interchange provenance information across systems and domains, it is much better to reuse it than to invent custom provenance semantics in a UAIX-specific ontology.

For access control, there are two layers. The graph should carry access metadata, but the storage or application layer should enforce it. The AGENTS spec already proposes accessControl fields such as readRoles and writeDIDs, and readme.human plus memory.uai emphasize trust boundaries and the requirement that external handoffs be sanitized and approved before sharing. If you later need portable policy interchange, W3C’s ODRL can express permissions, prohibitions, and obligations; but for the first implementation, it is enough to store access metadata in the graph and enforce it in the API, ingest pipeline, or chosen database platform.

Validation should be layered, not replaced. UAIX already publishes JSON Schemas for UAI-1 records and the AGENTS spec explicitly recommends JSON Schema validation for .uai files. Keep that authoring-time validation. Then add a JSON-LD context and validate the resulting RDF view with SHACL. Jena supports SHACL validation and RDF4J includes a SHACL engine integrated with transactions. This gives UAIX a clean split between syntactic authoring correctness and semantic graph correctness.

Tooling, Databases, and Export Formats

The practical tooling landscape divides into four layers: authoring and conversion, RDF storage and validation, property-graph storage and visualization, and synchronization or API delivery. Apache Jena covers RDF APIs, SPARQL, Fuseki, I/O, and SHACL; Eclipse RDF4J provides scalable RDF parsing, storage, querying, reasoning, SHACL validation, server endpoints, and a web-based Workbench. JSON-LD is well supported in JavaScript by jsonld.js and in Python by PyLD, while RDFLib is a strong Python-native bridge for parsing and serializing RDF. For Neo4j interoperability, the official neosemantics plugin exists specifically to bridge RDF vocabularies and SHACL-style validation into Neo4j.

A concise comparison of database options is below.

This comparison synthesizes the official Neo4j property-graph and Cypher docs, Neo4j Bloom and neosemantics docs, JanusGraph documentation, Amazon Neptune documentation, and Blazegraph’s site plus the archived public repository status.

For export formats, the choice should be deliberate rather than ideological.

The first three formats are defined by W3C specifications, while the last is best understood as an application-defined projection format rather than a universal interchange standard.

The most important architectural decision is what counts as the canonical semantic representation.

This tradeoff analysis follows directly from UAIX’s current positioning of Project Handoff as portable file-based source material and from the fact that JSON-LD, Turtle, SPARQL, Cypher, and RDF interop tooling are all mature enough to support a projection-based design.

If the goal is a pragmatic stack with no hosting, scale, or language constraints, the strongest reference architecture is: author in UAIX files; validate with JSON Schema; emit JSON-LD; derive Turtle; validate with SHACL using Jena or RDF4J; publish via Fuseki, RDF4J Server, or Neptune SPARQL; optionally project the same graph into Neo4j for Cypher and Bloom-based exploration; and keep the write path flowing back into canonical handoff files. Jena’s riot tool can already parse, validate, and convert RDF serializations, and RDF4J’s Rio can parse and write RDF documents or feed repositories directly.

Query Patterns, Workflows, and Implementation

UAIX’s own onboarding and verification guidance points directly to the most valuable graph queries. The Project Handoff page tells the next AI to read AGENTS.md, readme.human, and every loaded context file; to confirm hard constraints; to name the files or routes it expects to touch; and to name the targeted checks it expects to run. The verification plan section says every handoff should spell out what checks to run, what is out of scope, and what evidence must be reported. Those instructions translate almost one-for-one into graph queries about navigation, impact, constraints, checks, evidence, and trust boundaries.

In practice, the most useful common query patterns are these: find all records the next agent must load before touching a given artifact; find all constraints and approval gates that apply to a route, package, or file; find all decisions that affect a subsystem and what would cause reversal; find which checks must run for a proposed change; find which claims lack validator or release evidence; and find what part of the handoff may be shared externally versus what must remain internal or sanitized. Each of these patterns maps naturally to both SPARQL and Cypher.

A representative SPARQL query for a common UAIX task is: given an artifact, which active constraints and accepted decisions apply to it, and where did they come from? SPARQL is the right language for this kind of standards-based auditability because it is designed to query RDF graph content and integrates cleanly with named graphs, provenance, and SHACL-validated RDF data.

PREFIX uaix: <https://kg.example.org/uaix#>
PREFIX prov: <http://www.w3.org/ns/prov#>

SELECT ?artifact ?constraint ?constraintText ?decision ?decisionText ?source
WHERE {
  BIND(<https://kg.example.org/repo/artifact/src/payments.py> AS ?artifact)

  OPTIONAL {
    ?constraint a uaix:Constraint ;
                uaix:appliesTo ?artifact ;
                uaix:text ?constraintText ;
                prov:wasDerivedFrom ?source .
  }

  OPTIONAL {
    ?decision a uaix:Decision ;
              uaix:affects ?artifact ;
              uaix:text ?decisionText ;
              prov:wasDerivedFrom ?source .
  }
}
ORDER BY ?constraint ?decision

A representative Cypher query for the same operational problem is below. Cypher is particularly strong when teams want fast impact analysis or graph exploration in tools built around property-graph workflows. If you run this on Neptune rather than Neo4j, account for Neptune’s documented openCypher compatibility differences.

MATCH (a:Artifact {uri: $artifactUri})
OPTIONAL MATCH (c:Constraint)-[:APPLIES_TO]->(a)
OPTIONAL MATCH (d:Decision)-[:AFFECTS]->(a)
OPTIONAL MATCH (c)<-[:DERIVED_FROM]-(cf:DocumentArtifact)
OPTIONAL MATCH (d)<-[:DERIVED_FROM]-(df:DocumentArtifact)
RETURN a.path AS artifact,
       collect(DISTINCT {
         id: c.id,
         text: c.text,
         severity: c.severity,
         source: cf.path
       }) AS constraints,
       collect(DISTINCT {
         id: d.id,
         text: d.text,
         status: d.status,
         source: df.path
       }) AS decisions;

The end-to-end workflow should be explicit and automated. Project Handoff already publishes the basic lifecycle as “Project Handoff files -> agent runtime -> traces, checks, PRs -> updated Project Handoff files.” A graph layer should sit between those stages as a projection and query substrate, not as a replacement for the source files. On the RDF side, Fuseki and RDF4J Server are natural query endpoints; on the property-graph side, Neo4j plus Bloom is the cleanest operational experience.

flowchart LR
    A[UAIX source files<br/>AGENTS.md<br/>readme.human<br/>.uai/*] --> B[Parse and normalize]
    B --> C[Validate source files<br/>UAIX JSON Schema]
    C --> D[Assign stable URIs<br/>and provenance]
    D --> E[Emit JSON-LD]
    E --> F[Emit Turtle]
    E --> G[Project to property-graph JSON or CSV]
    F --> H[SPARQL endpoint<br/>Fuseki RDF4J Neptune]
    G --> I[Property graph store<br/>Neo4j JanusGraph Neptune]
    H --> J[SPARQL queries<br/>SHACL validation]
    I --> K[Cypher exploration<br/>Bloom dashboards]
    J --> L[Accepted updates]
    K --> L
    L --> A

A small Python example can carry most of the transformation work. RDFLib is a pure Python package for working with RDF and can parse or serialize RDF in multiple syntaxes. In a UAIX pipeline, Python is often the fastest way to parse front matter, mint URIs, emit triples, and then serialize both Turtle and JSON-LD.

from pathlib import Path
import hashlib
import yaml

from rdflib import Graph, Namespace, URIRef, Literal
from rdflib.namespace import RDF, XSD

UAIX = Namespace("https://kg.example.org/uaix#")
PROV = Namespace("http://www.w3.org/ns/prov#")

def parse_uai(path: str):
    text = Path(path).read_text(encoding="utf-8")
    parts = text.split("---", 2)
    if len(parts) < 3:
        raise ValueError(f"{path} is missing YAML front matter")
    _, front_matter, body = parts
    meta = yaml.safe_load(front_matter) or {}
    return meta, body.strip()

def file_uri(repo_base: str, rel_path: str) -> URIRef:
    normalized = rel_path.strip("/").replace("/", "%2F")
    return URIRef(f"{repo_base}/file/{normalized}")

def add_document(g: Graph, repo_base: str, rel_path: str):
    meta, body = parse_uai(rel_path)
    node = file_uri(repo_base, rel_path)

    g.add((node, RDF.type, UAIX.DocumentArtifact))
    g.add((node, UAIX.path, Literal(rel_path)))
    g.add((node, UAIX.recordType, Literal(meta.get("type", "unknown"))))
    g.add((node, UAIX.status, Literal(meta.get("status", "draft"))))
    g.add((node, UAIX.uaiVersion, Literal(meta.get("uai", "1.0"))))
    g.add((node, UAIX.bodyText, Literal(body)))

    sha256 = hashlib.sha256(Path(rel_path).read_bytes()).hexdigest()
    g.add((node, UAIX.sha256, Literal(sha256)))

    # Example extraction rule:
    if meta.get("type") == "constraints":
        for i, line in enumerate(body.splitlines()):
            line = line.strip()
            if line.startswith("- "):
                c = URIRef(f"{repo_base}/constraint/{Path(rel_path).stem}-{i}")
                g.add((c, RDF.type, UAIX.Constraint))
                g.add((c, UAIX.text, Literal(line[2:])))
                g.add((c, PROV.wasDerivedFrom, node))

    return node

g = Graph()
g.bind("uaix", UAIX)
g.bind("prov", PROV)

repo_base = "https://kg.example.org/my-project"
for rel_path in [
    ".uai/context.uai",
    ".uai/constraints.uai",
    ".uai/decisions.uai",
    ".uai/test-plan.uai",
]:
    add_document(g, repo_base, rel_path)

g.serialize("handoff.ttl", format="turtle")
g.serialize("handoff.jsonld", format="json-ld", indent=2)

A small JavaScript example is useful when the canonical semantic export is JSON-LD. The jsonld.js library is an implementation of the JSON-LD specification in JavaScript, so it is a good fit for Node-based build steps or browser-side tooling.

import jsonld from "jsonld";

const context = {
  uaix: "https://kg.example.org/uaix#",
  prov: "http://www.w3.org/ns/prov#",
  id: "@id",
  type: "@type",
  path: "uaix:path",
  recordType: "uaix:recordType",
  references: { "@id": "uaix:references", "@type": "@id" }
};

const doc = {
  "@context": context,
  id: "https://kg.example.org/my-project/file/.uai%2Fconstraints.uai",
  type: "uaix:DocumentArtifact",
  path: ".uai/constraints.uai",
  recordType: "constraints",
  references: [
    "https://kg.example.org/my-project/file/.uai%2Fcontext.uai"
  ]
};

const expanded = await jsonld.expand(doc);
const compacted = await jsonld.compact(expanded, context);
console.log(JSON.stringify(compacted, null, 2));

Testing, Migration, and Roadmap

Testing a UAIX knowledge graph should reflect UAIX’s own review model. The Project Handoff spec says a handoff must spell out what checks to run, what is out of scope, and what evidence must be reported; it also says agents should stop guessing, skipping, or pretending. In graph terms, that means the quality bar is not just “the graph loaded successfully.” The quality bar is that the graph supports evidence-backed decision-making and preserves the review semantics already present in the handoff files.

A useful validation stack has four tiers. First, validate source .uai files with the existing UAIX JSON Schema discipline. Second, validate JSON-LD compaction and expansion so the export is deterministic. Third, validate the RDF graph with SHACL. Fourth, run golden queries—SPARQL and Cypher queries with expected result sets—so you know operational questions still resolve correctly after mapping changes. Jena and RDF4J both support the SHACL and RDF-processing pieces of this stack.

The right metrics are mostly governance metrics, not vanity metrics. The most valuable scorecard is: source-schema pass rate; SHACL pass rate; percent of durable entities with stable URIs; percent of graph statements with provenance back to a source file; round-trip fidelity from source to JSON-LD to store and back to query results; query-regression pass rate for standard handoff questions; and hot-context size or density, so the graph does not accidentally turn cold memory into default startup context. That last metric matters because Project Handoff explicitly separates hot context from cold memory and tells teams to keep active files concise.

The migration should be phased and deliverable-driven.

This roadmap matches the current public UAIX support boundary, which says the visible starter ZIP is current and generated from canonical templates and manifests, but hosted .uai validation/import tooling, automatic repository writes, sync tooling, SDKs, and endorsements remain planned rather than fully public today.

The main implementation risks are predictable. The first is ontology bloat: trying to model everything before the handoff graph is useful for a handful of real queries. The second is identifier churn: changing URIs or deriving them from unstable paths or transient labels. The third is projection drift: letting the Neo4j graph, SPARQL graph, and source files tell different stories. The fourth is governance leakage: exporting internal-only or sensitive context into graphs meant for wider sharing. The fifth is platform-specific query assumptions, especially if Cypher written for Neo4j is later expected to run unchanged on Neptune openCypher. These are manageable if the source of truth remains the UAIX files and every projection is testable and derived.

The final recommendation is therefore clear. Build the UAIX knowledge graph as a standards-based semantic projection of Project Handoff, not as a replacement for Project Handoff. Keep the canonical handoff authored in AGENTS.md, readme.human, and typed .uai files. Add stable HTTP URIs, JSON-LD export, Turtle output, PROV-O provenance, SHACL validation, and named-graph separation for trust boundaries and bundle versions. Then add an optional property-graph projection where Cypher, visualization, or operational graph apps are genuinely valuable. That approach is analytically rigorous, operationally practical, and tightly aligned with what UAIX already publishes today.