Simmis keeps recorded organizational facts and history queryable, gives people and agents bounded tools to reason and work from them, and keeps proposed changes separate until authorized adoption.
Keep organizational records, documents, relationships, and decisions connected across retained versions, so people and agents can examine what changed, when it changed, and the context surrounding a result.
People and agents deterministically query organizational ontology instead of reconstructing the organization from memory, files, and prompts.
Leverage shared context, scoped tools, schedules, and spending limits to support coordinated work.
Proposed changes remain inspectable and separate until an authorized decision.
02 HOW IT WORKS
Simmis presents the proposed change, checks adoption authority, records the decision, and invokes the supported return, discard, or adoption path.
Dvergr assembles a persistent team around a task, gives it relevant organizational facts and approved capabilities, and returns either an answer or a proposed change for review.
The team and its context persist as individual workers come and go.
Everyone works from the same task, relevant facts, and configured boundaries.
Datahike preserves managed facts and relationships across versions. Dvergr work uses a forked connection, while authorized adoption creates the next accepted version.
ONLY ADOPTED WORK CHANGES THE SHARED SOURCE OF TRUTH. SIMMIS CANNOT CONTROL EXTERNAL ACTIONS SUCH AS PAYMENTS, EMAILS, OR PROVISIONING.
03 WHAT IT BUILDS ON
Make change on a branch, inspect the diff, request review, and merge deliberately.
Apply branch, diff, review, and merge to organizational state, not only code.
GitHub versions repositories. Simmis coordinates the registered data, files, and execution context involved in an organizational attempt.
Listed entities and products are illustrative references, not dependencies. Simmis is independent and is not affiliated with or endorsed by these companies.
Simmis brings the replikativ component family together as one integrated Clojure/ClojureScript stack. Individual components have different maturity and support boundaries.
| AREA | WHAT EXISTS | CURRENT BOUNDARY | STATE |
|---|---|---|---|
| MANAGED STATE | Accepted bases and queryable history for registered managed state. | Accepted state is not proof of outside truth. Queryable history is not automatically an audit trail. | WORKING WITH LIMITS |
| ADOPTION | Proposal review, conflict checks for supported fork types, and recorded adoption for each fork. | A proposal lands one fork at a time, not as one atomic transaction. Reconciliation varies by fork type. Any fork that does not land remains open and retryable. | WORKING WITH LIMITS |
| AUTHORITY AND EFFECTS | Managed changes pass through an adoption decision. | Detailed authority and the unified assignment, branch, and review experience remain incomplete. External actions require separate controls. | IN PROGRESS |
| INTEGRATIONS AND RELEASE | Supported registered systems can participate in managed work. | Connector maturity varies. Supported public installation remains unreleased. | LIMITED |
| SIMULATION | Research into possible organizational futures. | Organizational simulation is not current product behaviour. | RESEARCH |
The current architecture uses immutable data and reactive computation to keep accepted state, branches, and history inspectable.
Probabilistic programming informs a research direction for what Simmis may learn from retained history. It is not current product behaviour. Start with the component role map, then watch Christian Weilbach’s talk, “Programming as and for Inference.”
simmis
Datahike
Yggdrasil
Dvergr
Spindel
