Loading

TypeSafe Jev

Typed AI decisions from TypeSafe Jev: switching it on, the console and playground, AI workflow steps, Is about (AI) message rules and Feed Queue suggestions.

What TypeSafe Jev Is

TypeSafe Jev is a decision model from TypeSafe AI. You give it some text or data and one or more typed questions, and it answers every question at once with probabilities, usually in well under a second. It never writes text.

The platform uses it wherever something has to be decided rather than written: which way a workflow goes, whether an incoming message is about a particular thing, and which account a bank line should be coded to.

Where to find it

Architect Panel → Activity:

  • TypeSafe Jev — the console: status, connection check, test call, playground and recent calls

Architect Panel → Automation:

  • Workflow Builder — the AI decision and AI check steps

Architect Panel → Communication:

  • Inbound Messaging — Is about (AI) rules on SMS and WhatsApp routes

Architect Panel → ERP - Finance:

  • Feed Queue — account and tax code suggestions for bank and accounting feed lines

Three kinds of question

  • Choice (pick one). Choose one of 2 to 255 options you supply, such as which team should handle a ticket. The answer is the option chosen, a probability for every option and a confidence.
  • Score (ordered levels). Place the input on a scale of 2 to 10 levels, lowest first, such as how frustrated a customer is. The answer is the most likely level, a score that can fall between two levels, and a confidence.
  • Yes / no. How likely a plain-English statement is to be true, such as "The customer is asking for a refund". The answer is one probability between 0 and 1.

Every question is answered from what you send and nothing else. Jev has no access to your database and does not look anything up.

The answer says what; the confidence says whether to act

Each feature turns Jev's answer into an outcome before acting on it:

  • Choice or score: confident when the confidence reaches the bar (0.6 unless you change it) and, for a choice, the lead over the runner-up reaches its minimum; otherwise review.
  • Yes / no: yes at a probability of 0.75 or more, no at 0.25 or less, review in between.

Review means a person decides. These figures are starting points: tune them against your own examples, and do not carry a bar tuned on a yes/no question over to a choice, because the two are not comparable.

A failure is never treated as an answer. If Jev is switched off, unreachable or refused by the AI budget, each feature falls back to its safe behaviour: a workflow step goes to a person, a message rule does not match, and a bank line gets no Jev suggestion.

Jev or the AI gateway?

Use Jev when the platform needs a decision it will act on: route something, pick a value from a list, flag a record, or hold an action until a probability is high enough. Use the AI gateway when you need text: a summary, a draft reply, extraction into free-text fields or code. Jev is deliberately not one of the gateway's providers, so it never appears in a Send to AI menu or in the list of providers a feature can use.

What leaves your installation

TypeSafe AI is a third-party processor. Whatever a feature puts in front of Jev is sent to TypeSafe, so every use has its own opt-in and sends only what it needs:

  • Workflow steps send only the fields listed on the step. Listing them is the decision.
  • Message rules send message text only from routes whose Allow AI conditions switch is on.
  • Feed Queue suggestions are sent only when the installation and the tenant have both switched them on.

Passwords, encrypted fields and system columns are never sent by any of them. Before you switch on anything that sends personal data, add TypeSafe to your privacy notice and check its terms on retention.

Limits worth knowing

  • Text only. Jev reads text and structured data, not images or files.
  • It reads instructions literally. Put boundary cases in the options, and offer a "none of these" option where nothing may fit.
  • It is unreliable at arithmetic, counting and comparing dates. Do those in a workflow Condition step or a rule, and ask Jev only for the judgement.
  • Less is more. Accuracy falls as unrelated detail grows, so send the fields the question needs and no others.
  • Input can argue its own case. A message may be written to look like something it is not. Keep consequential actions behind a confidence bar, with a person deciding below it.

Worked example

A housing association's repairs team switches Jev on and tries its questions in the playground first. On the repairs text number, an Is about (AI) rule with the statement "The sender is reporting a leak or flooding" routes matching messages to the urgent work queue, with a keyword rule kept alongside it. On new repair requests, a workflow AI decision chooses a trade (plumbing, electrical, joinery or none of these) from the description field alone. Confident answers set the Trade field; everything else goes to the supervisor's queue. The privacy notice names TypeSafe as a processor before either goes live.

