Support for Typed Edge?

[ChristopherA]

I'm maintaining a plain-markdown knowledge graph using author-declared edges with explicit predicate syntax:

- is_a::[[Pattern Form]]
- has_form_contract::[[Pattern Form]]
- in_knowledge_domain::[[Agentic Architecture]]
- derived_from::[[Source Document]]
- contradicts::[[Opposing View]]

These edges are first-class content — written into the file, versioned with it, auditable with rg.

I see that Thoth ships ~67 predicates in its graph model. As I understand it, those are system-inferred (semantic extraction at ingest/query time). Declared and inferred are different primitives:

• Declared encodes what the author committed to at writing time. Persists through re-indexing, survives model changes, and uses the author's own vocabulary (sovereign per-collection).
• Inferred encodes what the system extracted. Valuable for surfacing relationships the author missed, but re-computed and drawn from a fixed vocabulary.

I'm looking for graph tools that:

1. Treat author-declared predicates as authoritative — don't normalize them into the system's vocabulary
2. Layer inferred predicates on top as enrichment, with provenance preserved on each edge (author-asserted vs. system-inferred)
3. Let me query across both, distinguishing the two

I'd also be glad to discuss this further.

[ChristopherA]

Complete details on how I current use named edges is at https://gist.github.com/ChristopherA/151aefa6a6bde1ce4fa6b1182656cebe

[siddsachar]

Thanks for sharing that reference guide. I've read through it carefully. The declared-vs-inferred distinction you're making, and the naming sovereignty argument behind it, are both well-articulated and something we've been thinking about in concrete implementation terms.

Here's how Thoth's graph works today and what we're building:

Current state:
Thoth ships 67 typed directional relation types with 49 aliases that normalize LLM-produced variants to canonical forms. All edges today are system-inferred, created by background extraction (every ~2 hours from conversations), document ingestion (map-reduce pipeline), or a dream cycle (nightly co-occurrence inference at ≥0.80 confidence). Every relation has a source field (live, extraction, document:filename) for traceability, but there's no distinction between "the author asserted this" and "the system extracted this" as different provenance classes.

Relations pass through a normalization layer that lowercases, strips prefixes, and maps aliases to canonical forms. A custom predicate like in_knowledge_domain would technically survive (unknown types are accepted with a warning), but nothing treats it as authoritative, nothing protects it from being overwritten on re-extraction, and nothing signals to the retrieval system that it carries author commitment.

The Obsidian-compatible wiki vault exports entities as markdown with [[wikilinks]] and a ## Connections section, but vault sync only reads back subject/description/tags, not edges.

What we're adding: Pinned Relations

Rather than building around a specific syntax, we're introducing a general primitive: pinned edges. One new flag on every relation. Pinned means "a human committed to this." Unpinned means "the system inferred this."

This maps directly to your declared-vs-inferred distinction:

Pinned edges bypass normalization. Your custom predicates (in_knowledge_domain, has_form_contract, conforms_to, grounded_in, whatever your collection uses) are stored verbatim. No forced mapping into our 67-type vocabulary. This is your naming sovereignty principle in practice: the system acts as translator, not extractor.
Pinned edges are protected. Re-extraction, dream cycle inference, model changes: none of these touch pinned edges. They survive re-indexing by design. This is what you described as "persists through re-indexing, survives model changes."
Both coexist with clear provenance. Inferred edges layer on top as enrichment. Every query can filter on pinned/unpinned or return both. The UI marks pinned edges with 📌, and the graph visualization colors them differently (gold vs. grey). This is your "layer inferred predicates on top with provenance preserved on each edge."
Retrieval is aware. When the system does auto-recall (injecting relevant knowledge into context before every LLM call), neighbors reached via pinned edges get a slight scoring boost over inferred neighbors. The LLM context also marks pinned relations with 📌 so the model knows which connections are user-asserted vs. system-extracted. In your terms, predicate-first reading: the model can weigh author-committed edges more heavily than system guesses.
Vault round-trips. Pinned edges export with a marker, and edits in Obsidian sync back with pinned status preserved.
The UI already has a full relation editor (add/delete/search by target, relation type dropdown, direction picker). We're extending it with a pin toggle on every edge and a free-text predicate input for pinned relations, so you're not locked into our dropdown vocabulary. If a user takes the time to manually add a relation in the UI, it defaults to pinned.

What we're covering vs. what's out of scope for this release:

Your reference guide describes a full architecture: annotated predicates with inline rationale, compound nodes (folders as graph participants), construction predicates as temporary scaffolding, ghost links, external wiki links with ↗ markers, and progressive disclosure for agent traversal. Those are all interesting directions, but the pinned relations primitive is the foundational piece. It establishes the declared-vs-inferred distinction at the storage and retrieval layer. Richer conventions on top (annotations, construction predicates, compound node support) become possible once that foundation exists.

We're also not building a predicate::[[Target]] parser into core. Your plain-markdown convention is a deliberate architectural choice about where edges live (in file bodies, not databases), and we respect that. The pinned relations feature works through the UI and vault sync, which means users who maintain edges in Obsidian can add them there and have them sync back as pinned. Users who prefer the UI can pin edges directly. Both paths produce the same result in the graph.

What we're deliberately not doing:

No vocabulary management or enforcement. Custom predicates pass through for pinned edges without needing registration. Your folksonomy-to-curated-vocabulary approach is your own curation discipline; we don't impose one.
No conflict resolution between pinned and inferred edges on the same entity pair. They coexist. If the system infers friend_of(A, B) and you pin colleague_of(A, B), both stay. This matches your principle that multiple vocabularies should coexist rather than converge.

I'll keep this issue open and will close it once the feature ships, so you'll be notified and can test it. Happy to discuss further, especially around how vault sync should handle your edge conventions in practice.