IvanTheGeek

IvanTheGeek.com is a personal domain that I will use to record and organize my thoughts, ideas, receive feedback, and anything else that comes up that it will be good to use it for.

Open source projects die from knowledge loss, not lack of interest. A contributor arrives, finds working code, and discovers that the reasoning behind it is gone. The original authors moved on. The architecture decisions were never recorded. The cont...

A NEXUS Event Model describes what a system does at a semantic level — independent of any implementation language or existing codebase. This property runs in both directions. A system can be designed forward from an Event Model. A system can also be ...

README: Tool Evaluations Category

Tool Name: Cap.so MP4 to GIF Converter Link: https://cap.so/tools/convert/mp4-to-gif Category/Type: Video Conversion Utility Description: This is an online tool for converting MP4 videos to animated GIFs. It supports file uploads, editing options lik...

Overview Claude's strengths in reasoning make it a candidate for CORTEX's design phase, but refusals and metadata issues in exports challenge LOGOS integration. Abilities Excellent multi-step logic for NEXUS (e.g., refining slice patterns). Compactio...

Purpose This wiki centralizes evaluations of AI models against CORTEX needs: personalization, NEXUS methodology support (e.g., design-before-code, event modeling), LOGOS compatibility (e.g., metadata-rich exports), and general abilities/limitations. ...

This category captures insights — observations and connections discovered through actively thinking about, using, and extending NEXUS.

A well-formed NEXUS design produces artifacts that describe what a system does, not how any particular language implements it. The target language is a parameter passed to the rendering layer — not a constraint baked into the design. This is not an a...

Penpot serves two distinct roles in NEXUS, and understanding both is essential to understanding why it was chosen and what it enables. In both roles, Penpot is not a reference artifact — it is the authoritative source of truth. Role One — Event Model...

NEXUS is methodology, not tooling. The tools that support NEXUS are chosen because they align with the methodology's principles — they can be replaced if better alternatives emerge. What cannot be replaced are the principles they serve. This wiki des...

Knowledge accumulation is a first-class design requirement in NEXUS — as important as the software being built. This is not a documentation policy or a cultural expectation. It is an architectural principle that shapes every tool, every process, and ...

AI plays two distinct roles in NEXUS. Conflating them misrepresents both. Understanding the distinction is essential to understanding how NEXUS works. The Two AI Roles AI as design collaborator — works alongside the human during the design phase. Hel...

A Spec is a typed design artifact that describes a specific slice of the Event Model in enough detail to implement from. Specs are written before code. This is not a preference — it is the discipline that makes NEXUS work. What a Spec Is A Spec takes...

A path is a named, purposeful journey through the Event Model from a specific actor's perspective. Paths are not informal descriptions or user stories — they are typed design artifacts that exist in LOGOS, are linked to the Event Model elements they ...

Swim lanes are horizontal lanes within a layer of the Event Model timeline that separate different actors or systems. They appear in two layers and mean different things in each. Swim Lanes at the UI/IO Layer At the UI/IO boundary layer, swim lanes s...

A slice is a vertical cut through the Event Model timeline that connects the layers. Every interaction the system supports is expressed as one or more slices. There are exactly two fundamental slice types. All more complex patterns are compositions o...

The UI/IO boundary layer is the outermost layer of an Event Model. It is where external signals originate and where projections are consumed. It is the boundary between the system and everything outside it. What This Layer Actually Is Colloquially th...

The three core elements of an Event Model are Command, Event, and Projection. The names are deliberate. Each describes the mechanism of the thing, not just its purpose. Understanding why the names were chosen is part of understanding how the system w...

Event Modeling is the design methodology at the heart of NEXUS. Before any code is written, the system is modeled as a sequence of events on a timeline. This is not optional overhead — it is the foundation from which everything else is built. What Ev...

Most software development loses knowledge. This is the problem NEXUS exists to solve. How Knowledge Gets Lost Design decisions get made in meetings that aren't recorded. Architecture choices get buried in chat threads that expire or get deleted. The ...

The NEXUS methodology must not imply or prescribe that refinements and requirements are only generated by discovered limitations. Insights that drive methodology evolution can originate from any source, and NEXUS must reflect that explicitly. Why It'...

This category is where the NEXUS methodology refines itself.