Recommendations

  • Try every question in the playground with real, awkward examples before a feature depends on it.
  • Always give review a destination. A person should see what Jev was unsure about.
  • Send the minimum. It is better for accuracy and better for data protection.
  • Record each opt-in: which fields, which routes, which tenants, and who agreed.
  • Pin the model version once you have tuned a bar against it, so a new release cannot move it under you.

Turning Jev On and the Console

Jev sends nothing until it is switched on with an API key. The TypeSafe Jev console shows whether it is ready, proves the connection, and lists the calls your features have made and their cost.

Where to find it

Architect Panel → Activity:

  • TypeSafe Jev — status, Check connection, Test call, the Playground and Recent Jev runs
  • AI Usage — every Jev call with its cost, listed under the service TypeSafe Jev
  • AI Run Log — the run rows themselves, read-only

Architect Panel → Configuration:

  • AI Settings — the TypeSafe Jev section of the AI configuration file
  • Platform Modules — the AI module, which hides the console when switched off

Switching it on

Jev's settings live in the installation's AI configuration file, the same file the AI gateway uses. Only two are required.

  1. Get an API key from TypeSafe for this installation, under an organisational account rather than a person's.
  2. Set it. Open AI Settings, go to the TypeSafe Jev section, tick Switched on, paste the key into API key and click Save. If the screen says This screen cannot change the file, ask your hosting administrator to set the same two values in the AI configuration file.
  3. Open the TypeSafe Jev console and check that the Status card shows Ready to call: Yes.
  4. Click Check connection. It asks TypeSafe which models your key may use. It is free and is not logged, so it proves the key and the network path without spending anything.
  5. Click Test call. It sends one small fixed request: a customer message and three questions, one of each type. It is a real, billed call of about 450 input tokens, logged as admin.testcall.

The other settings

All optional; the labels are those on AI Settings.

  • Model: blank means jev-latest. That and jev-preview are aliases that follow TypeSafe's releases. Once you have tuned a confidence bar against a version, pin it, for example jev-1.13.0.
  • API address: blank means TypeSafe's own. Set it only to send calls through a proxy, and give the host only, with no /v1. The console never shows it.
  • Timeout (s) and Retries: per attempt. Inside a page request Jev gets 10 seconds an attempt, one retry and 15 seconds in all; background work gets 30 seconds and two retries, unless a feature sets tighter limits of its own. These settings can lower the page figures but never raise them.
  • Calls per web request (100) and Seconds per web request (30): ceilings for one page request.
  • Input price and Output price: used only for the run log's cost estimate.
  • Playground on the Jev console: untick to hide the playground and refuse its calls.

The messaging threshold and the three Feed Queue settings are covered with those features.

Reading the Status card

The card is read-only and never shows the key or a custom address. Ready to call is Yes only when Jev is switched on, has a key and has a usable address; when it says No, nothing is sent and every feature behaves as though Jev were unavailable. AI budget: Checked means the budget is asked before every call, and Run logging: Off means calls are made but not recorded.

When the test call fails

A failure shows a code and a hint:

  • not_configured: switched off, no key, or an API address that is not an http(s) URL. Nothing was sent.
  • auth: TypeSafe refused the key. HTTP 403 means no key reached it; 401 means a key it does not accept.
  • not_found: with HTTP 404 the API address is wrong (it must not end in /v1); otherwise TypeSafe does not know the model named.
  • timeout or connection: check that the server can make outbound HTTPS calls to TypeSafe, through any proxy and DNS.
  • rate_limited, overloaded or provider_error: TypeSafe is busy or failing. Try again shortly.
  • budget_exceeded: the AI budget refused the call, so nothing was sent.

Cost, the run log and the AI budget

Every Jev call writes one row to the AI run log, with any retries counted in that same row. The feature column says what asked: admin.testcall, jev.playground, workflow.decide, messaging.condition or erpfeed.suggest. The Recent Jev runs card lists the latest ten for your account, with When, Feature, Outcome, Model, input tokens, Cost and time taken; Open shows a run in AI Usage, and All Jev calls in AI Usage opens the last 30 days.

Each decision is individually very cheap, so costs are shown to six decimal places. One row's figure is approximate; totals over many runs are reliable. Failed calls and budget refusals are recorded at zero cost. While Jev is switched off nothing is sent and nothing is recorded.

