# Level 00 · Conventional software _Rules, search, and automation_ Use ordinary code, search, forms, or a task-specific statistical model when they solve the problem. No generative model is required; classical machine learning can belong here too. ## Who decides the next step Your software applies rules, lookups, or established algorithms. ## What is at this level - [When not to use a model](/gradient_ascent/techniques/order-zero/) (sourced): How to tell when ordinary code, search or a form is enough. ## Upgrade conditions - **When not to use a model → Chat:** The input is language you cannot write rules for, and a wrong answer is cheap to catch. ## Named products, tools and models ### Tools - Elasticsearch — Elastic · keyword search - OpenSearch — open source · keyword search - Regular expressions — every language · pattern matching - scikit-learn — open source · classical machine learning - spaCy — Explosion · rule-based and statistical text processing - SQL — every database · structured queries - XGBoost — open source · classical machine learning ## What is still unsolved at this level _As of 09/19/2026. This block ages faster than the rest of the page._ ### When not to use a model A rule written as a regular expression can pass every test anyone thought to write and still take exponential time on one unlucky input, because a backtracking engine tries an exponential number of paths before it gives up. Reading the pattern does not tell you which inputs do it. **What people are trying:** Engine authors are moving to matchers that run in linear time and never backtrack, and static analyzers look for the nested, overlapping repetition that makes a pattern vulnerable. Neither removes the need to check a pattern you inherited. - [Regular expression Denial of Service - ReDoS](https://community.owasp.org/attacks/Regular_expression_Denial_of_Service_-_ReDoS) · OWASP Foundation · read 09/19/2026: "may reach extreme situations that cause them to work very slowly (exponentially related to input size)" ### When not to use a model A rule system's real input space is every field's values multiplied together, so testing all of it is out of reach, and there is no general way to say how much of it a test suite covers. Every practical answer rests on an assumption about how failures are spread across combinations. **What people are trying:** NIST's combinatorial testing work builds test sets that cover every two-way to six-way combination of parameter values rather than every combination, on the finding that most real failures are triggered by a few interacting factors. Teams pair it with tracking which rules ever fire in production, to find the branches no test reaches. - [Combinatorial Methods for Trust and Assurance: Why do Combinatorial Testing?](https://csrc.nist.gov/projects/automated-combinatorial-testing-for-software/combinatorial-methods-in-testing/interactions-involved-in-software-failures) · NIST, Computer Security Resource Center · read 09/19/2026: "it is nearly always impossible to do exhaustive testing, but we don’t have to test all possible combinations of inputs; we only have to test all of the combinations that trigger faults" ### When not to use a model A classifier your code acts on can drift away from the data it was trained on long before any true label arrives to prove it. Measuring accuracy directly means waiting, and by then it may have been wrong for weeks. **What people are trying:** Detectors that watch the model's own output distribution instead of waiting for labels, built on statistical process control and set to fold labels in if they ever turn up. Keeping the false alarm rate low at production volume is the part that is not settled. - [Flexible and Efficient Drift Detection without Labels](https://arxiv.org/abs/2506.08734) · arXiv · read 09/19/2026: "Controlling for false positives while monitoring the performance of predictive models used to make inference from extremely large datasets periodically, where the true labels are not instantly available, becomes extremely challenging."