Thanks, is the concern being non-starter on the trust side? the binary makes zero outbound calls. It talks to your bucket and nothing else, and that's verifiable with egress monitoring. I'm putting up a security page that spells it out.
Open-sourcing parts of it isn't off the table. I kept the core closed for now to understand the interest in it.
Harnesses are not a solved problem, yet. There are multiple kinds of memory that are user in them, conceptually. Working, Procedural, Semantic, etc. depending on harness design and architecture. Observe-modify is an integral part of harness development that continues to evolve and change, model to model.
Adoption of a system sans functional observability and mutation is of little utility. There's no reason to use a system that cannot be altered in design cycles (or larger model-release cycles), when memory systems aren't that complicated to begin with. RAG, Vector, simple KV, append-only buffers, are all in competition and used at different scales for good reasons.
The policy layer you’re describing lives in the harness, and yes, it changes over time. What I wanted to showcase is polign_db underneath with typed records, hybrid index, attached to your bucket. You can swap your memory design without migrating the storage or spawn nodes to access it quickly.
I see your point on observability. I haven’t baked it into polign yet, but I have been thinking about ‘how’ I would do it a very user friendly way. Glad to have a conversation about it.
Thanks, is the concern being non-starter on the trust side? the binary makes zero outbound calls. It talks to your bucket and nothing else, and that's verifiable with egress monitoring. I'm putting up a security page that spells it out.
Open-sourcing parts of it isn't off the table. I kept the core closed for now to understand the interest in it.
Harnesses are not a solved problem, yet. There are multiple kinds of memory that are user in them, conceptually. Working, Procedural, Semantic, etc. depending on harness design and architecture. Observe-modify is an integral part of harness development that continues to evolve and change, model to model.
Adoption of a system sans functional observability and mutation is of little utility. There's no reason to use a system that cannot be altered in design cycles (or larger model-release cycles), when memory systems aren't that complicated to begin with. RAG, Vector, simple KV, append-only buffers, are all in competition and used at different scales for good reasons.
The policy layer you’re describing lives in the harness, and yes, it changes over time. What I wanted to showcase is polign_db underneath with typed records, hybrid index, attached to your bucket. You can swap your memory design without migrating the storage or spawn nodes to access it quickly.
I see your point on observability. I haven’t baked it into polign yet, but I have been thinking about ‘how’ I would do it a very user friendly way. Glad to have a conversation about it.