AI has made it easier for me to create a lot of useful things. A research note. A design sketch. A review packet. A task brief. A few plausible next actions. The trouble starts when I return after a pause and there are several projects moving at once, several agent-assisted work streams producing new files, and a growing set of threads that may connect back to one idea or may simply be sitting beside each other waiting for a connection I have not made yet.
I have been feeling that pressure lately while trying to hold multiple projects at once. Obsidian helps. The folders, links, and notes give me somewhere to put the work. They do not always show me which thread matters now, which decision is current, what an agent prepared rather than what I accepted, or how the small projects are meant to cohere into one larger direction. The amount of output has gone up faster than my ability to return to it.
I can usually find a file if I remember its name, and I can often find a note if I remember the phrase I used when writing it, but returning to work asks for more than retrieval because I need to recover the reason the work existed, the source that made the current direction seem sensible, the unresolved question that may have been hidden by a polished draft, and the next action that lets me continue without reopening every adjacent project simply to reconstruct the room I was standing in before I left.
That is the practical meaning of an extended mind for me. I am building a workbench where records, sources, plans, and AI-assisted transformations can remain available when I need them, with enough structure to support a return without asking me to reconstruct the whole situation from scratch. The workbench has to help me grok the work rather than make a confident-looking answer appear in front of me.
A grammar is part of that workbench. It gives the records a few distinctions that survive the interface.
A grammar, here, is a small set of visible distinctions that survives the interface. It lets me see what came from a source, what remains a proposal, what a person decided, and what a tool only prepared for review.
The point is modest. A grammar does not solve the hard parts of knowledge work. It gives those hard parts somewhere visible to live.
Method boundary
How I am reading my own practice
I am putting the method on the table early because I want you to see what I am actually observing, what I am interpreting, and where this page stops before the technical detail starts to look more settled than it is.
- What I am looking at
- One researcher-builder: me, returning to AI-assisted research and design work after interruption.
- Question I am carrying
- When I come back after a pause, what helps me recover a source, a state, an open question, and one next action without mistaking accumulated output for understanding?
- How I am looking
- I keep a longitudinal first-person account of agency, authorship, continuity, cognitive load, and failure.
- I inspect source trails, review gates, exclusions, and recovery paths in the records themselves.
- I use public-safe record and presentation experiments to give the questions something concrete to push against.
- Work I am drawing on
- Research and Evidence Framework for the Knowledge Workbench
- Research Direction: Governed AI-Augmented Knowledge Work
- Hearth & Code Interaction Block Protocol v0, source-only proposal
Start with the return, not the dashboard
If I were walking someone through this at a whiteboard, I would start with the return rather than the dashboard. I open a document after a week away. The title still looks familiar. The text may even be good. Yet the important questions arrive before the first paragraph ends.
Where did this come from? Is the conclusion supported or merely plausible? Did someone decide this, or is it still an option? What changed since I last looked? What do I do next?
A useful system should make those questions cheap for me to answer. I do not need a giant ontology or a full product redesign before I can begin. I need a small record that keeps a few things together: a stable identifier, a kind of question or artifact, an answer state, a source, and a next action.
That sounds almost too basic to deserve architecture language, except the same small distinctions become important whenever several people, documents, or AI assistants touch the same work, because a record that retains its source and current state can be inspected by a colleague, a future reader, or an agent without asking any of them to treat the most fluent paragraph as the whole story, and because an explicit next action makes the difference between a folder that merely stores history and a workbench that helps someone re-enter it.
One source-only experiment in my work is called the Hearth & Code Interaction Block Protocol. When I explain it, I start with its deliberately plain rule:
“The code block is the durable record.”
Hearth & Code Interaction Block Protocol v0, source-only proposal
That sentence tells me where I want the meaning to live. A form, dashboard, or plugin may make a record easier to read or answer. I still need the record to remain understandable when the visual layer goes away.
Here is the small shape I keep in mind when I am designing for a return. It is a contract sketch, not an active form or a command for a model.
A return note, in plain view
The question I want waiting for me
When I come back cold, I do not need a miniature dashboard. I need to see one honest question, where it came from, and whether anyone has actually answered it.
- What I need it to hold
- The exact question I need to see before I can pick the work back up.
- What kind of thing this is
- An open question, still open.
- How I keep it usable
- I keep an explicit response state, a correction note, and named source references together.
- What I allow it to draw from
- I start with the current project record instead of treating an ambient archive or a prior session as automatic context.
- Who gets to decide
- I review, correct, and accept any response before it becomes part of the record.
- Where it stands today
- It is unanswered for now. That is useful information, not an empty space to hide.
- Where it belongs
- I keep this kind of working note private by default. This page uses a safe illustrative shape only.
version: "0.1"
id: return-to-work-question
kind: open_question
prompt: "What do I need to see before I can resume this work?"
response:
value: null
state: unanswered
note: null
source_refs:
- "current project record"
visibility: privateWhen I put the YAML after the note, I am showing the part that has to survive the presentation. An empty answer remains an explicit unanswered state. A note can carry a correction or disagreement. The question has a stable name. The source does not disappear behind a polished interface. Those small distinctions give a future reader something to work with, including the future version of me who has lost the thread.
Keep evidence, proposals, and decisions apart
AI makes this distinction matter more to me because fluent text can arrive before judgment does. A model can summarize a document, compare choices, find contradictions, or draft a plan. I can find that work genuinely helpful. I still need it to have a visible state.
I have been trying to keep three states separate in my own records:
- Evidence is something I can point to and inspect.
- Proposal is a possible direction that still needs review.
- Decision is a direction that a person has actually accepted and can be held accountable for.
This sounds small until an AI workflow starts producing several documents in a day. I can mistake a proposal for something finished. I can misread a source. I can look at a review note and forget that nobody has made a decision yet. The trouble is not that I forgot how to think. The trouble is that the system made several different kinds of thing look too similar.
When I say provenance, I mean a readable answer to a simple question: where did this result come from? I want a trail that includes the source, the method used to work with it, the parts excluded from the result, and the person who accepted or corrected the outcome. That is how the interesting work stays inspectable once the conversation that produced it is gone.
Give every AI request a boundary
The technical direction I keep returning to is a proposed contract called context.prepare. The name is less important than the habit I want it to make possible. Before I hand an agent or model a pile of material, I want the request to say what work I am doing and what material is allowed to enter.
A bounded request needs at least four questions answered:
- Purpose: What question or task is this context meant to support?
- Source scope: Which records or collections are allowed in, and which are out?
- Method and budget: How should the system look, and how much material may it use?
- Expiry: When should this prepared context be rebuilt or reviewed instead of quietly persisting?
Those fields give me a useful pause before the model sees anything: I have to say what I am trying to do, I have to say which material belongs to that task, I have to accept a limit on how much can enter, and I have to leave a point at which the context becomes stale enough to deserve another look, which is a much healthier starting point than treating every accumulated note as if it automatically belongs to every new question.
I call the evidence service Cortex and the workbench layer Exocore. Cortex may prepare cited candidates. Exocore would hold the active work item, the visible review route, and the final decision about what actually enters a context package. Those names belong to my project. The boundary is the part I want to make useful beyond it.
“No database is the “brain” of the system. Useful intelligence comes from a human-governed sequence of evidence selection, policy checks, explicit context construction, bounded execution, and visible review.”
Exocore Cortex and Platform Integration Boundary and Contract Route, source-only proposal
Governed context route
The handoff I want to be able to inspect
When I say that human authority should stay visible, I mean this actual sequence. The system may prepare bounded material, but I do not want it to quietly become the authority that accepts the result.
person
I name the work
I start by naming the question, task, or decision that needs support.
system
Gather only allowed sources
The system follows an explicit source scope and keeps excluded material out.
system
Prepare cited candidates
The system records sources, transformations, limits, and exclusions for review.
agent
Propose bounded work
An agent may draft or compare a next step from that prepared context.
person
I review what comes back
I accept, correct, reject, or defer the candidate.
person
I leave a durable record
When I accept an outcome, I want it to retain its source, state, authority, and next action.
The route remains an ordered record: person, bounded system work, candidate proposal, human review, then a durable accepted result.
I am not trying to make a model less capable. I am trying to make the handoff more legible, so it can help me prepare a next step without becoming the hidden owner of the project.
Make the small metadata earn its place
When I talk about small metadata, I am not describing a compliance system. I want every field to earn its place because I do not want every note to become a form. I do want the fields that help me return to work to be visible before I have to reconstruct the situation from memory.
For a small work record, I keep returning to a few questions: What is this? What is its current state? Where did it come from? What needs to happen next? Those are not the only fields a project may need. They are a useful beginning because they support both an individual note and a group of related records.
Small metadata also gives a team a way to talk about disagreement without flattening it. A record can carry a source alongside a claim. A proposal can remain a proposal. A review note can say why someone disagreed. An AI assistant can present a candidate without quietly changing a durable decision. The labels do not remove judgment. They make room for judgment to remain visible.
I have run a few small reader-task pilots around this idea. The useful parts were not one preferred dashboard or a universal card layout. Across the bounded exercises, readers needed a plain Markdown fallback, grouped structure, source links, a short summary, stable field order, and one clear next action. That is a limited result. It gives me a practical design direction without pretending the interface question has been solved.
The broader lesson for me is that a view should earn its place by helping someone orient around a real task, while the underlying record keeps enough of its meaning to travel when the preferred view changes, because I do not want the next useful card grid or dashboard to become another place where my work looks temporarily coherent and then becomes difficult to recover once the plugin, layout, or particular session that made it legible has moved on.
Build from personal practice, then test the boundary
I am starting with the kinds of problems I actually have. I want a place where I can hold a few active threads, see how a side project relates to a larger vision, and return after interruption without treating every prior conversation as lost context. That personal starting point is a source of design pressure, not proof that the same workbench will fit everyone else.
The real question is whether the small practices travel. Would a colleague find it useful to distinguish a source from a proposal? Would a project handoff improve if the next action and open question were visible? Would a model-assisted summary become easier to trust if its source scope and exclusions were readable? I think those are worthwhile questions. They need evidence from more people and more settings than my own work can provide.
The hearth and forge language in Hearth & Code is meant to keep that relationship honest. The hearth is the record I can return to. The forge is the place where a draft, question, or plan gets shaped. I remain the person responsible for deciding what belongs there. AI can be a second pair of hands, useful for sorting, comparison, and rough drafting, while the work still needs someone to ask whether it is true and whether it is mine to keep.
A question to take back to work
How has your own personal knowledge-management practice influenced the way you approach knowledge work in your workplace?
I am interested in the answer because tools often arrive as if everyone begins from the same workflow. They do not. Some people need a clearer handoff. Some need a source trail. Some need a smaller active surface. Some may find that a system I am building for myself does not help them at all. That answer matters as much as the next feature idea.
For now, the test is simple. When I come back after a pause, can I find the source, the state, the open question, and the next small action without mistaking accumulated output for understanding?
Hearthside expansion / author review candidate
This added reflection is a private-to-public projection prepared in my requested voice. It remains subject to my factual, privacy, and authorship review.
The grammar is for relationships, not for the mind
I use the word grammar carefully. I am not claiming that thought can be reduced to a formal language or that a system should parse a person into stable categories. The grammar belongs to the shared work: the relations among source, claim, proposal, decision, tool, effect, and return. It constrains the artifact, not the person.
This boundary matters because an extended-mind system can easily become presumptuous. If it stores enough behavior and preferences, it may begin presenting inference as identity. I want the opposite posture. The workbench can offer remembered context with a source and expiry while leaving me free to accept, revise, or ignore it.
The grammar should therefore include unknown and refusal. A relation may not be established. A term may remain contested. A private source may be acknowledged without being disclosed. These are first-class states, not errors the system must fill for the representation to feel complete.
In my own practice, this makes the extended mind less like a substitute brain and more like a set of carefully labeled shelves and instruments. It can help me recover the conditions of work without claiming authority over the meaning I make from them.
What I need the system to remember after interruption
After interruption, I rarely need the entire transcript. I need the live question, the current source, the decision that shaped the present route, the last verified change, the unresolved risk, and one next action small enough to begin. These elements reconstruct orientation more effectively than a large summary of everything that happened.
I also need the system to remember what not to resume. A branch may be incubating rather than active. A candidate may have been withheld. A tool may have been available but not authorized. Without those distinctions, retrieval can reactivate old possibilities as if they were obligations.
The return record becomes a kind of cognitive checksum. It does not preserve every nuance, but it lets me notice when the current story has drifted from the recorded state. If the summary says a service is active while the receipt says only that a manifest rendered, the mismatch tells me where to look.
This is deeply personal in use and intentionally modest in claim. The pattern has helped me return to complex work. I do not know whether the same fields will support another person’s attention, and I do not want an individual adaptation to become a universal prescription.
The smallest grammar that can carry the day
A useful daily grammar may be no more than five distinctions: source, current state, open question, boundary, next action. If those are clear, I can often resume without loading a larger system. Richer typing should appear only when the task contains a real ambiguity the smaller form cannot hold.
For research, I may add claim class and evidence need. For agentic work, I may add tool permission, stop condition, and return contract. For public writing, I add audience, disclosure posture, and authorship review. The grammar grows from consequence rather than from a desire for completeness.
This modularity is important to the wider Exocore direction. I want a workbench capable of supporting different practices without forcing every record into the maximum schema. The system should be able to recognize a small note as complete for its purpose while still connecting it to a more formal process when needed.
The ultimate test is whether the grammar reduces reconstruction and category mistakes. If it merely generates more metadata, it has failed. The extended mind should return attention to the work, not make the maintenance of its own representations the dominant task.