Liminalisand where it actually stands
Built by working on a real corpus, not on a demo.
Liminalis started as a way to stop losing the thread in a long manuscript, and turned into the more general problem underneath: how do you make a body of documents behave like knowledge, and then prove that it worked?
Three phases, each one making the last one honest.
-
A workspace that knows its own corpus
Typed documents on disk, a background knowledge layer derived from them, and a grounded assistant over the top. The features people notice — the weave board, chronicles, validation — all sit on that foundation.
-
Then: prove the retrieval actually works
A hand-authored benchmark over a real project, an ablation ladder, and a willingness to delete features that measured as no better than nothing. This is where the interesting results are, including several that contradicted the assumptions the work started from.
-
Then: prove the engine isn't about fiction
The lens was factored into a real abstraction, and then tested by building a third one over ten thousand pieces of legislation. That's what turns “a writing app with two modes” into a platform claim you can defend in a technical conversation.
Eva Lothian is a system architect, with a doctorate focusing on integrative social science, and intrigued by the capabiliites of Artifical Intelligence. If you'd like to contact her, connect on LinkedIn: https://www.linkedin.com/in/lothian/ PLACEHOLDER: a short paragraph about you — background, why you built this, and what you're looking for. Two or three sentences is plenty.
The table nobody puts on a marketing site.
Every other page here describes what the system does. This one says how far each part has actually been proven. “Built and compiles” is not the same as “verified in live use”, and pretending otherwise is how technical credibility gets spent.
| State | What's in it |
|---|---|
| Live-verified | Documents, editor, tree, folder notes, split view, import · grounded chat and thinking levels · the full retrieval stack (hybrid recall, reranking, contextual embeddings, tiered context, context budget) · the background knowledge workers (extraction, summaries, motifs) · Reverse Index, Project Overview, Context Summary, Structure · reasoning control and the thinking box · context depth indicator · selective editing and draft proposals · the lens abstraction and lens-scoped retrieval · Campaign mode through live play, access control and reuse checks · the Legislation lens including corpus ingest, families, escalation and the insight charts · the agent API and MCP server, including cross-turn chat memory · the pipeline-graph engine and executor · auth, sharing, credits and billing · The Pacing Watcher — tested and works · Bluesky / AT Protocol login — tested and verified · Unified campaign-and-series generation — tested and verified · The desktop client — complete and working well |
|
Built & build-verified, not yet proven in real use |
Parts of the legislation lens that depend on model calls were build-verified only, because provider quota ran out during that phase. |
|
Built, then deliberately switched off |
On-demand context expansion — fired zero times across 41 queries under two different prompts. · A second, related retrieval escape hatch that was never observed firing at all. · Diversity reranking with adaptive result counts — measured as a no-op, and actively risky on narrative material. · An “amendment aggressiveness” metric in the legislation lens, deleted after its input distribution turned out to be a PDF-converter artifact. Optional retrieval features live behind configuration and all default to off. |
| Planned only | Legislation-specific validation. · The visual node-graph pipeline builder — it needs a library decision that hasn't been made. · Trigger kinds beyond document-triggered pipelines. · Cross-project world reuse — two candidate designs, neither chosen. · Additional lenses. · Chat auto-renaming. · No mobile client. |
Where a page elsewhere on this site describes something in the second or fourth row, it says so on that page too.
The things that are genuinely unresolved.
Multi-document synthesis quality is unmeasured, not bad
The bench can't currently price it well enough to make a claim either way. The first attempt to measure it turned out to be measuring the grader. That's an honest “we don't know”, not a hidden weakness — and it's the reason no synthesis number appears anywhere on this site as a product claim.
The cognitive layer has no number attached
The ACT-R activation model and the association graph it spreads over are, arguably, the most distinctive thing here — and they are the part the benchmark cannot price. A fixed-corpus, single-shot bench scores a cold graph, while the entire value of that layer is history-dependent. Building an evaluation that can actually observe a graph getting better as a project is worked in is open, unstarted work, and no performance claim is made for it in the meantime.
Two retrieval categories are measurably softer
Questions about long-range arcs, and questions that require stitching across documents, both score below the rest. Both are named rather than averaged away.
Scale, not lenses, was the real problem
Building a third lens over ten thousand documents generalized cleanly at the lens layer. What broke was code that had quietly assumed a few hundred documents. Those were fixed — but one index operation at that scale remains unmeasured, and it is logged as the open scale risk rather than assumed fine.
Some good features have never met a real user
The Pacing Watcher is the clearest case: a genuinely novel piece of autonomous steering that has never run at an actual table. Until it has, it's a design, not a result.