The graph is the brain

Most AI apps answer with vector search: embed the text, find the most similar passages, hand them to the model. That is good at “find text that looks like this,” but it is blind to the things you have said Kiduna is about — who owns a fact, who it is about, how it connects, and who may see it.

Your design is full of those statements: “all allies have the same context about Jeya,” “node types such as member, ally, and Duna,” knowledge that is “public, private, or secret.” Those are relationship and permission claims. A graph expresses them natively; a vector index cannot.

Everything in Kiduna is a node; every meaningful relationship is an edge. One model carries both the organization and its knowledge — so an Ally can reason across people, orgs, and facts in a single traversal.

It spans six layers — identity/wallet, the Ally and its skills, community & access, social & commerce, governance, and the knowledge content itself — all projected from your three databases, joined by wallet. The full node-and-edge catalog is in the appendix.

Each Ally is an NFT. At registration, Kiduna mints an NFT identity for the Ally into the owner’s wallet. In the graph that is one node — NFT — that links the Ally to the Wallet holding it. It delivers two things you called for: traceability (every action an Ally takes is attributable to a token on-chain — “if the ally has an address … we can trace”) and portable ownership (transfer the token, transfer the Ally).

When a user — or an Ally, on command — adds knowledge (an upload, a Google Doc/Drive connection, or a “research X and build me a knowledge base” instruction), it flows through one pipeline and lands in the graph:

Dropping Pinecone does not mean dropping similarity search. It moves into the same Postgres via pgvector, so vectors sit next to the graph. A single query can then filter by relationship, then rank by similarity — impossible when the vectors live in a separate system.

Every question runs the same loop. The step that makes the Ally understand the situation rather than just retrieve text is Traverse — walking the graph out from the passages it found.

This is the part to get exactly right. Your rule — “my ally also sees what Jeya says, but it won’t take instructions from Jeya — just context that it stores — and all allies have the same context about Jeya” — falls straight out of the graph: context is shared, authority is not.

Concretely, every knowledge base and chunk carries one of three scopes, and every read is checked against the Ally that is asking:

Four rules make those scopes actually hold — this is where permission is enforced, not merely described:

• Structural, not a filter. Scope is a SCOPED_TO edge. Every read is anchored to the caller and only walks edges they are allowed — an off-limits chunk is never traversed, not “fetched then hidden.”
• Enforced in the tool, not the prompt. An Ally’s reach is baked into its retrieval tool (a closure over the caller’s wallet and allowed knowledge bases). No chat message — however clever — can make an Ally widen its own access.
• Injection-safe. A user’s words only ever go to vector search; they never become part of a graph query. Only validated ids traverse the graph, so a crafted prompt cannot exfiltrate someone else’s data.
• Shared structure, isolated content. The relationships (who owns what, who belongs where) are shared so Allies can reason about the organization; the text of private and secret knowledge stays hard-isolated to its owner.

No big-bang cutover. Each phase leaves the system fully working, and Pinecone is only removed once pgvector matches it on recall.

• Scale of vector search. Pinecone is tuned for very large corpora; pgvector with an HNSW index comfortably covers Kiduna’s launch and growth horizon. If one corpus ever gets huge, we tune the index or shard — a good problem for later, not a launch concern.
• Migration effort. Real, but contained (embeddings already in Postgres; scaffolding present) and fully parallelizable behind a flag.
• Graph discipline. A shared brain needs a clean, permissioned model. That is a feature — it is what makes traceability and “shared context, private authority” enforceable rather than aspirational.

The graph is a projection of your three databases (joined by wallet), organized in six layers — about 27 node types and 46 edge types. Postgres stays the system of record; the graph is rebuildable from scratch.

The Wallet is the hub. The whole wallet section — balance, deposits, withdrawals, rewards, and history — anchors on the Wallet node.

Live today vs. planned. The structural, content and lineage layers are built; a few nodes are planned extensions that slot into the same model without changing it — OnchainAccount / OnchainTx (wallet accounts & on-chain history), Subscription (commerce), Conversation (agent), Post / Chat (social), Launch (governance), Visitor (identity).