IvanTheGeek

I have a category description set that is a bit longer. Edit the description of the Talkyard category: The place where I record my Talkyard "forum" investigations, experiments, questions, experiences. Being done here to eventually be used to improve ...

Right now, just gathering thoughts. Will compose this into an actual story later.

Replies have links to examples I have found

A collection of ideas for apps. Feel free to suggest and define.

This is a good moment to freeze the ontologies, because you now have enough clarity to separate three layers: Nexus Universal Ontology (domain-agnostic primitives) Adam’s Event Modeling Ontology (method primitives) Event Modeling Extended (EMext) (yo...

DISCOVERY-019ce328-ea67-77ce-8b0a-ed422fa1bdd3: 019ce328-ea67-77ce-8b0a-ed422fa1bdd3 Following the distinction between Domain Ontology, Concept DNA, and Cells, the next question is: What are the fundamental cell types that implement behavior inside a...

Discovery Log: Distinguishing Domain Ontology vs Concept DNA in the Nexus Model After a large amount of exploration and iteration, an important conceptual distinction emerged in the Nexus model between Domain Ontology and Concept DNA. This distinctio...

Good software to look at being useful Is open source https://checkmate.so/sponsored-features#top as a way generate $ and improve the product.

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...