Everything we've built.
Nothing we haven't.

Usage, stated exactly. 9 protective rules have run to a conclusion in the development database: 3 triggered on real executed size and placed their order (one of them is the order above) and 6 were cancelled by their owner before they ever fired. 0 are armed today, and 0 autopilot plans have ever been created here at all. We would rather decompose the count than let a total imply live cover that is not there (measured 23.08.2026; pg: select status, count(*) from stop_loss_orders → cancelled 6, executed 3).

Autopilot is one of the 6 engines but is not a separate row in the catalogue above: it ships inside Algo Trading and is gated by that one entitlement. One purchase, not a second SKU.

1. 01

   The broker never tells us an order filled, so we ask, and we never assume

   There is no fill callback here and no push of any kind. The one place this venue admits an execution is its own live order list, whose rows carry an executed quantity and an average price, and reading that list is the ONLY way a fill is ever written on this platform: a sweep and an on-demand endpoint copy what the broker says onto the order and write nothing else. The rules are deliberately unflattering. A partial stays “submitted”, because the rest is still working and still cancellable; a zero is never written as an observation; an order the broker stops listing is left alone, because absence is not evidence of a fill; a figure smaller than one already seen is reported as an anomaly instead of applied, since a fill cannot un-happen; and there is no backfill at all. That last rule is why the autonomous order above is still not called a fill (the reader was built after it) and why 0 orders here carry an observed execution today. Anything that depends on a fill, the recurring-buy plan for instance, reports “fill unknown” and waits rather than stacking real money on an order that may never have executed.

2. 02

   Our stop-losses live on our servers, not the exchange's

   The broker's verified order form has no stop-trigger field (the gateway raises if you try), so a stop is a rule our own monitor evaluates before placing a plain limit sell. The exchange never held it. If our monitor is down, the stop does not fire. We would rather you knew that from us than discovered it on a bad day.

3. 03

   We built the 10-rung order book; the venue serves an empty one

   The depth wiring speaks the terminal's exact call and the panel renders up to 10 rungs, but every call to that endpoint has come back empty with zeros. And every one of those calls, all of them, was placed outside trading hours. The in-session probe is still owed and we will not pretend otherwise. The one real live book is the exchange's public asking-prices file, the whole market in a single fetch, cached for seconds and shared across users, and that is what the panel honestly renders. If the in-session probe is also empty, the remaining step is a market-data entitlement request to the broker rather than code; until it runs, that is a hypothesis, not a fact about the venue.

4. 04

   We take payment by hand, on purpose (for now)

   The code for automatic collection exists: 3 operator protocols are implemented against their published specifications (Paynet UWS, CLICK's shop API and the Payme merchant JSON-RPC). 0 of them are switched on. What no operator hands out without a signed merchant agreement is the credential, so each adapter reports itself unconfigured and names the settings it lacks, and their callback endpoint answers 503 rather than pretending to confirm a payment. Xolis, the QR product people here actually use, publishes no developer API at all. So a purchase is a server-priced request, a reference QR that is explicitly ours and not provider-signed, an out-of-band payment, and a human approval that creates the time-boxed grant. It does not scale to a hundred thousand users and we know it: the code is written, the agreements are not.

5. 05

   Copy trading is opt-out, not opt-in

   A user's profile allows their trades to be mirrored by default (the leaderboard would be empty otherwise), under an alias, never an email, and the switch is in settings. We would rather volunteer that here than have a privacy reviewer find it.

6. 06

   The insurance register has a captcha, so we record, not verify

   The state register of compulsory insurance policies, ersp.e-osgo.uz, requires a captcha and offers no API. We record what the policyholder saw and link to the authoritative register; we do not claim an automated verification we cannot perform. What we did build behind that limit is an import keyed on the register's OWN identity, the series and number it prints (e.g. EUID 0386126): pasting the same block twice updates one policy instead of minting a second, a legacy row still matches by its alphanumeric-reduced policy number, the fields the register does not know (surrender value, beneficiary, private notes) are never touched, the premium is never silently rewritten, and every field the paste does change is reported back with its old and new value.

7. 07

   There is no e-filing API, so the taxpayer files

   The taxpayer cabinet offers no public API for submitting the declaration. Finmind computes and renders the exact document, in the authority's own notation, and the taxpayer files it. We will not pretend to a submission channel that does not exist.

8. 08

   Some statutory numbers are unknowable right now, so we say “pending”

   Several caps in the tax code are multiples of decree-set amounts that are not always published in advance. When a decree is missing, the affected rows render as pending with an explanation. A declaration that quietly guessed would be worse than one that waits.

9. 09

   The deterministic parser is proven; the language model is not

   The assistant understands money instructions through a deterministic intent parser that runs FIRST and handles everything it recognises: holdings, net worth, prices, orders, standing plans. The language model only sees what that parser did not understand, anything it proposes is rebuilt by the same proposal builders and still requires the user's explicit approval and the same order validation, so no order-safety property depends on the model. What we have not done is prove the model half end to end: the API key in the container has never been probed live, and if the provider rejects it the assistant falls back to the parser silently. We would rather tell you that than let you assume an LLM you have not seen work.

10. 10

    We have no traction metrics to show you, so this page shows none

    No user counts, no AUM, no revenue claims, no testimonials, no logos. What we can demonstrate is the running system itself, every feature in the catalogue above, driven live, with its own gaps named as we reach them. We would rather earn the other numbers than assert them.

Contact details read from the platform's own public settings as this page rendered. Change them in the admin surface and they change here.