COGNILOG

The Cognitive Gap

between reasoning and recollection

A strength of mine is paired with a rather unfortunate weakness. When I set my mind onto a problem, it does not let go until resolution. As the complexity increases, the focus narrows to the part at hand while the bigger picture stays in view. The journey and rationale live on a platter of understanding within arm’s reach during the process. However, once the task is complete, I dump the cognitive capital that was required to accomplish it. The logical sequencing that led me to a solution starts to fade away. Recalling the resolution, why I did what I did, becomes almost impossible without replaying the play-by-play. Where I might excel in reasoning, I fail in recollection. This is compounded when I context switch while on the solution journey, then come back and have to re-render the mental state I was in when I left. Now, with the advent of agentic AI as an aid, the cognitive gap between reasoning and recollection widens. The shared synapses between me and AI leave me with only my portion of cognitive awareness and evidence to aid me in recollecting what I was doing, or why I was doing it. My particulars aside, I suspect the shape of this is universal. Things completed get archived to make room for the next thing, and for whatever reason the fade sets in, until the reach into an archived memory returns an index of what happened, not necessarily a rendering of the why. What I wanted was a way to reach into the archive and get renderings back, whether I was chasing one specific why or scanning a whole stretch of work for its shape.

Without a purpose-built tool to augment my recall capability, I started shoring up the weakness with habits, such as applying documentation liberally, noting everything. However, documentation is usually only applied when the situation warrants it, and when it does, it’s for a broader audience than myself, and thus may have some of the more personal hints and aids culled out. While documentation is a good representative of the current state, it isn’t a good medium for the journey it took to get there. So, I decided on keeping a work log, just anything, little notes to myself, of why I did something, what I had worked on, the meaningful outcome of a meeting or of an impromptu troubleshooting session, all leaving breadcrumb trails for me to render into recollection during recall. As I built this rear view mirror capturing what was behind me, it started to help orient me quicker when it was time to lock in again to a specific thread of work.

The idea of journaling a work log isn’t original. The habit or discipline to log everything, even when nothing has happened, has been a staple in several professions, such as medical, maritime and military, and in places of shared responsibilities, anything from a captain’s log, to a guard’s report, to a bathroom cleaning ledger. My work log notes would take on a description and granularity that could reflect any of those types of logs depending on how loquacious I felt like being at the time. I was encouraged that I had found a habit that seemed to help, but ran into an issue of comprehensive structure. More and more my journaling and notes were strewn across different mediums. I would regularly audit and refactor the corpus into some common format or schema, but I never could find the same tool that could afford the input and recall mechanics I desired in one place. Where most capture tooling satisfied, it would then fail me for the type of recall I would require. And where a tool excelled at recall, it was cumbersome or inadequate for capture.

So, being a builder of digital solutions myself, I set out to create a tool that would capture how I wanted, while also offering the recall story all in one place. That tool became CogniLog. The capture story is straightforward: it’s shaped by how I already find myself capturing, learned from everyday products like Apple Notes, Slack, and READMEs, and from the note taking apps I had been journaling my work log in. All of them speak Markdown underneath, whether through direct tokenization or GUI formatting with Markdown as the schema on import and export. So my ideal capture was Markdown.

As for recall, this is where I very much had little concrete to adopt or draw from. First and foremost the raw corpus needed to present itself temporally, much like a running log stream does. All calendar apps and some journaling apps honored this format, but fell short in other ways while more conventional note taking apps that served their purpose well for creation, just didn’t honor this at all. The part that was missing the most in all existing possible solutions is progressive detail or awareness of the corpus from a temporal display context. What I mean by that is the ability to get a 30,000-foot view of your work log in a meaningful way, and then be able to drill in, each layer deeper producing a higher fidelity rendering of the work log entries that fit within the displayed temporal window. Some calendar apps pull this off well for content like reminders, appointments, meetings, schedules and the like, all naturally short formed to begin with. So, for recall ultimately I started with a raw view of a highly filterable log stream with some visual quick view style anchors that rendered as a mini-map of the stream. Then drew from the calendar concept combined with the GitHub style commit heat map to help build a temporal visual and canvas for drilling into progressive detail.

