The purchase page sells sovereignty. It doesn't sell an uptime plan.
I have been reading the Mentary AI page closely, and it makes one claim louder than any other: complete data sovereignty, zero external network reliance, no cloud, no telemetry. That is the pitch, and it is a good pitch. A law firm that cannot send privileged communications to a third-party API has a real problem, and Mentary AI is aimed squarely at that problem.
But sovereignty is a data property. It is not an availability property. And those two get confused more often than anyone admits on a sales page.
So this post is about the second one: what happens on the night the machine dies.
The failure nobody budgets for
A private inference deployment has a very different failure profile from a cloud one:
- A cloud outage is not your outage. Someone else's pager goes off. You retry, you complain on a status page, you wait.
- A local outage is entirely your outage. No status page. No retry budget from the vendor. Just you, a dead disk, and a person waiting on an answer.
The Mentary AI package lists what you get: complete pre-trained model weights, an optimized inference engine, automated deployment scripts, a production-ready Docker image with Compose orchestration, documentation, and 30-day priority support. That is a real, complete bundle — and none of it is a backup or recovery story. It is a deployment story. Those are different documents.
If you are evaluating Mentary AI for anything that has to be up, read the package list twice. Once for what it contains, and once for what it assumes you already have.
The thing that actually breaks first
Not the weights. Weights are large but they are static — you can copy them, checksum them, and rest easy. The part that breaks first is the part nobody thinks to snapshot:
| Component | Breaks how | How often it bites |
|---|---|---|
| Model weights | Disk corruption, incomplete copy | Rare — you can verify by hash |
| Inference engine / runtime | Library mismatch after an OS patch | Often — the classic "it worked yesterday" |
| Container image + compose config | Port changes, volume path changes | Often |
| Quantization / precision config | Recopied weights, different runtime version | Rare but silent — wrong answers, not crashes |
| Deployment scripts | Your custom edits | Constantly — this is the one you edit |
That last row is the real one. Everyone customizes the deployment scripts. Almost nobody versions them. So the recovery plan has to start with a question nobody asks on the demo page:
Do you have a copy of the environment you actually run, or only the environment you downloaded?
Those are not the same thing.
A recovery runbook that fits in one page
This is deliberately small. A recovery plan you cannot run at 2 a.m. from a phone is not a plan.
1. Checksum the weights once, and keep the file somewhere else.
# On the deployment host, right after delivery:
sha256sum model-weights.bin > ~/mentary-weights.sha256
# Store that single small file outside the deployment host.
# Email it to yourself. Put it in a note. It is 64 hex characters.
If the weights ever look wrong, that file is your only way to know whether the bytes are corrupt or whether the runtime is just loading them badly. Those two failures look identical from the outside.
2. Freeze the runtime before you trust it.
docker images --digests
pip freeze > ~/mentary-runtime-freeze.txt
Copy both out. If a patch bumps a library and inference breaks, you now know exactly which version to go back to instead of spending a weekend bisecting.
3. Keep two known-good copies of the container stack.
One is what you run. One is a .tar of the same image plus the compose file, stored somewhere that is not the machine. The demo page's compose orchestration gets you to a running container; it does not get you back to a running container after the disk dies.
4. Restore order, and test it in that order.
# 1. Restore weights, verify checksum
sha256sum -c ~/mentary-weights.sha256
# 2. Restore the image
docker load -i mentary-image.tar
# 3. Start the stack
docker compose up -d
# 4. Smoke test — a real query, not a health check
curl -s http://127.0.0.1:8080/health
Step 4 is the one everyone skips. A container being Up is not a model being correct. Run the same query you ran on day one and compare the answer. That is the only test that catches a wrong-precision restore.
5. Write the two commands you will actually type.
Not a 40-page DR document. Two commands: how to restore the weights, and how to bring the stack back up. Everything else is reference material for a Tuesday, not a Sunday 2 a.m.
Where 30-day support ends and you begin
The package includes 30-day priority support from the deployment engineering team — installation help, performance optimization, environment-specific issues. That is genuinely useful, and it is a real reason to buy rather than build.
It is also a time-bounded thing. After day 30, recovery is yours. So use those 30 days for exactly this: get the team to walk you through a restore. Ask them to watch you do it once, from your frozen runtime, on a machine that is not the production one. If you have never restored it, you do not have a backup — you have a hope.
That is the single highest-value thing you can do inside the support window, and it is not obvious from the purchase page.
The honest limits of the demo
The interactive demo on the Mentary AI page is a client-side simulation — keyword and pattern matching running in your browser, with a "0 bytes transmitted" badge. It is good for showing the shape of the interaction: type a query, get a structured, domain-flavoured response. It is not a benchmark of the model, and it should not be used to judge inference quality, throughput, or latency. Any capacity decision has to be made against your own hardware with the real weights.
Also worth being precise about: the page's privacy claims — zero telemetry, no external calls, data sovereignty — are about the architecture of the delivered deployment, not about a property I can verify from a product page. If your use case is a regulated one, that is a question to put to the vendor in writing before you buy, not something to assume from marketing copy.
The two questions to ask before you pay
- "If this host dies, what is my restore procedure and how long is it?" If the answer is a shrug, budget a weekend.
- "Can you walk me through a restore during the 30-day support window?" If the answer is yes, you have just turned a support period into a working backup.
Everything else — the weights, the engine, the container, the docs — is in the package, and it is a complete package. The gap is not in what they ship. The gap is that a sovereignty product still needs an availability plan, and that plan is yours to write.
Mentary AI — fully private, autonomous local AI model. One-time $299.99, lifetime license. Complete data sovereignty, bundled weights, runtime, deployment scripts, Docker image, docs, and 30-day priority deployment support. See the live interactive demo and full package list here: https://reggiebro.github.io/WorkflowAlpha.ai/mentary-ai/
To purchase, email [email protected] — that is the only contact method, and the team confirms price and payment details from there.
Payment options:
- PayPal — send $299.99 to our account email [email protected] (write a note; we confirm in the inbox). Buyer protection included.
-
Crypto — ETH, USDC, or USDT on the Base network, to
0x078fE079A9440631Bc6AD722D7143dC382b4ea4f - Western Union / MoneyGram — recipient details and MTCN verification provided after you confirm
After payment verification the complete package is delivered digitally.
Top comments (0)