FAQ

What is the difference between Synix, Synixolis, and CDR?

Synix is the program name. It covers the build system, the memory architecture, the protocol, and the conceptual model.

Synixolis is the protocol specification — the formal rules for how a conforming node or colony operates. Think of it as the spec document.

CDR (Compress, Divide, Renew) is the theoretical framework that informs the design. It argues why certain architectural properties are necessary. You don’t need to understand CDR to use the system — it’s the reasoning behind the design decisions.

Those claims are still part of an active research program. The build system can be used today without accepting the full conceptual model.

What is actually built today?

The build system is shipped software — Python, MIT license, 10 releases. Content-addressed storage, DAG execution, incremental rebuilds, hybrid search, MCP server. You can install it and use it.

The memory architecture is in design. The object store and search index exist from the build system. The event log, agent registry, policy engine, and governance mechanisms are not yet built. See the roadmap for the full breakdown.

The Synixolis protocol is a draft specification (v2). It has not been validated through a reference implementation yet.

In other words: most of the protocol layer should be read as design work, not as an already-demonstrated platform.

Where should I start reading?

If you want to understand the overall program: start with the overview.

If you want to understand the design philosophy: read the conceptual model.

If you want to see what’s shipped: look at the build system.

If you want to understand the new architecture: start with the memory architecture overview and then the data model.

If you want the protocol details: the Synixolis overview walks through what a node and colony look like before you hit the spec sections.

How expensive is this in LLM calls?

In the current design, every memory operation (classification, contradiction checking, condensation, routing) is a full LLM inference call. That is expensive.

The protocol includes a five-level optimization path: pure inference → pattern recognition from traces → compiled routing rules → prompt-level compilation → native integration. The idea is that stable patterns get compiled into cheaper operations over time, and compiled rules that stop working get demoted back to inference.

This optimization path is specified but not implemented. The real cost profile is an empirical question.

What are the biggest open questions?

• Do explicit renewal and review mechanisms outperform simpler heuristics in practice?
• How expensive is continuous lifecycle management relative to the value it adds?
• At what point do multi-agent coordination costs outweigh specialization benefits?
• Which parts of the protocol are actually required, and which are useful only in the reference design?

Those are open research and engineering questions, not settled results.

Can I use this with an existing memory system?

The build system is standalone — it does not require replacing your existing stack.

The memory architecture is designed to be substrate-agnostic. In principle, the data model (objects, event log, policies) could sit on top of different storage backends. In practice, the only implementation path right now is the one described in the reference implementation (filesystem + markdown conventions).

Integration with Mem0, Letta, Zep, or other systems is not currently supported but is not architecturally excluded.

What is the minimum viable Synixolis node?

A directory on disk with:

• A CLAUDE.md containing the protocol rules
• A memory/ directory with region subdirectories
• Slash commands for write, review, query, and status

The reference implementation section describes the full structure. A single-node deployment without colony features is the simplest starting point.

How does multi-agent consistency work?

Nodes share an append-only state log. Each node materializes its own local view from this log. The consistency model is causal consistency — the weakest model that preserves provenance chain integrity.

Nodes that go offline continue on their local view and reconcile when they reconnect. Conflicts are resolved by recency, then confidence, then domain ownership, then human escalation.

The collective state section has the full specification.

What happens when two agents write conflicting data?

Both writes go to the event log (it’s append-only — nothing is rejected). The conflict detection mechanism surfaces the contradiction, creates a resolution record linking both objects, and either an agent or human adjudicates. The losing object is invalidated with a pointer to the resolution, not deleted.

See governance for the full conflict resolution process.

How do I add a new agent role?

Write a new policy document that defines the role’s trigger conditions, the procedure it should execute, and its authority level. Add it to the store. No code changes — the next agent that reads the policy directory will pick it up.

See agents for the role model.

What is the conceptual model for? Do I need to read it?

The conceptual model explains why the system is designed the way it is — the theoretical arguments for timescale partitioning, renewal, and multi-agent coordination. It connects to information theory, distributed systems, and cognitive architecture research.

You don’t need it to use the system. It’s there for people who want to understand the reasoning, evaluate the claims, or extend the framework.

What’s the license?

The build system is MIT licensed. The protocol specification and documentation are published openly. Formal licensing for the spec is not yet determined.

How do I contribute?

The project is at github.com/marklubin/synix. The build system accepts contributions. The protocol spec is in active development — feedback on the Synixolis sections is welcome, particularly from people with distributed systems or multi-agent systems experience.