I just had a couple of interesting, informative, and possibly useful chat sessions with ChatGPT (CG):
Interested readers can explore the actual sessions. Meanwhile, this post provides an overview.
TBP Website Research Assistance
In this session, I asked CG to help with some general research:
Can you peruse the TBP web site to research a question?
Yes. I can peruse the Thousand Brains Project site, its docs, forum links, GitHub/docs pointers, and related Numenta pages to research a specific question. …
Cool! I’d like a detailed summary of the message data formats that Monty’s modules can emit and/or handle. This should include CMP, telemetry, and any other formats that seem relevant. I’m particularly interested in ways for LLMs to interop with Monty. Finally, I’d like to know about any troubling forms of connascence (arrays and lists exhibit COP).
Note: COP is Connascence of Position (i.e., order dependence).
… Monty’s “message format” is not primarily a wire protocol such as JSON, Protobuf, ROS messages, etc. It is currently a Python-level semantic contract centered on CMP-compliant
Stateobjects: “feature/object at pose,” plus sender and confidence metadata. Telemetry/logging appears to be a separate experiment-observability layer rather than part of CMP proper. …
Are there reliable (and reasonably tidy :-) ways to capture all CMP and telemetry I/O? …
Yes — but with one important caveat:
There is probably no single magic “record everything” switch yet. The reliable/tidy approach is to add a thin observation layer at the few choke points where Monty already passes messages and logs events, rather than trying to sprinkle print statements everywhere. …
… What is the cleanest, minimal way to modify (e.g., branch) the Monty code base to allow generalized I/O of CMP messages? …
… Add a pluggable CMP “tap” interface at Monty’s message boundary, without changing CMP semantics or module algorithms.
Monty already treats CMP as the common protocol among SMs, LMs, and motor systems, where communication is “features at poses,” with sender ID and confidence; raw sensory input and final actuator commands are explicitly outside CMP. …
Examine the current code base and report on the number of places that would need to be modified to implement a pass-through (no-op) implementation. Show (short!) examples of current and modified LOC, providing citations (i.e., file, module, line range).
… I found about 5 existing source locations for a clean no-op CMP I/O tap in the current graph-matching path, or 6 if you also patch the simpler base
_vote()fallback. …
RFC Minimal CMP Tap
In this session, I asked CG to draft an RFC:
In “TBP Website Research Assistance” (https://chatgpt.com/share/6a08fd9d-7160-83e8-aaa0-5ee68a8dc28c), CG and I explored a number of issues related to allowing Monty’s LMs to interoperate with LLMs, etc. Near the end of the session, we converged on the idea of proposing an RFP (really, RFC) for a minimal set of “cmp_tap” changes that could be extended to support interop. Generate an RFC in TBP style for this set of modifications.
Below is a draft RFC in a TBP-ish style: concrete, implementation-oriented, minimal in scope, and careful to separate the immediate no-op tap from later interop work. …
The following draft seems pretty detailed and plausible to me, as did CG’s preceding answers. FYI, here is an outline:
- Summary
- Motivation
- Goals
- Non-Goals
- Background
- Proposal
- Proposed Interface
- Minimal Patch Strategy
- Boundary Placement
- Event Phases
- Message Kinds
- Encoding Requirements
- Connascence Concerns
- LLM Interoperability
- Future Interop Path
- Configuration
- Performance
- Safety and Semantics
- Testing
- Acceptance Criteria
- Example: No-Op Integration
- Example: JSONL Capture
- Open Questions
- Recommended First Patch
- Rationale
(ducks)
