79 lines
3.4 KiB
Markdown
79 lines
3.4 KiB
Markdown
# Roadmap
|
|
|
|
## Overall Direction
|
|
|
|
Synaptopus is intended to become a multi-architecture artificial neural systems lab that supports:
|
|
|
|
- reusable architecture families
|
|
- hybrid execution across unlike systems
|
|
- inspectable traces for pedagogy and research
|
|
- graph-oriented tooling
|
|
- browser-based experimentation
|
|
|
|
The project should remain useful even if no single architecture family dominates it.
|
|
|
|
## Current State
|
|
|
|
The repository already contains:
|
|
|
|
- generic runtime and trace primitives
|
|
- component-role protocols and cooperative orchestration
|
|
- information-theoretic sequence analysis
|
|
- generic reporting helpers
|
|
- graph schema and trace serialization
|
|
- multilayer backpropagation
|
|
- ART1
|
|
- Hopfield-style dynamics and generic Hopfield matrix preparation
|
|
- a small XOR novelty demo combining backpropagation and ART1
|
|
- a richer parity-pressure demo combining backpropagation and ART1 under category pressure
|
|
- a demo exporter that can emit artifacts for multiple internal demos
|
|
- first-pass checkpoint/resume snapshots for the internal demos
|
|
|
|
This is the first point at which Synaptopus is more than a scaffold.
|
|
|
|
## Near Term
|
|
|
|
- Extend checkpoint/resume beyond internal demos toward a generic snapshot contract
|
|
- Add explicit RNG-state capture where demo behavior is stochastic at runtime
|
|
- Expose snapshot artifacts more directly in the browser-side tooling
|
|
- Document recommended conventions for state, candidate, metadata, and mutable model serialization
|
|
|
|
## Mid Term
|
|
|
|
- Introduce domain adapters as examples rather than as the center of the framework
|
|
- Add experiment runners that generate comparable reports across parameter sweeps
|
|
- Add more robust trace viewers and summarized execution statistics
|
|
- Build a TypeScript mirror of the graph schema and trace model
|
|
- Prototype a browser-based workbench that can visualize execution traces and graph structure
|
|
|
|
## Longer Term
|
|
|
|
- Support richer loop and controller semantics in the graph layer
|
|
- Add pedagogical views for stepwise inspection of network behavior
|
|
- Expand architecture coverage beyond the historically reconstructed families
|
|
- Allow the same execution concepts to span music, classification, toy planning, and other problem domains
|
|
- Support saved sessions and replayable teaching demonstrations
|
|
|
|
## Design Constraints
|
|
|
|
Several constraints should remain stable as the repository grows:
|
|
|
|
- generic code should be preferred over thesis-specific code
|
|
- architecture families should remain explicit rather than hidden behind one opaque abstraction
|
|
- graph tooling should reflect execution semantics rather than invent a separate model
|
|
- serialization should stay JSON-friendly for browser consumption
|
|
- pedagogy should be treated as a first-class use case, not an afterthought
|
|
|
|
## Relationship To TriuneCadence
|
|
|
|
TriuneCadence remains the historically grounded exemplar and compatibility reference for the thesis-derived hybrid composition system.
|
|
|
|
Synaptopus should borrow generic, reusable pieces from that work, but should not become tied to one domain, one historical artifact set, or one architecture trio.
|
|
|
|
## Concrete Next Milestones
|
|
|
|
1. Generalize snapshot/resume beyond the built-in demos.
|
|
2. Extend the TypeScript-side contracts to cover snapshot artifacts explicitly.
|
|
3. Teach the browser tooling to inspect checkpoint contents and resume lineage.
|
|
4. Add a more complex mixed-family example with stronger controller semantics than the current parity-pressure demo.
|