A grab bag of questions about Remastery, each with a short answer.
Because what the system sells is provenance, and a plain folder is the easiest thing to audit that anybody has ever built. Each document has its own folder, named by its id. It holds the source as it arrived, every state the document has ever had, and an append-only log of what changed, when, and who approved it. That folder depends on nothing outside itself. You can read it with a text editor, back it up with zip, and hand it to someone in ten years who has never heard of this tool.
It also removes a whole class of failure. There is no schema migration that could rewrite history, and no single file whose corruption loses everything. Searches run against SQLite indexes, but those are derived from the folders and can be rebuilt from them at any time. The folders are the truth; everything faster is a cache.
Speed is less of a problem than you might think. Modern SSDs are very fast, and reading whole documents straight from a local disk, with no network hop in between, is quicker than most people expect.
The index can be replaced if a deployment needs it, and the main reason would be XPath queries over a large collection. Today, the SQLite index narrows down which documents to look at, but the XPath itself still runs on each of them. An XML database such as BaseX could take the place of that index and answer the XPath directly, which can be dramatically faster on more complicated queries. It would be filled from the folders and could be rebuilt from them, just like the index today, so the folders stay the truth.
Git is battle-tested, and it stores versions of files, so it is a fair question. There are two answers.
First, the undo that Remastery needs does not map well onto Git. Suppose one commit changed 500,000 documents, and later you want to undo only the 2% that one issue touched. git revert undoes the whole commit. You would have to pick the files by hand, and if a later change touched some of them for an unrelated reason, you would silently throw that change away. Remastery detects exactly that case and refuses rather than guess. That logic would have to be built on top of Git anyway.
Second, in a bespoke deployment, Git can replace the storage if an organisation prefers it. That is not a large job.
No. There is a great deal of XML still around. Some of it is waiting to be retired, but much of it matters: legislation, regulations, publications and technical documentation, often going back decades.
XML is also still good at what it was made for: mixed content, where structure and meaning are layered on top of running text. Its biggest problem was overreach, the attempt to make it the format for everything, including data that a simpler format handles better. For documents, it remains a sound choice. And a collection that has to move to a new format still has to be converted out of XML, carefully.
Today, yes: the workbench reads XML, and its checks (well-formedness, schema validity, text preservation) are XML checks. But the approach is not tied to XML. Any document collection that benefits from small, approved, reversible improvements with full provenance could work this way, and the storage and the log do not care what is in the files. Transforms can be written in Python or XSLT today, and adding another language is a small change. Adapting the workbench to another format is the kind of change we would make together.
Almost all of the time goes into the model, not into the workbench.
For a local model, check the hardware first. A model that does not fit in the memory of the graphics card runs partly on the processor, which is an order of magnitude slower. Also keep thinking off: a reasoning model writes out its reasoning before it answers, which can take longer than the answer itself. The workbench switches thinking off by default, and you can switch it on for one model if it gives better answers. Do not go much smaller to gain speed, though: below about 14 billion parameters, the answers are rarely good enough.
For a cloud model, try another model or another provider; the difference in speed can be large.
A check asks the model about every change, one request at a time, so a check over thousands of changes takes a while whatever the model. Run it in the background and do something else.
Not by default. For each model you set up, you answer one question: may this model see the project's documents, yes or no? The answer is no until you change it.
With no, the interactive mode sends your sentences and its command reference, but it keeps document text out of what it sends. The routes that need document content, such as the second opinion on a change, refuse to run rather than send anything. A model on your own network can be given a yes, and so can a cloud model, but only by a deliberate setting. You can check what is sent with an ordinary proxy, and I am happy to show you how.
No. The model never writes to a document. Every change is made by a transform: code, in Python or XSLT, that a person wrote, tested and approved. The model proposes commands, gives a second opinion on a change, or points at fragments that look odd; a person decides what happens.
Every test also checks whether the text survived the transform, character for character. A transform that changes words is caught before anybody approves it.
Nothing breaks. Each document is changed on its own, and each change is either complete or not made at all, so no document is ever half-changed. The job records which documents it has finished. Resume it, and it picks up the rest; the documents that are already done are not touched again.
Do you hold a large XML collection, and have good reasons to put AI to work on it, but no safe way to begin? Here is how we would work together. It starts with an hour online, no charge: we look at your own documents, and you see the system running on them.