The motivation behind progressive detail in a visual canvas is that the recall engine is meant to help me quickly find out things like: when and how much did I work on X? What does the distribution of my work look like across XY&Z? What were the decision points on the direction of XY&Z? I wanted to be able to first scan the days, weeks, months, in one glance, identify all the X category of work, hover over for headline and tags, “Decision point on aspect Y for X”, then click or tap into that headline pane without committing fully to that entry to render a little more detail, getting the first part of each paragraph or bullet points presented, then make a determination if this is the entry that provided the reasoning behind a decision, if not I simply check the next visually filtered candidate. Once I find it, drill into the entry itself. Of course keyword search and attribute filtering help at scoping the entire corpus to optimize this style of data spelunking, so that needed to be supported natively as well. I also wanted to use the same view and mechanics for discovery down memory lane versus a concrete lookup. Being able to marinate in the past some helps me reinforce the decisions I have made to keep me from returning to re-evaluate them again.

So the input or capture story was about 20% of the ask, the recall requirements were easily the other 80%. But this workflow predated the advent of AI. I actually made crude versions of this starting nearly a decade ago and would re-approach it every few years, never completely through to fruition. What AI brought is two new surfaces. AI can and has become a partner with shared awareness on many produced artifacts, and the reasoning behind things a shared responsibility. For me specifically, the reasoning behind a scoped request now had layers, my layer of why the request was being made, then the AI’s layer of why it executed the way it did. Instead of drawing that info from AI and then transcribing it to the work log, I wanted the same AI to make the same work log entry as I would for my part, thus creating a shared authorship surface. The other surface being recall within an AI context. While the visual temporal canvas offers a tactile approach for me, when within an AI agent console, like Claude Code or Codex, the AI needed to be able to recall from the same corpus in the progressive detail rendering that is natural to it, and thus requiring a programmatic AI friendly recall surface. This led me to incorporate MCP centric design and interfaces for both authorship and recall. With recall specifically allowing the agent to query scoped requests, building the context it needs responsibly.

What I liked about doing the product discovery when trying to find an existing solution, is that I found products that helped augment my productivity workflows even though they would not solve my work log journaling story end to end. Being creatures of habit, we refrain from using a new protocol, process or tool, if it doesn’t play nice with our existing ones. One of the requirements for me for CogniLog was that it needed to play nice with others, that it could graft into existing workflows, and tools. The pragmatic way to make this a reality is to keep it from being a walled garden via proprietary standards. Having an import story that was as broad as possible allowing ingest from existing content creation apps was a must for being able to seamlessly migrate an existing corpus of notes, or to plug into an ongoing and recurring workflow. Being a two way street was very important to me as well, by creating common sense export protocols, such that anything authored or migrated to CogniLog could also be exported in as many standard formats as possible for other apps to ingest, as well as a proprietary archive that can be re-ingested (the user’s choice). I often don’t start my work log entry within CogniLog, it starts as an Apple Note, or pulled from one of my other note taking apps.

Enriching ingest and capture beyond declarative imports though is where the CogniLog capture engine is meant to go next. While the manual prose capture, the AI based programmatic input, and rich import support help build cognitive bridges, the ideal is that anywhere your work story already shows up, CogniLog could become a relevant sink for it. So much of a work log gets written without anyone calling it one: git commits and merges, tickets changing state, the meetings on your calendar, the reminders you check off. The intent is for CogniLog to ingest from the sources that already contain your work log, so you aren’t transcribing your own history twice.

With CogniLog, the work that demands my utmost focus, the meetings and administrative tasks around it, and the shared cognitive awareness I build alongside AI tooling all end up in one corpus built around recall, wired into the tools I already use, and rendered in progressive disclosure whether I am chasing one specific why or scanning a stretch of work for its shape. As it stands today, that corpus lives in a native Mac and iPhone app, on the App Store. The log lives on your devices and syncs through your own iCloud. The only account involved is the Apple one you already have: nothing to sign up for, no login, and no server of mine holding any of it. CogniLog was built for me, retrofitted to my strengths and weaknesses. If you share some similar pains, then it might be something for you as well.

Rivet & Rune

Written by the person behind it. Say hello: support@rivetrune.com

ALL NOTES