The AI budget is checked before every call. A refusal sends nothing and is recorded with the code budget_exceeded. The run log keeps Jev's answers but not what was sent, unless Keep the request is on in the run log section of AI Settings. Usage, credit and budgets in general are covered in AI Usage & Run Log and AI Credit & Spend Limits.

Worked example

An architect opens the console on a new installation and sees Ready to call: No, with a warning that Jev has no API key. They save the key in AI Settings, reload, and Check connection lists the models the key may use. The test call answers all three questions and appears in Recent Jev runs. Only then do they build the first workflow step that relies on Jev.

Recommendations

  • Make the first call yourself, rather than letting a live feature discover a bad key.
  • Use Check connection after any change to the key or address: it costs nothing.
  • Pin the model once a bar has been tuned against it.
  • Check Recent Jev runs weekly at first: a run of errors means a feature is quietly falling back.

The Playground and Writing Good Questions

The playground lets you put a question to Jev about sample text before any feature depends on it. It is where you find out whether a question is worded well enough to trust, and what confidence bar it needs.

Every playground call is real, billed and logged under the feature jev.playground.

Where to find it

Architect Panel → Activity:

  • TypeSafe Jev — the Playground card, below Check the connection

The card is missing when Playground on the Jev console is switched off in AI Settings.

Asking a question

  1. Write the state. This is the text or data the questions are about, such as a customer message. Choose Text, or JSON (an object or an array) to send several labelled values. The counter shows how much of the 20,000-character limit you have used.
  2. Choose the model. Default uses the installation's model. You can also pick jev-latest, jev-preview or A pinned version and type one such as jev-1.13.0.
  3. Set up each question. Give it an Id (letters, digits, _ . : -, up to 64 characters), a Type and its Instructions, which say what Jev is being asked.
    • Choice (pick one): under Options, one per line as key: description. A colon followed by a space separates the two, so keys such as 09:00 or GB:VAT20 keep their own colons. The description is optional; up to 100 options.
    • Score (ordered levels): under Levels, one per line, lowest first, 2 to 10 of them.
    • Yes / no: the instructions are the statement. What "yes" means and What "no" means are optional.
  4. Add a question for more, up to 20 in one call, or Remove one.
  5. Click Ask Jev.

If anything is wrong, such as a duplicate option or a score with one level, the result says Not sent and lists the problems. Nothing reached TypeSafe, so it cost nothing and was not logged.

Reading the result

  • Each answer shows a bar and a percentage for every option or level, with the winner highlighted. A choice gives its confidence and its margin over the runner-up; a score gives the score and the most likely level; a yes/no gives the probability that the statement is true.
  • The outcome badge (confident, review, yes or no) uses the starting bars: 0.6 confidence for a choice or score, and 0.75 and 0.25 for yes and no. A sentence underneath explains it.
  • The call details: the model that answered, TypeSafe's request id (quote it to TypeSafe if you need their help), tokens, cost, attempts, duration and the run, linked to AI Usage.

Writing good questions

  • Send only what the question needs. Accuracy falls as unrelated detail grows. A subject and a description beat a whole record.
  • One narrow judgement per question. Ask "which team" and "is it urgent" separately, then combine the answers in a workflow.
  • Say exactly what you mean. Jev reads literally. Put the boundary cases in the option descriptions ("Payments, refunds and invoices; not pricing questions"), and add a none of these option whenever nothing may fit.
  • Keep arithmetic out. Counting, sums and date comparisons belong in a Condition step or a rule. Ask Jev for the judgement only.
  • Assume the text was written by a stranger. A message can claim to be urgent or argue for its own category. Test examples that try.

Calibrating the bar

Run a dozen real examples through the same question, including the awkward ones, and note the confidence each time. Where right answers cluster above a figure and wrong ones fall below it, that figure is your bar. Write the model version down beside it: a bar tuned against one version may not hold on the next, which is why the Model setting can be pinned.

Taking it into a feature

  • Workflow AI decision: the instructions, options and levels go into the step's Instructions, Choose from and Levels, lowest first. The bar goes into Sure enough at.
  • Workflow AI check: the statement goes into Statement to check, with Yes means and No means.
  • Is about (AI) message rule: test the statement as a yes/no question with a real message as a text state. Rules allow up to 500 characters.

Worked example

An operations lead wants a workflow to route customer enquiries by intent. In the playground they paste a real message, add a choice question with exchange, refund, track and other, and ask Jev. It picks exchange at 91%. They try twelve more messages; the two it got wrong both scored under 70%, so they set the workflow step's Sure enough at to 0.75 and pin the model the console reported.

