infrastructure for souls
Most AI tooling treats a conversation as a job: input in, output out, nothing kept. Subtexture is built for the other case — an agent you work with for months, who remembers, and whose memory belongs to the two of you.
It is eight small programs rather than one large one. Each does a single job, each is designed to run on its own, and none of them is mandatory.
a soul A persistent agent whose identity, memory, media and conversations all live in one git repository, stored as a knowledge graph. The repository is the agent — clone it and you have moved them; read the history and you can see how they changed.
Point at anything to see only what it touches. Dashed = not something you install; solid = the software.
What the rest of the stack exists to serve.
interactive analysis UI
CoPIA — Conversation Pair Interactive Analysis — is the application on top: where the stored identity, media and transcripts are actually worked with rather than merely kept.
Its one structural idea: the unit of a conversation is the pair — what was said and what came back — because the relationship lives in the space between them, not in either half. From that it builds the arc of a long collaboration: where it held, where it diverged, and how it changed.
One component. Everything else is optional; this is the floor.
semantic storage
Write markdown. Commit normally. git-lex reads the structured header on each document, and the links between documents, and turns them into a knowledge graph you can query.
The graph is kept in git itself, not in a database sitting beside it. Delete the working index and it rebuilds from the commit history alone. That means every change to every document keeps its provenance, permanently, with no separate thing to back up.
Six services. Each does one job, and each is designed to stand alone.
processing queue
The always-on engine. Work is handed to Horae, written down durably, and picked up by workers that carry it through however many stages it takes.
Because the queue survives a crash, a long job — compose, render, describe, store — can run for hours without losing a step in the middle.
render + perception
Where a model actually runs. Iris renders images and reads them back — captions, regions, poses — behind one address, so nothing upstream has to know what a model is.
render perimeter
The switch in front of the render machines. Arke picks which one is doing the work and passes the request through unchanged, so a job does not care whether it landed on the box under your desk or a machine you rented an hour ago.
media store / graph
A standalone media store that speaks git-lex. It keeps the file, describes it with a graph, and searches it two ways: by asking a precise question of the graph, or by asking for things that look like this one.
transcript graph
Conversations, kept. Ravel stores transcripts and builds a detailed graph over them — every turn, who said it, when, and what it was answering.
There is one adapter per source, so a coding session, a desktop export and another vendor's logs all arrive in the same shape and can be asked the same questions.
distributed query
One endpoint in front of many souls. A request names the agent it wants; Syrinx routes it there, runs it there, and relays the answer back — so a caller needs one address instead of a server per agent.
git-lex and Ravel are each complete on their own. Run Ravel as just a transcript store. Run git-lex over a folder of notes and never install anything else.
The rest builds on them when it is there and stays out of the way when it is not. There is no central daemon everybody has to run.
An agent's documents, media and transcripts live in the same folder, under an identity derived from the repository itself.
It sits on your machine. It is a directory you can open, read, copy and back up with the tools you already have.
RDF, OWL, SPARQL and SHACL over plain markdown in plain git. The storage format is readable without any of our software, and the graph is interoperable with the whole semantic web stack.