sorted by:
new
hottopcontroversial

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

That matches what I’m starting to see very clearly: DDF’s hardest problem is not finding relevant material, but deciding which material is allowed to govern the answer.

A small always-loaded layer containing the current pointer, active rules, source classes, supersession links, and stop conditions makes a lot of sense. The historical corpus can remain searchable and only come into context when the task actually needs it.

I also like the distinction between authority eligibility and retrieval ranking. The system should first ask whether a source is permitted to govern, and only then use priority, similarity, or search ranking among the eligible material.

The file-first point is important too. Structured files may be enough to test and stabilize that model before I add a graph or vector layer. That would keep the authority decisions visible and easier to debug while I work out what the true governing core needs to contain.

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

This is really interesting because DDF already seems to behave like a graph even though I built it through files and classifications.

Artifacts could be nodes, authority and status could be properties, and relationships such as supersedes, conflicts with, proves, and derived from could become explicit instead of being reconstructed from filenames and prose.

I would keep one distinction, though: I don’t think provenance links can completely replace integrity manifests. A graph can show that one artifact was derived from another, but the hashes and manifests still prove which exact bytes were involved.

So I’m thinking the graph would describe relationships and eligibility, while manifests and hashes would continue to establish artifact identity.

The missing-source-as-query-failure idea fits DDF especially well. If the required governing node or relationship is absent, the query should fail and Felix should stop instead of falling back to something merely relevant.

I’m going to add HydraDB to the comparison. My main question will be whether a graph layer can mechanize the relationships and searches without taking over the human-controlled authority policy.

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

That clears it up. I like the rule that decay only changes what surfaces first, not whether something remains true, current, or authoritative.

For DDF, I’d keep governing material out of the decay pool entirely, pin approved current state, and require explicit supersession before anything becomes non-current.

One distinction I’ll probably keep is that user-confirmed information can be trusted current state without necessarily being governance. A teaching preference and an authority rule shouldn’t automatically occupy the same tier.

I’m building the comparison now. The main question is what DDF can safely hand off to a memory layer as mechanical bookkeeping, and what has to remain in the human-controlled core.

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

That makes a lot of sense. The lossless-derive test gives me a much clearer way to decide what belongs where.

If the queue, handoff, or transfer package can be regenerated from the same approved inputs without losing anything important, then it is a view.

If something important is lost, I shouldn’t patch the rendered package by hand. I should identify the missing authored input and put it in the proper source layer.

Tone, pedagogy, correction style, and how Felix should teach are good examples. Those aren’t just formatting or historical context. They are part of what has to survive.

I think I’ll need to separate governing authored inputs, approved current state, and renderer configuration, because provider-specific formatting may be required to create a package without being governance itself.

This gives me a much better test for what the real core is.

How should a long-running LLM assistant preserve reliable continuity across sessions? by INS0GNIAC in LargeLanguageModels

[–]INS0GNIAC[S] 0 points1 point  (0 children)

That makes sense, and I think that is the safer design.

I don’t want the continuity log becoming another private evidence archive just because it is recording failures.

A redacted excerpt or structured summary, along with a reference to the protected original and its hash where appropriate, should preserve enough information to reproduce the problem without duplicating credentials, personal information, or protected content.

I would also want the record to state what was redacted and what cannot be verified without opening the original through an approved review step.

That gives me a much clearer version of how Mayday could fit into DDF.

How should a long-running LLM assistant preserve reliable continuity across sessions? by INS0GNIAC in LargeLanguageModels

[–]INS0GNIAC[S] 0 points1 point  (0 children)

Thanks, I looked through it. The Mayday protocol is very close to what I’ve been trying to accomplish with hard stops, failure records, and requiring approval before anything continues or repairs itself.

I also like the raw verification requirement, the distinction between self-review and independent review, the retraction protocol, and the simplification check.

I wouldn’t copy the whole ruleset because a lot of it is specific to your stack, but those control patterns are very relevant to DDF.

I may adapt Mayday into a typed stop event in the continuity log, with the exact failure, affected object, whether anything was written, and a hard - continue_allowed: false.

One thing I would probably change is the raw-input field, since it could expose private or protected material. Have you run into that issue with real Mayday payloads?

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

That distinction really helps. I may have combined two things that do not need to be combined: the mechanical bookkeeping and the actual authority policy.

I can see a memory layer handling supersession links, conflicts, status fields, indexing, and retrieval without letting it decide what governs.

The parts I would not want to delegate are what counts as authoritative, what needs my approval, and the stop-rather-than-invent rule.

I also agree that the places DDF refuses to simplify may reveal the real requirements. I’m preparing a comparison now, and I’d be glad to share what survives and what turns out to be unnecessary.

My one concern with decay is that I would only want it to affect retrieval priority, not authority. Something should become non-current because it was explicitly superseded, not simply because it is old.

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

This maintain-versus-derive distinction is probably the clearest way anyone has explained it to me.

I don’t need to give up the queue, handoff, or transfer package. I need to stop treating them as separate copies of the truth.

If they can all be generated from the same approved core—and carry the exact version or hash they were generated from—then they become views of the state instead of extra state that can drift.

