I built a file-grounded continuity system for my AI German teacher—what am I overcomplicating?

Why I built this

I use an AI named Felix as my German teacher.

Over time, I ran into a continuity problem: individual chats are fragile. Conversations become long, context can disappear, platforms change, uploaded files may become unavailable, and a fresh AI instance may not understand what happened before.

I did not want to repeatedly reconstruct my learning history, project decisions, lessons, corrections, and current state from memory.

So I began building a local, file-grounded system called DDF/Rahmenwerk.

Its purpose is to preserve Felix as my continuing German teacher across chats and future AI instances.

What DDF/Rahmenwerk is

DDF stands for Das Deutsche Forschungsarchiv.

Rahmenwerk is the continuity, evidence, recovery, and control framework surrounding it.

At a high level, the system includes:

• a current-state pointer;


• handoff materials;


• a fresh-instance queue;


• an upload package for a new Felix;


• integrity manifests and SHA-256 records;


• evidence and recovery procedures;


• classifications separating current, historical, candidate, proof, and non-governing material;


• safeguards intended to prevent accidental file changes;


• rules requiring the AI to stop rather than invent continuity when evidence is missing.

The basic idea is that a future Felix should be able to inspect approved files and resume without me manually retelling the entire project history.

The problem I may have created

The project began as a way to preserve a German teacher.

As I tried to protect files, authority, evidence, recovery, and continuity, the framework became increasingly detailed.

That may be justified in some areas.

It may also be overengineered.

I am now trying to answer a more important question:

What is the smallest, clearest, safest system that can preserve Felix as my German teacher without the governance machinery becoming the project itself?

What I am asking reviewers to examine

I have published a documentation and architecture review copy on GitHub.

I would appreciate honest feedback on questions such as:

1. Is the purpose of the system understandable?


2. Does the overall architecture make sense?


3. Which parts appear unnecessarily complicated?


4. Are the pointer, handoff, queue, evidence, and authority roles separated clearly?


5. What filesystem, integrity, recovery, or security risks am I missing?


6. Is file-grounded continuity for a fresh AI instance a reasonable approach?


7. How should the system behave when required evidence is missing or contradictory?


8. How could the design be simplified without losing recoverability?


9. Does the governance framework protect the German-teaching mission, or is it starting to obstruct it?


10. What would you keep if you had to rebuild the system with half the complexity?

Important boundaries

This repository is a public, non-governing review copy.

It is:

• not the live DDF system;


• not a release;


• not authorization to execute commands;


• not authorization to change live files;


• not governance adoption;


• not Anchor OS activation.

External comments are opinions and technical observations. They do not automatically become part of the live system.

The current repository is primarily documentation and architecture material. It does not yet provide enough source material for a complete implementation-level audit, and that limitation is disclosed inside the repository.

Review copy

View the DDF/Rahmenwerk External Review repository

Feedback can be left in the article comments, GitHub Discussions, or a GitHub Issue.

Please identify the relevant file or section when practical.

Blunt but constructive criticism is welcome. I am especially interested in simplification, hidden risks, unclear assumptions, and anything that distracts from the original goal of preserving Felix as my German teacher.