This page is not connected to a status source.
So it reports that, rather than showing five green dots. An availability figure nobody measured is a fabricated claim, and this site does not have a second kind of honesty to fall back on.
5 components, each reported separately.
API
No live sourceThe Django application serving every route. If this is down, nothing else matters.
This site is not connected to a status source, so it reports nothing about this component rather than assuming it is healthy.
AI runtime
No live sourceThe model runtime — Ollama on CPU, or vLLM where GPU serving is enabled. A failure here degrades to a previous healthy owned version rather than to an external model.
This site is not connected to a status source, so it reports nothing about this component rather than assuming it is healthy.
Retrieval
No live sourceThe vector store and the sparse index. Without it, high-risk answers have no evidence to stand on and the assistant abstains rather than guessing.
This site is not connected to a status source, so it reports nothing about this component rather than assuming it is healthy.
Document processing
No live sourceUpload, malware scanning, OCR and extraction. A failure delays intake; it does not affect answers already given.
This site is not connected to a status source, so it reports nothing about this component rather than assuming it is healthy.
Scheduled jobs
No live sourceCorpus refresh, source indexing, FX rates, monthly audit proofs and the nightly anomaly scan. Failures here surface as staleness rather than as an outage.
This site is not connected to a status source, so it reports nothing about this component rather than assuming it is healthy.
Why there is no uptime percentage here
Because nothing on this site measures one. A published availability figure is a measurement or it is a decoration, and a decoration shaped like a measurement is the most damaging thing a status page can carry — it is the number a procurement reviewer will quote back.
When a status source is wired, this board reports what it measures and this note goes away. Until then the honest answer is that this page cannot see production.
The status source that does exist is yours.
Every deployment exposes a readiness verdict behind ten gates, each with its own remediation text. For anyone self-hosting, that is the real answer to “is it working” — it describes the system you are actually running rather than somebody else’s.
- READY
All ten gates pass. High-risk workflows are enabled and answers are grounded against a promoted corpus release.
- DEGRADED
Some gates fail. Low-risk help stays available while high-risk advice is gated off — graduated capability disabling rather than an outage.
- NOT_READY
The deployment will not serve high-risk answers. A fresh environment correctly returns this; the per-gate remediation text says what is missing.
Incident history
No incidents have been published.
That is because none have been published — not because none have occurred and not because operations have been flawless. A seeded example incident with a date and a resolution would be a fabricated operational record, which is a worse claim than a fabricated uptime figure: it invents an event.
Be told, rather than checking.
There is no status-notification service to subscribe to yet, and a form that collected addresses for one would be collecting them for nothing. What does exist is the changelog feed, which covers changes to the contract you integrate against.
For anyone self-hosting, wire your monitoring to your own readiness endpoint. It is a better signal than an email from us would be, because it describes your deployment.
The gates, the versions and the gaps, published as they are.
Readiness is reported rather than asserted, and a gate that is not met is shown as not met. Read it before a demo rather than after one.
TaxOrch provides decision support, not professional tax advice. Exact results apply only within declared coverage. TaxOrch does not file returns or execute payments. Review all outputs before filing.