How much does an AI need to know about you to give a better answer?
An old decision can send it in the wrong direction. An entire conversation history may reveal more than the task requires. Yet leaving out one important detail can make the answer useless.
Brane is our way of investigating that problem: what information helps, what should remain private, and when adding context makes the result worse.
Technical context, September 2026: A small local computer can run a compressed open model for some useful tasks, though hardware and maintenance still cost money and the hardest work may call for a frontier service. Apple describes local AI capability in its M6 Mac mini announcement; Qwen’s model page describes a capable open-weight option. Local processing is one way to reduce what must leave a person’s machine.
Personal context also has commercial value. OpenAI says personalised ads in ChatGPT can draw on a conversation, past chats and memory, while those conversations remain inside ChatGPT rather than being disclosed to advertisers. That is not evidence of conversations being sold; it does show why control over personal context matters. OpenAI Help Center
Brane asks whether a model can receive only the context that improves a task, while the richer personal and project history remains under the user’s control.
That claim needs a demanding comparison. As of September 2026, GPT‑5.6 Sol had a context window of more than one million tokens and can search files, use tools and coordinate work. A system that merely selects relevant information would add little. OpenAI Developers
Brane’s proposed role is a private layer that controls what information an AI receives. It could keep evidence, decisions and permissions outside a model provider, then prepare a limited view for a particular task. Once private material has been sent to a service, a model cannot undo that disclosure. Keeping the selection with the user would also make it possible to inspect what was shared and why.
Selection is harder than retrieval. An old project decision may look relevant but have been replaced. Two records may conflict. A personal preference may be true yet inappropriate for the current role. More history can make an answer familiar and repetitive when an open question needs a new idea.
A useful system would mark superseded decisions, expose conflicts and let uncertain inferences lose weight over time. Sometimes the right choice is to add no personal context at all.
Those distinctions matter in ordinary work. A coding assistant can faithfully implement an obsolete requirement. A pricing estimate can follow an assumption that the customer has since changed. A personal assistant can remember a preference that no longer fits the person’s circumstances. In each case, retrieval has succeeded, but the answer may still be wrong. The system needs a record of what was accepted, what replaced it and what remains uncertain.
Continuity can also narrow an answer. If the same history is supplied to every open design question, the model may return to familiar ideas when the user wants alternatives. Brane would need a reason to include each piece of context, and a way to leave it out when novelty or privacy matters more than familiarity.
Existing methods offer parts of this work. Retrieval can find material when a request arrives; a knowledge graph can preserve relationships; MCP can connect tools. Research into Adaptive-RAG, response-aware memory selection and long-term memory evaluation provides useful comparisons. Brane’s contribution would have to come from its ownership and selection rules, and from measured results.
The decision is not simply whether a record matches the question. A useful detail has to earn its place against the risk of staleness, privacy exposure, delay and distraction. A short current constraint may help more than a large archive. A conflicting record may be better shown to the person for resolution than silently combined with another into a false certainty.
The first version might use simple rules: Is the task personal? Is there a current accepted constraint? Has an earlier decision been replaced? Is the information sensitive? Could the task stay local? A local model might help search files, spot conflicts or compress context where those rules are insufficient. Only a small, permission-checked packet would go to an external model when needed.
Local processing is not automatically the best answer. A smaller model could add delay and make the same choices as a few clear rules. It might also miss a contradiction in a document or over-compress a decision that matters. Brane would need to show when local analysis improves the selection and when a direct task with no extra context is better. The aim is to make the boundary useful and inspectable, not to insert another model into every request.
For a person, this could keep messages and documents on their own hardware. For a company, it could keep plans, source code and client material local while sharing a limited abstraction. A local store still needs security, deletion, export and access controls; external services still require trust.
Related questions appear elsewhere in SR3H’s work. Conchup keeps product requirements and decisions connected to implementation, so a later change has a traceable reason. RedThread explores how to bring fragmented source material into a private briefing. These products solve different problems, but each depends on knowing which information is current and who may use it. Brane would test that boundary for AI assistance.
A user should be able to see more than a general assurance that their data is protected. The meaningful account is specific: which source was used, whether it was transformed, what stayed local, what left the machine and which permission allowed it. That record would help people correct a bad selection and compare the system with a simpler approach.
Control also includes being able to withdraw or update information. An accepted project decision should not silently inherit authority forever. A record can remain available as history while being marked as superseded for future work. The same distinction applies to personal information: retaining a detail, using it for a task and sharing it with an external service are separate choices. Treating those as one blanket permission would undermine the ownership Brane is meant to test.
The test is whether this helps real tasks. Compare the same work using an existing capable assistant, no extra context, a broad profile, ordinary retrieval and a small packet chosen by Brane. Check whether each answer follows current constraints, avoids stale decisions, remains original and exposes fewer private details. Measure delay, token use and reviewer preference too.
The existing assistant should run normally, with its own memory, tools and long context. An artificially forgetful comparison would make Brane look useful without showing a real improvement. A blind reviewer could judge the outputs, while the study records how much private information each method revealed. The cases should include both tasks where context ought to help and tasks where it ought to be withheld.
If simple rules perform as well as a local model, use the rules. If the existing assistant already handles the task, Brane should stay out of the way. Brane earns its place only if it improves outcomes while sharing less information.