How Codex learns from your corrections
- Utilisateur
- Admin
Codex is how Hyperfox learns from the orders you validate. When you correct a customer, an item, a unit or another field Hyperfox matched, it records a Codex entry. Hyperfox applies that entry to later orders when it matches the same record for a similar text. You can review, narrow or switch off the corrections Codex learned.
Only Validate records a correction
Hyperfox records Codex entries when you click Validate, never when you click Save. A saved order can still change before it is validated, so only the final, validated order counts.
When an order is validated a second time, for example after Submit Failed, Hyperfox first deletes the entries of the earlier validation. Then it records them again from the order as it is now. What each order and inquiry status means describes Submit Failed.
Which corrections become an entry
A correction becomes a Codex entry only when all of this holds:
- The field links to a reference data list. That covers every such field in your environment, not only the customer, the item and the unit. It also covers a bill-to, payer or ship-to party and a delivery address. It covers the fields of lines and of records inside the order too, such as the loading and unloading addresses of a transport order. Free text, dates, quantities and notes never become an entry.
- Hyperfox had matched a record for that field.
- You chose a different record before validating.
Typing a customer reference, fixing a quantity or choosing an item on a line where Hyperfox found nothing therefore creates no entry. Hyperfox records such a choice in another way, for the next document with exactly the same text. Match to your reference data describes how. Codex learns "for this text, Hyperfox matched record A, but the right record is B".
The second condition matters most for parties. Hyperfox can leave a bill-to or payer empty, for example because the document does not name it. If you then fill it in, Hyperfox records no entry, because it had matched nothing to correct. Codex cannot fill that field on the next order either. The levers in that case are your reference data and the instruction on that field. To set the instruction, follow Steer how the AI reads a field.
Every new entry gets the reason Matched to the wrong reference data record. You can change the reason afterwards in Codex.
What an entry records
Each entry shows, in Codex:
- Date: when the order was validated. After a second validation of the same order, the date of the last one.
- Field: the field you corrected, for example Item or Buyer customer party. The field names come from your environment.
- Changes: what Hyperfox read (AI extracted:), the record it matched (AI matched:) and the record you chose (Changed to:).
- Reason: why the match was wrong, from a list.
- Scope: the customer, and for a unit also the item, the entry applies to. No scopes means it applies to every order.
- Active: whether Hyperfox uses the entry.
Scope: for which orders an entry counts
An entry is limited to the customer of the order you corrected. A corrected item applies to later orders of that customer. A corrected unit applies to that customer and that item.
Correcting the customer itself works differently. The customer sets the scope of every other correction. When you change the customer of an order, Hyperfox records one entry for the customer, with No scopes, and no other entries for that order. That entry applies to every later order where Hyperfox reads a similar text. When you change both the item and the unit on one line, Hyperfox records only the item.
How Hyperfox uses entries
Since the release of 29 July 2026.
When Hyperfox reads a new order, it first applies the entries with No scopes. As soon as it has found the customer, it adds that customer's entries. An entry applies when Hyperfox is about to match a text to the record that the entry corrected. If the text is close to the text the entry recorded, Hyperfox takes the record from the entry instead. An entry stays on the field you corrected when another field of the same record uses the same list. For example, a correction of the unloading address of a transport order does not change its loading address. An entry never fills a field Hyperfox left empty. It only replaces a record Hyperfox matched. If two entries contradict each other, for example A was corrected to B and later B back to A, they cancel each other. Hyperfox then keeps its own match.
Codex changes matches, not reading. If Hyperfox read the wrong text, for example a quantity from the weight column, an entry does not help. That case needs a change to the extraction instruction.
To see which entries Hyperfox used on an order, admins open Developer tools > Codex on the validation screen. Captured lists the entries recorded on this order. Applied lists the entries Hyperfox used.
Each environment has its own Codex
Codex entries belong to the environment in which you validated the order. A test environment and your live environment each keep their own entries. No screen copies entries from one environment to the other. Hyperfox can match a customer or an item differently in two environments that have the same instructions. If it does, one cause is a difference in their Codex lists, and the entries for that field in both environments show it. Corrections you made while testing do not apply in the live environment. Only orders you validate in the live environment record entries there.
When a customer sends the same order again
Hyperfox reads a copy of an order that is sent again like any new order. The entries apply to the copy on the same conditions as to any other order. The entry must exist when Hyperfox reads the copy. An entry limited to a customer counts only when Hyperfox finds that customer. It must also match the record the entry corrected, for a similar text. A copy that Hyperfox read before you validated the first order gets none of the corrections of that order. Each copy therefore needs the same check as any order.
Why it works this way
Codex ties learning to what the business confirmed: a validated order. Scoping keeps a correction for one customer from changing the orders of another. One customer can order "box" and mean a different item from the next customer. A new run can read the document differently, for better or worse. Hyperfox does not learn from a retry. Only a validated correction records a Codex entry.
What this means for you
- Hyperfox learns only from a correction you make in Hyperfox before you validate. That holds even when you could fix the order in your ERP afterwards.
- A wrong correction records a wrong entry. You can switch that entry off or delete it in Codex.
- Hyperfox reads at most the 200 newest active entries that apply to every customer, plus the 200 newest of the order's customer. Switching off or deleting entries that no longer hold keeps the useful ones within that range.
- When an import deletes records from your reference data, Hyperfox also deletes the entries that point to those records.
- If an item is not in your reference data at all, Codex cannot help, and the item has to be added first. An item isn't recognised or the wrong item is matched covers that case.
- Hyperfox switches Codex on per environment. If Codex is off, Codex shows "Codex is not enabled".