SQL
Search the prefix that the technician actually typed
Two records clean to the same spelling
The pump search treated an underscore as a wildcard and returned a lookalike identifier. Botie needs the user’s literal naming policy to survive the search.
BOTIE
The inputs we are comparing
Imported code records
The underscore is literal
[
{
"record_id": 1,
"code": " PUMP_7 "
},
{
"record_id": 2,
"code": "pumpX8"
},
{
"record_id": 3,
"code": "pump_9"
},
{
"record_id": 4,
"code": null
}
]The query keeps distinct imported records
[
{
"record_id": 6,
"code": "pump_7"
},
{
"record_id": 7,
"code": " PUMP_7 "
},
{
"record_id": 8,
"code": "PÜMP_7"
}
]Literal prefix to select
Same in both cases
pump_
Result for the underscore is literal
[
{
"record_id": 1,
"normalised": "pump_7"
},
{
"record_id": 3,
"normalised": "pump_9"
}
]The technician searches valve_ rather than pump_
This check uses the pieces from “Match the literal prefix and retain source records”.
BOTIE
- Literal prefix to select
valve_
- Imported code records
[ { "record_id": 12, "code": " VALVE_4 " }, { "record_id": 10, "code": "valveX4" }, { "record_id": 13, "code": null }, { "record_id": 11, "code": "valve_4" } ]
Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.
Build a construction in the workspace above first. This case will test those pieces.
Which naming policy would need review before cleaned text could become a unique equipment key?
Treat text normalisation, literal matching and identity as separate rules, each with examples that expose its limits.
The workshop uses literal starts-with semantics, not a LIKE parser. It deliberately does not perform general Unicode normalisation.
Work through the SQL challenges →