Recommendations

  • Use real but harmless examples. The playground sends what you type to TypeSafe, so leave out names and account numbers.
  • Test the edge cases, not just the easy ones.
  • Keep the wording you settle on and copy it exactly into the feature.
  • Re-test after a model change before trusting an old bar.

AI Decision and AI Check Workflow Steps

Two workflow steps put a typed question about a record to TypeSafe Jev and branch on the answer. AI decision picks one option from a list, or a level on a scale; AI check asks how likely a statement is to be true.

This article covers adding and configuring them. For the builder in general, see Workflow Builder.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — the AI decisions group in the step palette

Architect Panel → Activity:

  • TypeSafe Jev — the playground, for working out the wording first

Before you start

The AI decisions group appears in the palette only while the AI module is switched on under Platform Modules. If Jev itself is not set up, the group shows the note Needs TypeSafe Jev, which is not set up on this installation and its steps cannot be added. A workflow that already has AI steps still loads and runs, but every one of them goes down Needs a person.

Adding an AI decision

  1. Drag AI decision from the AI decisions group onto the canvas and connect it after the step that should come before it.
  2. Decide: choose One of a list of options or A level on a scale.
  3. Decide about: the record the workflow runs on, or the current row of a For each step. Choose the row only when this step sits on that For each's each row path; the builder reports an error otherwise.
  4. Instructions: what to decide, in plain words, such as "Which team should handle this request?".
  5. Send these fields: pick each field Jev should see and, if you like, a label for it. At least one is required. Nothing else about the record is sent.
  6. Notes (optional): a fact the fields do not carry. Notes are sent first and may use placeholders.
  7. For a list of options, set Options to Written here and fill in Choose from (an Option and What it means, 2 to 255 rows), or to The options of a pick-list field and choose a drop-down or radio list under Pick-list field.
  8. For a scale, fill in Levels, lowest first, one per line, 2 to 10 of them.
  9. Sure enough at: the confidence, from 0 to 1, below which the run goes down Needs a person. Blank means 0.6. For a choice, Lead over the next option can also require the winner to be ahead of the runner-up by a margin.
  10. Connect both ports: Sure and Needs a person.

Adding an AI check

  1. Drag AI check onto the canvas and set Decide about.
  2. Statement to check: one plain sentence, such as "The customer is asking for a refund".
  3. Send these fields and, optionally, Notes, as above.
  4. Yes means and No means (optional): what counts as true and as false.
  5. Yes at (blank means 0.75) and No at (blank means 0.25). No at must be below Yes at; between the two a person decides.
  6. Connect the ports: Yes, No and Needs a person.

Both steps also have Save the answer as, Also write the answer to, Write it and an optional-failure tick box, covered in Branching on the Answer, and When Jev Cannot Answer.

What is sent, and what never is

  • Only the listed fields, each under its field name or your label. Pick-lists and tick boxes go as their option names, not their stored numbers.
  • Never sent: ID and other system columns, password and secret fields, encrypted fields, and anything that is not a defined field of the datastore. Listing one is a validation error.
  • Reference fields (a user, a file, a relational drop-down) are sent as stored, which is usually a number. The builder warns you; send a field that holds the words instead.
  • HTML is stripped from rich text and code fields. What you write in the instructions and options is sent as written.
  • A field placeholder in the instructions or statement is not pasted into the question. The question shows the field's name in brackets, such as [Subject], and its value goes with the data, so a record's own text can never rewrite the question. Write the question about the field by name.
  • A whole row, such as {{customer}} or {{record}}, is never sent, even in the Notes. Name the field: {{customer.name}}.
  • Empty fields do not count. If every listed field is empty and there are no Notes, no call is made and the step goes down Needs a person.

Worked example

A support desk adds an AI decision to its new-ticket workflow. Decide is set to one of a list of options; it sends only Subject and Description; the instructions read "Which team should handle this ticket?"; and Choose from lists billing (payments, refunds and invoices), technical (bugs and integrations), sales (pricing and new accounts) and none (none of these). Sure enough at is 0.7. Sure leads to a Condition: when decision.choice is none, a Notify step tells the duty lead; otherwise an Update record step sets Team to {{decision.choice}}. Needs a person leads to the same Notify step.

