Two companion docs answering 'how does a host module drive the
Lore Engine correctly?'.
INTEGRATION.md — the practical guide. Audience: anyone who has
the engine and wants to wrap it. 12 sections: TL;DR (30-line
integration module), mental model, transports, 50-tool surface,
24 read tools + 12 write tools, template-generated tools, 7
integration rules, 6 failure modes, 4 metrics, adding a new
domain type, worked end-to-end example.
integration-module-contract.md — the formal, testable contract.
Audience: host-app authors. The 7 rules + their tests + their
failure modes. Versions with the system prompt (v1.0/v1.1/v1.2).
The host is 'good' when its 50-question harness run scores:
tool-selection accuracy >=80%, citation rate >=90%, hallucination
rate <5%, time-window violation rate <5%.
Per the slice 7 doc deliverable (slice 7 Track A, blocked on
the API key for the LLM execution half). These are the
hand-off artefacts for any future host module author.
Co-Authored-By: Claude <noreply@anthropic.com>
Brings the docs into sync with what shipped in
slice 6 (712→761 tests, 7 sub-slices):
- Setting↔Plane membership is encoded as a
``setting_id`` field on the Plane node, not as a
HAS_PLANE edge. The pure-Cypher pattern in the
design is the *intent*; the engine stores it
differently for the 1-to-many reverse-lookup.
Updated 01-ontology.md, 11-extensibility.md,
14-examples.md, 17-planes.md accordingly.
- EXISTS_IN (entity → Setting) is the timeless
type-assertion; time-bounded planar location is
LOCATED_IN_PLANE (entity → Plane) with valid_from
/valid_until. Updated the edge-type table, the
Cypher examples, and the migration story.
- 17-planes.md: clarified "EXISTS_IN is many-to-many
(setting level, not plane level)"; the legacy v1.1
EXISTS_IN (entity → plane) is folded into
LOCATED_IN_PLANE for the time-bounded case and
removed from the timeless one.
- ADR 0013 — the v1.2 plane-model migration story.
Documents the 7 locked decisions (Setting/Plane
first-class, setting_id field encoding, the
GraphBackend Protocol extensions, the read-tool
setting filter, the 4 plane-relation edge types,
the migration's idempotency), what was rejected
and why, and the consequences for the Neo4j
parity follow-up.
Co-Authored-By: Claude <noreply@anthropic.com>
Three doc fixes so the plan directory matches the shipped state:
* docs/plan/README.md — the slice index was stale (still listed
slices 1-7 as "planned"). Refresh the table to show what
actually shipped (1, 2, 3, 4, 5a-Neo4j, 5b-TypeTemplate,
2.6.1, 10, 11) and what remains (6, 7, 8). Drop the old
"33 days" cumulative estimate. Update the dependency graph
to reflect the shipped substrate.
* docs/plan/05-slice-neo4j-backend.md — missing Status header
(the only shipped slice plan without one). Add it.
* docs/plan/exec/ — three execution roadmaps so the next loop
picks up the remaining slices without re-deriving the
sub-slice decomposition:
- 06-planes.md (22 tests, 6 sub-slices, no blockers)
- 07-harness.md (12 tests Track A unblocked; Track B
gated on $OLLAMA_API_KEY)
- 08-polish.md (22 tests engine-side, blocked on 6+7)
Plus README.md indexing them.
Each exec file follows the slice 1 impl-plan template: scope,
what ships today, decisions locked, sub-slice ordering with
test names, critical files to read, acceptance check,
cross-references.
TaskCreate entries #26-29 mirror the four tasks.
Co-Authored-By: Claude <noreply@anthropic.com>
Slice 5 (TypeTemplate) shipped in 5 sub-slices on lore-engine-poc:
5T.1 data model + ingest, 5T.2 template parser, 5T.3 Cypher
allowlist, 5T.4 registry + dynamic tool generator, 5T.5 four
example templates + end-to-end killer demo. 632 -> 712 tests.
ADR 0012 records the design choices:
- :DomainEntity, :Relation, :TypeTemplate as Layer 2 backbone
on top of the existing GraphBackend Protocol (ADR 0011)
- the Cypher-with-allowlist as the safety boundary
- why startup-load + reload() over a file-watcher (no new
dependency, deterministic tests, operator-controlled)
- acknowledged risks: tool surface explosion (deferred
collapse-to-one-tool follow-up), in-memory matcher scope.
Plan doc updated to shipped status with cross-references.
Co-Authored-By: Claude <noreply@anthropic.com>
Adds the slice 5 plan doc mirroring the existing plan-doc
shape (sub-slices, decisions, files, risks, verification
commands) and ADR 0011 capturing the GraphBackend Protocol
+ dual-write model decisions made across slices 5.1-5.8.
* docs/plan/11-slice-mcp-http-docker.md: slice plan with AC + test
plan, mirroring the 11 existing plan docs.
* docs/adr/0010-streamable-http-transport.md: captures Streamable
HTTP vs legacy HTTP+SSE, Starlette vs FastAPI/mcp-lib, stateless
v1 (no Mcp-Session-Id), one-shot JSON as common case, append to
requirements vs split, baked graph + mount override.
* CONTEXT.md: new 'Transports' section under Operations documenting
the transport-agnostic dispatcher + stdio + Streamable HTTP.
- New plan: docs/plan/10-slice-write-tools-deferred.md
(4 sub-slices, 9 new write tools, +61 tests, 24→36 MCP tools)
- 2.6.1 doc: status updated to reflect post-slice-10 boundary;
deferred-tools list points to the new plan doc
Co-Authored-By: Claude <noreply@anthropic.com>
Documents the slice that exposed the 12 read_tools over the
MCP wire (commit 0b0a71f on lore-engine-poc-v3 main).
448/448 tests green; 24 tools total.
Cross-references the deferred slice-4 tools (state_at, cite,
summarize_chain, narrate_arc) and the 6 deferred write_tools
that remain out of MCP scope.
Why: keeps docs/plan/ accurate; lets a new agent know what
the MCP surface looks like today and what's still deferred.
How to apply: when picking the next slice, slice 5 (TypeTemplate)
and slice 6 (Planes) both require Cognee/Neo4j and stay
blocked on substrate rehydration; slice 7 (Reasoning Harness)
needs OLLAMA_API_KEY to exercise real LLM calls; slice 8
(Polish) is mostly UI/import/export work. The lowest-friction
next POC slice is **exposing the 6 deferred write_tools over
MCP** (mirrors slice 9.1: pure registration, no new logic).
- Add docs/how-it-works.html: self-contained explainer with inline SVG
diagrams, ELI5 tone. Covers the big idea, plain-AI vs Lore Engine,
the cast (Cognee/Neo4j/Minimax-M3/45 tools), question flow, why time
matters, disputed edges + confidence, how lore gets in, the
consistency safety net, and how it differs from a wiki.
- Soften the false-precise '36 labels' bucket arithmetic to honest
'roughly 36' across 00-overview, 11-extensibility, 10-critique
(sub-arithmetic didn't reconcile across docs).
Co-Authored-By: Claude <noreply@anthropic.com>
The executable mirror in prompts/system-prompt.md drifted from
07-reasoning-harness.md after the recall reframe. The skill mandates
the two stay in sync (drift caught by test_system_prompt_consistency
in slice 7). Mirror now matches: recall is the fallback because
un-typed/un-cited/un-time-bounded, not low-precision.
Co-Authored-By: Claude <noreply@anthropic.com>
Three findings from the Cognee-API review:
ADR 0009 (the big one): edges with time/confidence are reified
:Relation nodes, promoted v1.1 -> v1. Cognee's graph_model can't
carry valid_from/valid_until/confidence on a native edge (an edge
is a nested DataPoint field; the Edge object only has weight +
relationship_type). So any edge the time model, consistency engine,
disputed-edge machinery, and retcon policy operate on is a Relation
node. Structural edges (is_type, template-wiring) stay native.
Propagated: 11-extensibility (Relation now v1, +disputed/retcon
fields), 04-consistency (Category A + B Cypher match through Relation
nodes, materialize is_disputed/disputed_with), 00-overview count,
CONTEXT.md (+Relation term), slice 1/3/6 notes.
Finding 1: cognee.recall is not 'low-precision' — it returns scored
multi-source RecallResponse objects (incl cypher/triplet/temporal
kinds), session-aware. It's the fallback because results are
un-typed/un-cited/un-time-bounded, not low-precision. Reframed in
07-reasoning-harness + 05-mcp-tools.
Finding 3: 'register our 45 tools with Cognee's dispatch' was false.
Cognee ships cognee-mcp (a fixed 14-tool surface) — a reference
server, not a registry we extend. Lore Engine runs its own MCP
server (45 tools), calls Cognee's Python API in-process. Reframed
in 00-overview + 22-cognee-boundary.
Co-Authored-By: Claude <noreply@anthropic.com>
The earlier commit missed 8 spots that still presented the graph
backend as undecided (00-overview x2, 12-storage x2, 13-microservice
x2, 06-ingestion, plan/05). All now pinned to Neo4j per ADR 0008.
Co-Authored-By: Claude <noreply@anthropic.com>
Cognee's default graph DB is Kuzu (PR #1022, June 2025). We override
to Neo4j for battle-testedness + Java UDFs. The time model
(time_in_window/overlap, era tree, current token) now ships as a
Neo4j Java UDF — queryable inline in Cypher, the contract was_true_at
depends on. Kuzu has no Java UDF mechanism, so on Kuzu the time model
would have been app-layer Python called outside the query. The POC's
pure-Python port becomes the reference impl + test oracle.
Resolves the 'verify which backend' hedge that was never executed:
- 08-architecture.md: storage line, diagram, time-model impl, hosting
- 22-cognee-boundary.md: storage ownership
- CONTEXT.md: Cognee entry pinned to Neo4j
- 00-overview.md: ADR index
Post-cognify consistency hook (Q10 second half): Cognee exposes no
built-in hook. 04-consistency.md updated — live sweep runs as a final
Task in run_custom_pipeline (post-ingest, <100ms); nightly full sweep
runs as external cron. Both write the same :ConsistencyRun shape.
Co-Authored-By: Claude <noreply@anthropic.com>
Cognee exposes two ontology mechanisms:
- graph_model= (Pydantic DataPoint hierarchy) — a CONTRACT;
the LLM can only emit fields/labels that fit the declared
schema. Invalid extractions are structurally rejected.
- ontology_file_path= (RDF/OWL) — ENRICHMENT; tags matched
entities ontology_valid=True but does not constrain output.
We pick graph_model= so the slice-3 risk ('reject triples with
unknown labels') is enforced at the LLM layer, not post-filtered.
OWL is deferred — it's interop we don't need yet, and can be
layered on later as enrichment without displacing the contract.
Trade-off: adding a label is a code change (new DataPoint subclass),
not a YAML edit. That rigidity is the point for a typed-ontology
engine; TypeTemplate (slice 5) is the 'add types without code'
escape hatch layered on top.
Also fixed cognee-integration.md: replaced two fictional Cognee
APIs (extract_graph_from_data.set_prompt, register_dataset) with
the real surface — remember(custom_prompt=, graph_model=) for the
prose path and add_data_points() for the structured path. Added
the 'graph_model enforces shape not value' caveat pointing to the
consistency engine (slice 2) as the second gate.
Slice 3 AC 3.5a added: a 37th label is structurally rejected by
graph_model (proves ADR 0007 holds).
Co-Authored-By: Claude <noreply@anthropic.com>
Research into Cognee's actual API (docs.cognee.ai) confirmed the
docs made a load-bearing false claim: that the Lore Engine
'inherits and generalizes' a Contradiction node, get_contradictions
tool, 8 inherited MCP tools, and neo4j-init.cypher from the substrate.
Cognee ships NONE of that. Cognee provides DataPoint + custom graph
models + remember/recall + a Cypher/APOC graph-rule pattern. So:
- Slice 2 (consistency) is a from-scratch BUILD, not a generalization
- Categories A/B/D (Contradiction/Anachronism/Orphan) are ours
- Category C (declarative OntologyRule) rides Cognee's Cypher pattern
- '8 inherited tools' -> '8 base tools' (one wraps cognee.recall)
- '7 inherited labels' -> '7 base types' (Lore Engine originals on DataPoint)
Fixed across 04-consistency, 01-ontology, 05-mcp-tools, 00-overview,
09-roadmap, 15-related-work, 16-comparison. Historical GraphMCP
comparisons left intact.
Added CONTEXT.md (glossary) — the grill-with-docs skill mandates it
and 6 ADRs' worth of resolved terms (Lineage/Faction/Region/Plane/
LoreSource/extraction+source confidence/disputed edge/retcon/Setting/
ConsistencyRun/Cognee) had no single home. New readers no longer mine
ADR prose for the vocabulary.
Co-Authored-By: Claude <noreply@anthropic.com>
The 18 design docs were the engine spec. These 12 new files are
the operational layer that goes with it:
Design (docs/):
- 18-eval-policy.md thresholds + cadence (lifted from slice 7)
- 19-retcon-policy.md declare/preserve/surface retcons; codex syntax stub
- 20-multi-setting-policy settings.yaml; cross-setting queries
- 21-quickstart.md 1-page 'first 5 minutes'
- 22-cognee-boundary.md substrate vs domain contract
- cognee-integration.md recipe for prompt override + LiteLLM routing
Registries (docs/prompts/, docs/models/):
- prompts/README.md convention; system-prompt.md mirror, extraction-prompt.md stub
- models/README.md convention; minimax-m3.md primary notes
ADRs (docs/adr/):
- 0006-cognee-version-pin.md Cognee pinned at 1.1.2; harness is the upgrade gate
Index updates:
- 00-overview.md full doc set with categories
- 07-reasoning-harness.md link to prompt mirror
- 09-roadmap.md link to operational docs
Co-Authored-By: Claude <noreply@anthropic.com>
Harness now boots with OPENAI_BASE_URL pointed at minimax.io,
LLM_MODEL=openai/minimax-m3, thinking-mode=adaptive.
Cost risk downgraded: 50x3 + red-team is ~$5-10 at M3 pricing.
Test-overfitting mitigation: subset cross-checked on gpt-4o
and claude-sonnet-4-6 as a sanity check, not a parallel target.
Co-Authored-By: Claude <noreply@anthropic.com>
Minimax-M3 (released June 2026, OpenAI-compatible API at
api.minimax.io, 1M context, 428B-param MoE with 23B activated).
Cognee routes to it via LiteLLM with model id openai/minimax-m3.
Slice 3 (LLM extraction) and slice 7 (harness) updated to
reference M3 specifically:
- LiteLLM routing via OPENAI_BASE_URL
- M3's 1M context means the 45-tool catalog + system prompt
fit in one context
- Harness uses thinking mode 'adaptive'
- Cost risk downgraded (M3 is cheap enough that the 50x3
harness is ~$5-10, not a budget item)
- Cross-vendor sanity check (gpt-4o, claude-sonnet-4-6)
becomes a test-set-overfitting mitigation, not a parallel
target
Co-Authored-By: Claude <noreply@anthropic.com>
ADR 0004: a Region is geographic (inside a plane); a Plane is a
mode of existence (Material, Shadow, Voldramir). The v1.1 codex
conflates them under 'type: region'; the slice 6 migration fixes
this.
Migration rules:
- Entries with plane: true in frontmatter -> Plane node
- Entries under Campaign Codex - Planes/ -> Plane node
- All others -> Region node
- Migration is idempotent
- Default plane for an entity with no plane: -> Material Plane
Voldramir becomes a Plane node; its body-text [[Underdark]]
reference becomes a LAYER_OF edge. Added criteria 6.8-6.11.
Co-Authored-By: Claude <noreply@anthropic.com>
Templates declare named queries in a Cypher subset. The watcher
validates against an allowlist (MATCH/OPTIONAL MATCH/WHERE/
RETURN/ORDER BY/LIMIT/SKIP/count/coalesce); rejects with line
numbers on disallowed constructs (CREATE/MERGE/DELETE/SET/
CALL/UNION/WITH/arbitrary functions).
User input only reaches the Cypher body via $parameter
substitution, never via string interpolation. This is the
read-only Cypher dialect that template authors learn — powerful
enough for multi-hop traversal (the ci -> b OPTIONAL MATCH
example), constrained enough that no template can mutate state.
Added criteria 5.8-5.12 covering the allowlist rules.
Co-Authored-By: Claude <noreply@anthropic.com>
ADR 0003: a Lineage is a bloodline (descent from one founding
ancestor); a Faction is an association (House, Order, Guild).
A person can be in at most one Lineage but in many Factions
over their lifetime.
Slice 1 schema update:
- family_tree.yaml: header is now lineage: <id>, no House
name. Produces Lineage node + PARENT_OF/SPOUSE_OF/MEMBER_OF
edges. ADR 0002 dispute machinery catches conflicting
PARENT_OF claims from two YAMLs.
- factions.yaml: NEW. Produces Faction node + MEMBER_OF(Faction)
edges with reason: birth|marriage|adoption|swearing|other.
Cross-lineage marriages: a child is MEMBER_OF the lineage named
in the YAML header. The other parent's lineage is reachable
via PARENT_OF; no duplicate membership edge.
Added criteria 1.12-1.15 to slice 1.
Co-Authored-By: Claude <noreply@anthropic.com>
When a fact has multiple agreeing sources, aggregate_confidence =
min(extraction_confidence * source_confidence) across the per-source
products. The floor is the only formula that prevents a weak source
from being silently masked by a strong one — disagreement surfaces
as low confidence, which the slice-2 consistency engine will hook
into.
The dimensions themselves (extraction_confidence, source_confidence)
are tracked separately, never collapsed, so callers can ask 'is this
uncertain because we extracted it badly, or because the source is
unreliable?' — the two have different remedies.
Co-Authored-By: Claude <noreply@anthropic.com>
Two sources that produce the same (subject, relation, object)
with conflicting time bounds no longer get merged silently. The
edge merger now keeps them as separate Edge records, marks both
is_disputed=True, and links them via disputed_with. Slice 2's
consistency engine will turn this into a Contradiction node.
POC changes:
- Edge.is_disputed: bool (default False)
- Edge.disputed_with: list[Edge]
- _windows_consistent(a_from, a_until, b_from, b_until) helper
- was_true_at response now includes is_disputed +
disputed_with_sources fields
- tests/test_confidence.py: 5 new cases (11/11 pass)
The POC codex has no real disputes, so is_disputed is always
false in the demo output. The machinery is in place for slice
1, where family_tree.yaml can produce temporal disagreements
between two source files.
ADRs:
- 0001-aggregate-confidence-floor.md: aggregate is min of
per-source (extraction*source), not mean or max.
- 0002-disputed-edges-stay-separate.md: conflicting bounds
produce two edges, not one merged.
Co-Authored-By: Claude <noreply@anthropic.com>
Slice 0 acceptance criteria now distinguish three things the slice
proves (time filter, integration, dual-confidence). 5 new criteria
(0.11-0.15) verify the dual-confidence model in tests.
The model:
- extraction_confidence: did we extract this edge correctly?
Frontmatter = 1.0, body-text heuristic = 0.6.
- source_confidence: how reliable is the source document?
Lives on a LoreSource node as reliability
(canonical=1.0 | factional=0.75 | rumor=0.5 | dialogue=0.4
| fanon=0.3).
- aggregate confidence returned to callers = min(extraction * source)
across all sources on the edge.
Slice 1 picks up LoreSource as a first-class graph node and
SOURCED_FROM edges from every typed edge. Path-based reliability
inference (Quests/Random/ -> rumor) ships in slice 0; slice 1
adds YAML frontmatter override and the graph node itself.
Co-Authored-By: Claude <noreply@anthropic.com>
Slices the Lore Engine on Cognee roadmap into independently
shippable units. Each slice file has Goal, What's in the slice,
Acceptance criteria (table), Test plan (unit + integration +
adversarial where relevant), Risks, Out of scope, Cross-references.
- 00-slice-0-poc.md: POC slice (done) — substrate validation
- 01-slice-structured-yaml.md: family_tree / timeline / gazetteer
- 02-slice-consistency.md: 4-category rule system
- 03-slice-llm-extraction.md: custom extraction prompt for the 36
typed labels
- 04-slice-tools.md: remaining 44 tools to complete the 45-tool
surface
- 05-slice-typetemplate.md: polymorphic extension model
- 06-slice-planes.md: Setting + Plane graph nodes (v1.2)
- 07-slice-harness.md: 50-question validation gate
- 08-slice-polish.md: UI, export, enforcement
README.md indexes the slices with a dependency graph and a
cumulative effort estimate (MVP at end of slice 2, ~10 days;
full v1 at end of slice 4, ~21 days; v1+ext at end of slice 7,
~33 days).
Co-Authored-By: Claude <noreply@anthropic.com>
The /docs review surfaced two categories of work: real bugs and a
substrate decision. This commit lands both.
Pure fixes:
- Fix markdown table corruption in 01-ontology.md (3 `||` lines +
duplicate `### Magic, culture, language` header)
- Replace wrong tool/label/doc count claims with the real numbers:
30 -> 45 MCP tools, 14 -> 36 node labels, 14 -> 18 docs
- Resolve Phase 11 collision in 09-roadmap.md (v1.1 phases renumbered
to 4-7 in the unified plan; v1 Polish keeps its Phase 11)
- Propagate the v1.2 world_id -> Setting/Plane deprecation to the
v1.1 docs (11, 12, 14, 17): YAML world_id -> setting_id, Postgres
world table -> setting table, Cypher index renamed, migration
steps 6 + 7 added in 17-planes.md
Cognee substrate switch (the strategy change):
- 00-overview.md: substrate line now Cognee, not GraphMCP-Example
- 08-architecture.md: full system diagram, services layout, hosting,
and resource budget rewritten for Cognee as the substrate
- 11-extensibility.md: 4-layer diagram reframed (Cognee data-model
extension; template-watcher is a Cognee data-pipeline)
- 12-storage-strategy.md: 5 stores collapse to 3 layers; saga pattern
removed (Cognee handles cross-store transactions)
- 13-microservice-decomposition.md: full rewrite (Cognee is the
gateway; no monolith problem; 5+ Go services collapse to one
in-process Python extension)
- 14-examples.md: Example 6 added (full 8-step Cognee integration
walkthrough from "stand up Cognee" to "template-driven tool call")
- 15-related-work.md: Cognee reframed as substrate, not option
- 16-comparison.md: strategic section reframed (decision made, not
debate); the build order is now in 09-roadmap.md (Cognee-spike-first)
- 10-critique.md: S1.4, S1.5, S2.5, S2.6 status updated for Cognee
- 07-reasoning-harness.md: system prompt mentions Cognee + cognee.recall
fallback
- 06-ingestion.md: Path 1 (prose) via cognee.add/cognify; Path 2
(YAML) via Lore Engine parser; Go-worker section replaced
Build plan (09-roadmap.md): the v1+v1.1 work collapses from 43 days
on GraphMCP-Example to 33 days on Cognee. The MVP is end of Phase 3
(16 days): Cognee spike, typed ontology, time model, 45 MCP tools.
Phase 4-6 add the consistency engine, TypeTemplate polymorphic
extension, and reasoning-harness validation.
Co-Authored-By: Claude <noreply@anthropic.com>
Replaces the v1.1 'world_id is a string' model with a graph-of-planes. Driven by Kay's Q2 ('worlds are planes') and the v1.2 design review.
- 17-planes.md (NEW): the plane taxonomy, the four relation types, Cypher patterns, migration from world_id, open questions
- 01-ontology.md: Plane and Setting as first-class nodes; the 6 plane-relation edge types
- 02-time-model.md: plane-aware time (entity_planes_at_time as the 6th time-aware primitive)
- 08-architecture.md: data flow for plane questions (the 'can I get from X to Y' pattern)
- 11-extensibility.md: how to add custom planes and plane-relations without code
- 12-storage-strategy.md: planes are pure graph (no Postgres/Redis/Qdrant/S3 changes)
- 14-examples.md: example 5 — full Setting + planes + Roland + Asmodeus + LLM tool calls
- README.md: v1.2 entry + doc 17 in the table of contents
The POC rebuild (T10) is the next step: migrate the existing 4 world_id values to Setting/Plane nodes and update the plugin queries to use EXISTS_IN/LOCATED_IN.
Researched 9 systems in the KG-RAG + LLM-reasoning space, with actual
abstracts, GitHub stars, and arXiv citations:
- Microsoft GraphRAG (33,779 stars, arXiv 2404.16130) — global summarization
- Cognee (17,843 stars, arXiv 2505.24478) — agent memory, cognitive ontology
- LightRAG (36,622 stars, arXiv 2410.05779) — graph-based text indexing
- Stanford Generative Agents (arXiv 2304.03442) — memory stream + reflection
- IVIE (arXiv 2606.13348) — neuro-symbolic interactive-fiction generator
- WikiChat (arXiv 2305.14292) — Wikipedia-grounded, 97.3% factual
- TKG methods (TLogic, Chain of History, TGL-LLM) — temporal forecasting
- Chain-of-Knowledge (arXiv 2306.06427) — in-prompt structured reasoning
- Long Story Generation (arXiv 2508.03137) — KG for long-form narrative
Critical findings:
- The Lore Engine's 'closed-world fictional ontology' niche is not crowded.
No system does time-aware, contradiction-checking, source-attributed
reasoning over a fictional world. That's the opening.
- BUT: GraphRAG/Cognee/LightRAG are 18-37k-star production systems.
The Lore Engine is a design. Maturity gap is the single biggest weakness.
- The right move might be: build Lore Engine on top of Cognee, not
GraphMCP-Example. Cognee is MIT, production, has paying users, and
closes 80% of the substrate gap in 2 weeks of integration work.
- The most leveraged next move: 1-week spike to validate the core
idea before committing to the 43-day build.
16-comparison.md is the honest assessment. Where the Lore Engine is
Worse is a direct list of 10 weaknesses; where it's Better is a
direct list of 10 strengths. Six debatable design decisions called
out for Kay to push back on.