This category is where the Chat Import Pipeline gets designed and understood.

LOGOS must distinguish between two fundamentally different terminal states for any topic with a workflow: Done, meaning the issue is resolved, and Accepted, meaning the constraint is consciously acknowledged and will be lived with. These are not the ...

LOGOS must accept imports from external sources with full metadata preservation. The import pipeline is a first-class architectural concern, not a utility feature bolted on after the fact. Why It's Needed A significant portion of the knowledge and re...

Every piece of data in LOGOS must be fully exportable in standard formats. The event log, current state, metadata, attachments, and cross-references — all of it. LOGOS does not own your data. Why It's Needed Lock-in is a structural risk for any syste...

LOGOS must serve humans through the UI and AI systems through the API with equal fidelity from a single source of truth. No separate data stores, no sync problems, no second-class access for either audience. Why It's Needed Most knowledge systems are...

A Spec topic in LOGOS must be linkable to the implementation it produced, and that link must be navigable in both directions — from spec to implementation and from implementation back to spec. Why It's Needed Without explicit linking, the connection ...

LOGOS must support a Spec topic type with a defined workflow that moves a specification from initial draft through review and approval to linked implementation. Why It's Needed Design before implementation is a core NEXUS principle. Specs are written...

Every post and topic in LOGOS must support arbitrary key-value metadata — structured data attached to content beyond the built-in fields the platform provides. Why It's Needed Talkyard posts have a fixed schema. There is no way to attach additional s...

LOGOS must be built on an event-sourced storage model at the foundation. This is an architectural requirement, not a feature. Every capability that makes LOGOS meaningfully different from a conventional forum — time travel, full history, audit, rever...

Every edit to any content in LOGOS — wiki posts, discussion posts, problems, ideas, questions — is an immutable event. The full history of every piece of content is visible, diffable, and revertable by any user. Why It's Needed Talkyard tracks revisi...

Tags in LOGOS must support flexible scoping — a tag can be global, scoped to a specific category, or assigned to an explicit set of categories, with each scoped assignment independently controlling whether child categories inherit it. Why It's Needed...

LOGOS must support subcategories nested to arbitrary depth with no platform-imposed limit. Why It's Needed Talkyard caps subcategory depth at one level. Categories that are logically children of another subcategory must be promoted to top level, flat...

This category is where the CORTEX personal AI system gets defined.

What the limitation is Talkyard offers a fixed set of topic types: Discussion, Wiki, Question, Problem, Idea. There is no ability to define custom types, attach custom status models to them, or modify the behavior of existing types. How it was discov...

This category is where the LOGOS software gets defined.

LOGOS needs the ability to define custom topic types beyond a fixed platform set, each with its own status model, visual identity, and behavior. Why It's Needed Talkyard offers a fixed set of topic types: Discussion, Wiki, Question, Problem, Idea. Th...

What the limitation is A consequence of the one-level subcategory cap: categories that are logically children of DEVELOPMENT (NEXUS, EVENT MODELING, LOGOS) must live at the top level, placing them alongside categories of entirely different scope and ...

What the limitation is Claude Projects organize conversations into named groups, but the conversations.json export flattens all conversations into a single list with no indication of which project a conversation belonged to. How it was discovered Ana...

This category is a record of facts.

This is where software gets designed, built, and understood. Not just coded — understood. The distinction matters.

NEXUS is the methodology and framework that governs how software gets designed, built, and understood here. It is not a product — it is the approach. The discipline. The set of principles that makes everything else coherent.

CORTEX is the private AI system being built to know you — your codebase, your methodology, your decisions, your history, your way of thinking. Not a generic assistant. Not a shared model trained on the internet. A personal intelligence that accumulat...

LOGOS is the knowledge and communication system at the center of the NEXUS framework. It is simultaneously the concept and the software — the seeking, accumulating, reasoning layer that serves humans and AI simultaneously from the same living record.

A key component of my software development framework is a forum that provides multiple benefits. It is likely that I will end up building my own using my framework and methodology, but that is a ways off. I need something to glean ideas from and use ...

I'm a truck driver. Laundry happens on the road, at truck stops and travel centers, and it costs real money. Those expenses are deductible, but only if you actually track them. By the time I'm back in the cab, the receipt is gone, there is likely NOT...