Day one: answers from your first call

You don't need history to start. The quickest way to your own model is to send the JSON you send Jev: it's ready in minutes. Day-one mode covers the time before that, and any question you haven't built a model for: a new domain, or a question it hasn't learned yet, is answered by your day-one backend, in the same shape, marked "source": "fallback". Your rules still apply through the decision block, and so does the safety check: a day-one answer below 0.8 confidence comes back "route": "review" and waits in the unsure queue instead of being acted on.

When a question has enough of your real outcomes (from uploads, /v1/outcomes and the unsure queue), it graduates to your own model automatically, question by question. Each graduation makes that question faster, cheaper to run and, in our tests, more accurate.

A starter model for decisions on text

A model you build from your Jev request reads text from day one, with no past cases. If you set up by describing the decision to the set-up agent instead, a question that reads text, such as what a message is about, or a routing decision like billing, shipping or account that depends on what the message says, can start with a starter model: train, and the question has a working model of your own on day one, with your rules enforced on every decision. There's nothing to set or ask for; it's used when it helps.

• Your rules still apply on top. A rule that says never still blocks, and a rule on your fields (like "escalate when amount is over 1,000") still decides the cases it covers.
• Say what each option covers when you describe the decision, like Question topic: billing (payments, invoices), shipping (delivery, tracking), account (login, password): it helps the starter model and day-one answers tell them apart.
• It learns your wording as you upload past cases or report outcomes. Each category moves over to your own cases once it has enough of them, and your recorded answers always win.
• Its accuracy is labelled. Until you have enough cases of your own, the report measures it on starter example cases (measured_on: "starter_cases") and says so: "Starter model: ready to use now. It learns your wording as you upload past cases or report outcomes; real accuracy appears once there are enough of them." From then on every number comes from your own held-back cases, and the never-worse check compares versions on those.
• Its automatic answers are more cautious while it's measured on starter cases: more of them are double-checked.
• You can remove the starter cases any time with DELETE /v1/domains/{domain}/uploads/starter (or Remove the starter cases on the Data tab). They then stay off for that model.

Decisions on data (numbers and fields only) don't need one: for them there's nothing to bring.

Coming from Jev?

The request and answer shapes are the same, so switching is a change of URL and model.

- POST https://api.typesafe.ai/v1/systemone   "model": "jev-latest"
+ POST https://api.canonopylabs.com/v1/systemone  "model": "support@latest"

A domain that doesn't exist yet is created in day-one mode on its first call, with the questions that call asks. A model that starts with jev- maps to your default domain.

Questions your model doesn't have

Ask a question your model doesn't have and it is answered all the same ("source": "fallback"). It doesn't join your model on its own: it's listed in the model's candidate_questions, and requests without questions keep asking only your model's own questions. Outcomes you report for it are kept. When you want it for good, add it to the model's questions with PATCH /v1/domains/{domain}; from then on it counts toward graduation like any other question.

Choose your backend

{ "provider": "typesafe", "api_key": "<your TypeSafe key>", "model": "jev-latest" }

Keys are stored encrypted, used only for that domain's fallback calls, and never returned: reads show has_key and the last four characters.

Offline: your own fallback, and sync later

A downloaded model can't call your day-one backend while it's offline. Give it a function of your own instead (your rules of thumb, or a small model you run): load("refunds@3.zip", offline_fallback=my_fallback). It answers the questions that need a second look when we can't be reached, marked "source": "local_fallback", with your rules still applied after it; None means review. The runtime also saves those cases on your machine, and model.sync() (or canonopy sync) sends them to your unsure queue later, so they count toward graduation like any other outcome once answered. See Running it yourself.

Graduation

{ "min_outcomes": 1000, "auto": true, "questions": {
    "action":  { "status": "trained",  "version": 3,    "outcomes": 5120, "needed": 0 },
    "urgency": { "status": "fallback", "version": null, "outcomes": 213,  "needed": 787 } } }

Outcomes come from your uploads, from POST /v1/outcomes and from answers in the unsure queue. Set graduation: {"min_outcomes": 1000, "auto": true} on the domain; with auto: false, you decide when to train. Graduation is checked each time an outcome or an unsure-queue answer comes in, so after an upload that takes a question past the mark, it graduates with the next one; or train it straight away with POST /v1/domains/{domain}/train.