Answers the way we would give them in a room.

Less than you expect, and that is by design. The baseline dynamics carry most of the state, so the platform produces useful forward state from your domain definition alone. The learned component earns trust over time. A month of events is usually enough to judge whether the learned correction is adding anything in your domain, which is the real question.

We do not publish a deployment timeline, because a range is only honest once enough implementations have completed to support one. What we can say without hedging: because a domain is a definition rather than a code change, standing up a new world does not require an engineering release.

No. The platform is read-mostly by default. It consumes events and reference data, and it acts only through explicit, audited actions. There is no background write path.

One domain (the thing your team already argues about weekly), a sample of real events, and the answer to “how far ahead do you need to be right?” That is a working session.

One domain, a sample of real events, a declared horizon, and a model record you can read, including where it loses. The steps are on get started.

That is the wrong question, so we will answer the right one: the platform reports forward error at the horizons you declare, against a naive persistence baseline, and tells you the furthest horizon at which it still wins. That is a number you can check, on your data, before you commit. See the evaluation methodology.

Then the model record will tell you, and the promotion gate will refuse the model. You are told early, on a small evaluation, rather than late, after an integration. That is a deliberate design choice, and it costs us deals.

No, but not because there is no learned component. There is one. It is attributable: a bounded correction to a known baseline, its contribution shown per metric, its internal state inspectable, its trust weight configured per domain, and its error published per horizon. We do not claim “no black box”. We claim you can always see what happened.

No. There are no tokens, no prompts and no generated text anywhere in the platform. Conclusions are derived from explicit state and evidence, so the same inputs produce the same conclusion. See explainable AI.

No, and we do not sell it that way. It changes what they spend their day on: from triaging a queue sorted by an unexplainable score to working a queue ordered by value at stake, with the evidence and the price attached.

Three things, all by design:

• The state still moves correctly under baseline dynamics, so the failure is a missed correction rather than nonsense.
• The error is visible as a divergence between predicted and observed state.
• Every recommendation carries its evidence so a human can overrule it, and the overrule is recorded.

No. Your warehouse stays your system of record. The platform consumes from it and does not become it. See integrations.

Yes. The engine runs locally in the browser, so the what-if uses the same engine and the same world definition as the server, with no round trip. It needs to load the engine once, on first use. See low latency.

Yes, and it is handled explicitly rather than papered over. State advances by observed elapsed time, not by position in a sequence, so irregular reporting is normal. Gaps longer than the ceiling the model was trained on trigger a documented fallback instead of an extrapolated guess.

Isolation is enforced by row-level security in the database, not by application filtering. If isolation lived in application code, a single missing filter would be a cross-tenant leak; pushing it into the database closes that failure mode. See cloud native.

A built-in simulated world in the demo edition, used to evaluate the platform at a realistic entity count without touching your data. It exists only in the demo edition, so a production deployment cannot accidentally run a fictional world.

Dashboards describe the past; this adds a forward position for each entity and a price on the action. We sit downstream of your warehouse and your BI, and we do not replace them. See how it compares.

No. A rule answers “did this cross a line?”; a state model answers “where is this going?” Customers typically keep their rules and gain the ordering and the pricing above them.

Anomaly detection gives a score against a static notion of normal. A state model gives a position, a direction, a measured horizon and a price. A score is not a decision. See early warning.

Probably a version of it. The honest question is what has to be built around it: per-entity state at scale, irregular-time handling, a baseline so it works before there is history, a promotion gate, evidence fusion that keeps conflict, tenant isolation and an audit trail. See how it compares.

AnantState is enterprise software, licensed as an annual subscription and deployed in your own infrastructure. We do not publish prices, and we do not quote before we understand the scope: it follows the domains and entities you model. See how pricing works.

One domain. We would rather you evaluate narrowly and succeed than buy broadly and stall.

That is what the evaluation is for: one domain, a sample of real events, and a model record you can read. If the record does not beat persistence at your horizon, the honest answer is that we are not the right fit yet, and we will say so.

That is a contractual position and not something a web page should assert. Ask us and we will give you the current terms in writing, before you start.

The trust page lists what the platform enforces and states plainly what it does not claim. We do not state or imply a certification on this site. Ask us for the current status in writing.

Yes. Bring the questionnaire to a security review conversation. Walking a reviewer through the tenancy layers and the audit trail is faster than a document.

There is no path by which one tenant’s data can reach another’s: isolation is enforced in the database, and there is no shared calibration store between tenants. See cross-domain connection. The contractual position is available on request, in writing.