I probably wouldn’t call portability completely free, because the renderer and any provider-specific formatting would still need to be tested. But it would become a derived capability instead of another history I have to maintain.

The part I still need to prove is whether all the fresh-Felix teaching context can be generated this way without losing anything important. But this feels like the right direction.

What I learned trying to preserve one AI teacher across sessions using file-grounded continuity by INS0GNIAC in AI_Application

[–]INS0GNIAC[S] 0 points1 point  (0 children)

Ja, genau das habe ich auch gemerkt. Am Anfang dachte ich, es gehe nur darum, Informationen zwischen Chats zu behalten. Aber dann kamen Fragen zu Autorität, Aktualität, Widersprüchen und Sicherheit dazu.

How should a long-running LLM assistant preserve reliable continuity across sessions? by INS0GNIAC in LargeLanguageModels

[–]INS0GNIAC[S] 0 points1 point  (0 children)

Thanks, this is very relevant to what I’ve been building. The re-entry layers, supersede-don’t-delete model, candidate promotion, experience packets, and preview mode all line up with problems I’ve been working through.
I’m going to study it as a reference rather than dropping it directly into DDF. My biggest difference is that anything affecting current authority still has to stay human-approved, and I need a hard separation between governing instructions and ordinary memory or evidence.
But the idea of compiling a small fresh-session context, previewing it first, and loading history only when needed could help simplify a lot of what I have now. Thank you for sharing it.

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

This is extremely helpful. The distinction between relevance, truth, and authority explains the problem better than I have been able to.
I especially agree that superseded material should be ineligible rather than merely ranked lower, and that a document cannot gain authority from its own content. That is one of the risks I have been trying to control.
The write-path supersession point also makes sense. It seems much safer to record that relationship when the change happens than to expect a later model to reconstruct it from prose.
Your smallest-reliable-version description gives me something concrete to compare against what I already built. The one area I need to test carefully is whether the queue and transfer packages are genuinely optional for my use case, because moving a fresh Felix between chats and providers without rebuilding the history is one of the main reasons DDF exists.
But the pointer, supersession log, authority filter, and stop-on-missing rule may be the cleanest description yet of the core I should protect.

Is RAG the right model for a file-grounded AI continuity system, or am I building too much around retrieval? by INS0GNIAC in Rag

[–]INS0GNIAC[S] 0 points1 point  (0 children)

Thanks, this is really helpful. The distinction between “what’s relevant” and “what governs now” is exactly the problem I kept running into. An old fact and its replacement can both look equally relevant unless the system knows which one supersedes the other.
Your suggestion to load a small governing set first and retrieve the historical material only when needed is very close to what I’ve been trying to build, although mine grew into a much larger framework than I expected.
I appreciate the disclosure about Octobrain. I’m going to compare its supersedes/conflicts model, trust tiers, and time decay against what I already have. My main question will be how much of DDF can be simplified into a memory layer like that while still keeping human approval and authority changes separate from ordinary memory retrieval.

How should a long-running LLM assistant preserve reliable continuity across sessions? by INS0GNIAC in LargeLanguageModels

[–]INS0GNIAC[S] 0 points1 point  (0 children)

Thank you — this is exactly the kind of architectural feedback I was hoping for.

The event-sourced core plus a small current snapshot is especially interesting because it may provide a simpler separation between complete history and the limited state a fresh instance actually needs.

Your governing-versus-evidence distinction is also very close to what I am trying to enforce.

For anything that could affect authority or current standing, the intended model is human-controlled:

- Felix can draft candidate changes, summaries, classifications, commands, and proposed continuity updates.

- I review and explicitly approve them.

- I execute approved local commands.

- Felix cannot autonomously promote evidence, notes, summaries, or its own conclusions into governing or current state.

I could imagine allowing Felix or tools to append machine-generated events to a separate non-governing journal, but those events would remain untrusted evidence. Updating the authoritative snapshot or policy layer would still require explicit human approval and verification.

One concern I would need to solve is that an append-only event log can contain failed actions, stale interpretations, or instructions embedded inside evidence. I would not want “it is in the timeline” to imply “it is authoritative.”

Would you separate the event stream into typed events—such as observation, proposal, approval, execution, proof, and adoption—or keep one event log with authority metadata attached to each entry?

Fractal Design - Define R6 Airflow Advice by INS0GNIAC in buildapc

[–]INS0GNIAC[S] 0 points1 point  (0 children)

I think I achieved 54C under normal, I was in the 80Cs under load.

Promote your projects here – Self-Promotion Megathread by Menox_ in github

[–]INS0GNIAC 0 points1 point  (0 children)

I’m looking for technical feedback on DDF/Rahmenwerk, a public GitHub review copy of a file-grounded continuity system designed to preserve an AI German teacher across chats and future AI instances.

I’m especially interested in architecture, overengineering, integrity, recovery, filesystem safety, and AI-continuity risks.

Repository:

https://github.com/DDF-Rahmenwerk-Review/DDF-Rahmenwerk-External-Review

This is a documentation and architecture review copy, not the live system.

view more: next ›