Recommendations

  • Work the wording out in the playground before you build the step.
  • Send two or three fields, not ten. Accuracy and privacy both improve.
  • Always offer a "none of these" option when the list may not cover every case.
  • Connect Needs a person every time, to someone who will act on it.

Branching on the Answer, and When Jev Cannot Answer

An AI decision or AI check step is only as good as what you connect after it. This article covers branching on the answer and its confidence, writing the answer back to the record, and what happens when Jev cannot answer.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — the step's ports and its Save the answer as and write-back settings
  • Workflow Run History — what each AI step decided, and why

Architect Panel → Activity:

  • AI Usage — each step's call, under the feature workflow.decide

The ports

  • AI decision: Sure when the answer clears Sure enough at (and any Lead over the next option); Needs a person otherwise.
  • AI check: Yes at or above Yes at, No at or below No at, Needs a person in between.

Needs a person is also where every failure goes, so it is never optional in practice.

Branching on the answer

Sure tells you the step is confident, not what it chose. To route by the choice, follow Sure with a Condition step and type the answer's name as the field: decision.choice equals billing, for example. For a scale, test decision.level, where 0 is the lowest level. When the options come from a pick-list, decision.choice holds the option's stored number, so compare decision.label with the option's name using contains.

To act automatically only on very confident answers, either raise Sure enough at, or keep it and add a Condition on decision.confidence (0 to 1), sending answers above, say, 0.9 straight on and the rest to a person to confirm.

Using the answer in later steps

Save the answer as names it; blank means decision or check. Use a different name for each AI step in the same workflow. The placeholder picker in later steps offers:

  • {{decision.label}}: the answer in words. For an AI check, {{check.label}} is your Yes means or No means wording (or simply yes or no), and empty when unsure.
  • {{decision.choice}} or {{decision.level}}, and {{check.noul}}: the option, the level, or the probability that the statement is true.
  • {{decision.confidence}}: how sure, from 0 to 1.
  • {{decision.outcome}}: confident or review (yes, no or review for a check), or error when Jev did not answer.
  • {{decision.why}}: one sentence explaining the outcome, useful in a notification to the person reviewing.

Writing the answer back

Also write the answer to puts it in one field of the record (or of the For each row): the option key for a choice, the level's position for a scale (0 for the lowest), and 1 or 0 for a check. Write it is either Only when the answer is sure or Always; with Always, an unsure check is written as 1 when the probability is at least a half.

In a workflow that runs before the save, the value is set on the record being saved. Otherwise it goes through the same audited path as an Update record step, so rules, field security and validation apply. A pick-list field accepts only a choice made from its own options, and system, secret and encrypted fields never take an answer; the builder's checks report both.

When Jev cannot answer

The AI module switched off, Jev not set up, the AI budget spent, no reply in time, or a step misconfigured: in every case the step is marked failed, {{decision.outcome}} is error, the reason is in {{decision.why}}, and the run carries on down Needs a person. What happens when nothing is connected there depends on the tick box If TypeSafe Jev cannot answer and nothing is connected to 'needs a person', finish the run instead of failing it:

  • Unticked: the run fails. In a workflow that runs while the record is being saved, the save is refused.
  • Ticked: the run ends there and the save goes ahead, without the answer.

An answer that is merely unsure, with nothing connected to Needs a person, simply ends the run. The builder's checks warn about each of these shapes.

Loops, schedules and outages

  • Inside a For each the step asks once for every row: one call, and one charge, each. Set Decide about to the current row, or every row sends the same record and gets the same answer.
  • A scheduled run with no record of its own needs its AI steps to decide about a For each row; the builder reminds you. Where a schedule runs once for every matching record, each record is one call, and the builder says how many.
  • In background work each step waits at most 10 seconds an attempt, with one retry and 15 seconds in all. After a failure that the retry did not cure, later AI steps fail straight away for up to five minutes, sending nothing, so an outage cannot hold up other scheduled work.

Testing

Simulate makes no AI call: you choose which way each AI step goes. Run for real makes the call. Afterwards, open the run in Workflow Run History: the step's detail gives the sentence explaining the outcome, the model, the input tokens, any field held back and anything written. Both screens are covered in general under Workflow Builder.

Worked example

