Each demo combines ordinary code with a small model task. I’m testing where that task helps. A working app doesn’t prove the model was necessary.

What happens in each app

  • News radar: code collects headlines, samples public posts, removes duplicates and checks sources. Clef reviews candidate topics and whether news adds something new or repeats earlier coverage. Approved items appear with source links.
  • Metals Pulse: code stores prices and calculates returns, ranges and supported patterns. Clef chooses among the allowed interpretations and attention actions. If only one outcome is allowed, code handles it without a model call. Neither predicts prices.
  • Weather Impact: code keeps the National Weather Service’s severity, dates and instructions, and removes expired alerts. Clef scores relevance to driving, outdoor activities, home and boating. Within your area and search, severe, extreme and unknown-severity alerts stay visible even when the model finds little relevance. Unreviewed and unclear matches stay visible too. The model does not decide whether an activity is safe.

Could rules or a regular LLM do this?

Yes. I’d use code for calculations, expiry checks and clear rules. A general-purpose LLM can also return structured choices. It makes more sense when the job needs written explanations, flexible reasoning, or an agent that gathers information and uses tools.

A decision model may fit repeated, limited choices over messy inputs: show or skip a headline, route a request, flag a report. It could cost less or respond faster than a larger model. These demos have not established that advantage.

They currently use Clef-flash. Jev is another dedicated decision-model option.

What would prove useful?

I’d test new examples we didn’t use while building it. The comparison should include simple rules and a small, inexpensive LLM. I’d measure missed items, false alarms, response time and total cost. The cost of a wrong decision matters too. A probability score alone doesn’t answer any of that.

Where else might it fit?

  • Manufacturing: flag batches for quality review using process readings and inspection results.
  • Maintenance: prioritise equipment warnings using sensor events and repair history.
  • Logistics: identify delivery exceptions that need attention, using shipment updates and customer commitments.
  • Retail: prioritise stock and supplier problems, using inventory changes, orders and lead times.
  • Customer operations: route requests using the message, service policy and previous outcomes.

We don’t have those operational feeds here. These are possibilities, not validated projects. I’d need live records, known outcomes and people who understand the work to test them properly. The first step would be helping someone review a case.