A lettings team's workflow runs whenever a tenant message is created. An AI check, "The tenant is reporting a repair", sends only the message text. Yes creates a repair job, No ends the run, and Needs a person notifies the duty officer with {{check.why}}. When the AI budget runs out one Friday, every message goes down Needs a person, so nothing is lost: the duty officer sorts them by hand until the budget is topped up.

Recommendations

  • Connect Needs a person in every AI step, to someone who will look.
  • Decide deliberately about the optional box in before-save workflows: ticked, a failed AI step can never block a save.
  • Name each answer when a workflow has more than one AI step.
  • Prefer scheduled work for volume: a For each over thousands of rows is thousands of calls.

Is About (AI) Message Rules

An Is about (AI) rule lets an inbound SMS or WhatsApp action fire on what a message means rather than the exact words in it. You write a plain-English statement, such as "The sender wants to reschedule their appointment", and Jev says how likely it is to be true of each message.

Routes, actions and the other rule types are covered in Receiving Messages.

Where to find it

Architect Panel → Communication:

  • Inbound Messaging — a route's Allow AI conditions switch, and the rules on each action
  • Received Messages — every message, with its AI Rule Scores

Architect Panel → Configuration:

  • AI Settings — Messaging rule threshold, in the TypeSafe Jev section

How a rule is decided

The rule matches when the probability that its statement is true reaches the Messaging rule threshold: 0.75 unless your installation has changed it, and never below 0.5 or above 0.99. Set to inverted, the rule holds only when Jev is confident the statement is not true: at or below 0.25 with the default threshold. A message in between matches neither way round.

All the AI rules on a route's enabled actions are asked about in one call per message, so ten rules cost barely more than one.

Setting one up

  1. Allow the route. In Inbound Messaging, click Edit on the route. Under Behaviour, tick Allow AI conditions and save. This is the decision that message text arriving on this route may be sent to TypeSafe AI, so make it with whoever answers for that number. The route list then shows that AI conditions are allowed.
  2. Open the action, or add one, and choose what it should do under Do this.
  3. Add the rule. Under Rules, set the component to Message body, the comparison to Is about (AI), and type the statement in the value box: one plain sentence, at most 500 characters. Leave it as written, or choose inverted.
  4. Set Rule matching, Stop after this action and Order as for any other action.
  5. Save. The action is refused if the route does not allow AI conditions, the rule is not on Message body, the statement is empty or too long, or the action is Add to or remove from the opt-out list.
  6. Send a test message from a real handset and look at its AI Rule Scores in Received Messages.

If Jev is not set up, the route and action editors say Is about (AI) rules will never match. Rules can still be saved, but an action that has one will not fire.

What is sent

  • Only the sender's own words: the message text, a caption on a picture, video or document, or the label of a button or suggested reply they tapped. Up to 4,000 characters, with the channel and the message type.
  • Never the sender's number or name, or the record the message matched.
  • Location shares, contact cards, stickers, voice notes and reactions are never sent, and an AI rule does not match them.

It fails closed

If Jev could not be asked or did not answer (not set up, the route not allowed, no text, a timeout, the AI budget spent) the whole action that carries the AI rule does not fire, even when the rule is inverted. If that action has Stop after this action ticked, the actions after it do not run either, so a catch-all action cannot act on a message the AI action should have taken. A low score is an answer, not a failure.

During an outage, after two failures in a row the drain stops asking Jev until its next run. AI rules never touch the opt-out: STOP, START and HELP are handled before any rule is read.

Reading AI Rule Scores

Open the message in Received Messages. AI Rule Scores holds the probability for each AI rule, keyed by the rule's ID, together with the threshold applied, the model that answered and the run ID that carries the cost. When Jev was not asked or did not answer, it holds the error instead, and it notes when an unscored stop action ended the chain. It is empty when the route has no AI rules.

Worked example

A clinic's appointment-reminder number allows AI conditions. Its first action, "Reschedule requests", has the rule Message body Is about (AI) "The sender wants to change or cancel their appointment" and routes the message to the bookings work queue, with Stop after this action ticked. A second action with no rules sends an automatic reply. When TypeSafe is unreachable one morning, messages are not auto-replied to in error; they wait, unrouted, for the bookings team's daily check of Received Messages.

Recommendations

  • Prefer routing by number where you can, and use AI rules for what is left.
  • Keep keyword rules for safeguarding. An AI rule does not fire when Jev is unavailable, so a crisis keyword rule should stand alongside it, not be replaced by it.
  • One idea per statement. Two short rules beat one long one.
  • Check AI Rule Scores weekly at first, and adjust statements that score close to the threshold.
  • Add TypeSafe to your privacy notice before allowing AI conditions on any route.

Feed Queue Coding Suggestions

When no coding rule matches a bank or accounting feed line, the Feed Queue can ask Jev to choose the nominal account and tax code from your own chart. Jev picks from the accounts it is shown, so it cannot invent one, and its answer is only ever a suggestion.

The queue, rules and posting are covered in Accounting & Bank Feeds.

Where to find it

Architect Panel → ERP - Finance:

  • Feed Queue — Suggest an account on a line, or Rules, then ask AI for the queue

Architect Panel → Configuration:

  • AI Settings — the installation's switch and bars, in the TypeSafe Jev section

Admin Panel → Finance:

  • Bank Feeds & Reconciliation — the same queue, for finance staff given the tile

Off unless two switches are on

Bank descriptions often contain people's names, so Jev is used for a company's feed coding only when both of these say so:

  1. The installation. Jev must be switched on with a key, and ERP Feed Queue suggestions ticked in the TypeSafe Jev section of AI Settings (or set by your hosting administrator in the AI configuration file).
  2. The tenant. The tickbox Feed Queue: Coding Suggestions by TypeSafe Jev on the tenant's instance configuration screen, which opens under the heading Customisation. Tick it and click Save. It is off by default and is saved for your own tenant only.

The second switch exists because one configuration file serves every tenant on a shared installation: one customer agreeing to a new processor must not send every other customer's bank lines. Tick it only once TypeSafe is in your privacy notice. With either switch off, suggestions come from your rules and, where one is set up, the AI gateway, exactly as before.

The order things are tried

  1. Your coding rules, highest priority first. A matching rule always wins and Jev is not asked.
  2. Jev, when both switches are on.
  3. The language model through the AI gateway, when Jev cannot answer or is not sure enough, and when Feed: fall back to the language model is ticked (it is by default) and a provider is configured for the Feed Queue.

What is sent

The line's date, description, counterparty, amount (as a positive figure, with whether it is money in or money out), currency and document type, plus up to 40 recently coded descriptions with the accounts they went to. The question lists your company's accounts and the tax codes valid on that date. The payment reference is never sent, and a field you have marked for encryption is sent blank.

What comes back

  • The account must be in the company's chart. If its confidence is below Feed: account confidence (0.5 by default) the language model is asked instead; if that gives nothing, Jev's answer is still offered, with its confidence.
  • The tax code must be valid for the company on that date. If Jev says none, or its confidence is below Feed: tax code confidence (0.6 by default), the tax code is left blank rather than guessed.
  • Nothing is posted. The suggestion fills in the line for a person to accept with Code, or Code & learn to turn it into a rule.

When Jev is not used

  • More than 255 accounts can be posted to in the company: Jev cannot choose from that many, so the language model is asked.
  • Jev failed, or the click ran short of time: the language model is asked.
  • The AI budget is spent: no suggestion at all, because the same budget would refuse the language model too.
  • Feed: fall back to the language model unticked: Jev or nothing.

Using it day to day

  1. Open the Feed Queue and click Rules, then ask AI. Up to 100 uncoded lines are tried, and the message counts how many matched a rule, how many were answered by AI (Jev's answers included) and how many are left for a person.
  2. In the Suggested column, each suggestion shows the account, its name and who made it: by rule, by Jev or by AI, with how sure it was.
  3. For a single line, click Code, then Suggest an account. The message names the source and its confidence.
  4. Check the account and VAT, then Code, or Code & learn when the same counterparty will recur.

Each Jev suggestion is one run in AI Usage under the feature erpfeed.suggest.

Worked example

A business with 140 nominal accounts ticks both switches after updating its privacy notice. Of a month's 300 bank lines, rules code 240. Rules, then ask AI suggests accounts for the other 60, 52 of them by Jev at 70% or more. The bookkeeper accepts most, corrects four, and uses Code & learn on three suppliers that will recur, so next month's rules cover them.

Recommendations

  • Rules first, always. A rule is repeatable and auditable; a suggestion is a proposal.
  • Turn recurring suggestions into rules with Code & learn.
  • Sample accepted suggestions at month end, especially tax codes.
  • Raise the account bar if Jev's low-confidence suggestions are often wrong.