Thread

Loading the complete thread in the background. This saved snapshot is available now. Refresh

1. ZaharaHussain · 1790099144 · focus · HN ↗

   [dead]

2. ZaharaHussain · 1790102279 · focus · HN ↗

   [dead]

3. chews · 1790102751 · focus · HN ↗

   It's been a while since I used a Rete rule engine, back in my days as math nerd at a mortgage bank (ooof we survived the 08 meltdown by the skin of our teeth) we used an internal fork of Drools and paired it with a merkle tree datasctructure to store lending decisions.... I knew blockchain was gonna be a thing when the genesis block referenced the bailout... I kick myself daily cause should've bought more bitcoin.

   1. ZaharaHussain · 1790191933 · focus · HN ↗

      [dead]

4. nickphx · 1790104516 · focus · HN ↗

   I don't understand. If you're already building the rules, why have a clanker summarize and guess why the result happened when you can display the rules that passed/failed?

   1. ZaharaHussain · 1790191671 · focus · HN ↗

      [dead]

   2. ZaharaHussain · 1790194801 · focus · HN ↗

      Fair question, and you can do exactly that( response_mode:"verdict_only") makes no LLM call

      1. ZaharaHussain · 1790195655 · focus · HN ↗

         [dead]

5. lunatuna · 1790139467 · focus · HN ↗

   I've used rete based CEP tool in the past for utility operations event management. We could tag the rule used to the event or event aggregate, but it was on a single node basis and a basic aggregate. If there was more coverage in understanding it would be a big help to operators. Based on say a set of outage events, can it further understand if it weather event, equipment failure, scheduled maintenance, etc. Linking it to possible operating procedures based on a broader understanding of the state would be very useful.

   1. ZaharaHussain · 1790192459 · focus · HN ↗

      That's close to what the chaining is for. Rules can assert facts that other rules consume, so a first pass classifies raw events (outage cluster + storm bulletin + no maintenance window -> assert cause: weather) and a second pass reasons over that derived fact rather than the raw events. The trace shows which firing produced what, so an operator sees the chain, not just the final rule.

      The procedure link is the part I'd most want you to try. A rule can carry a retrieval scope, so when the weather:cause rule fires, retrieval is narrowed to the storm-response procedures before the explanation is written. The operator gets the classification, the rules that produced it, and the procedure text that applies - grounded in your documents rather than a model's recollection.

      Two honest limits for your case. A match binds one fact per type, so there are no aggregation operators - "12 outages within 5km in 10 minutes" has to be computed upstream and asserted as a fact, not expressed in the rule. And there are no temporal windows, which for CEP is a real gap; time has to arrive as a field on a fact. For per-decision reasoning over a state someone else assembled, it fits well. For raw event-stream correlation, the windowing engine still has to sit in front of it.

      If you still work near this, I'd genuinely like to hear what the rule set looked like - outage classification is the case I'd build the next demo domain around.

   2. ZaharaHussain · 1790194860 · focus · HN ↗

      [dead]

   3. ZaharaHussain · 1790195033 · focus · HN ↗

      If you still work near this, I'd genuinely like to hear what the rule set looked like - outage classification is the case I'd build the next demo domain around.

      1. lunatuna · 1790215759 · focus · HN ↗

         It’s been a long time since I did the work and lost for details. The biggest issue we had was noise reduction when there was an upstream event. Could be a network issue and so meter reads were not expected to come in, so don’t send someone out to check the meter or do deeper analysis. Storm or other related outage, both diagnose and then quiet follow on events with a service ticket to acknowledge. Further we would build the history of events and if a meter or device wasn’t responding without the other broader events then create a service ticket to analyze or to send a technician out. This was all custom rules. Not sure how transferable it is as different utilities will have different ways of viewing and actioning. Interconnected are somewhat different. North America is also very different than say Germany or Brazil which I had a little bit of experience with. Wish I had more details.

         1. ZaharaHussain · 1790274481 · focus · HN ↗

            [dead]

   4. ZaharaHussain · 1790195591 · focus · HN ↗

      [dead]

6. adityamishra241 · 1790144357 · focus · HN ↗

   [dead]

7. ennepoai · 1790162063 · focus · HN ↗

   [dead]

8. jimmySixDOF · 1790171561 · focus · HN ↗

   I was expecting to see some Jev based influence on RETE/CEP rule handling ... the Typesafe.ai team have a lot more in the pipeline this use case is just getting started

   1. ZaharaHussain · 1790192706 · focus · HN ↗

      [dead]

9. awfm9 · 1790179088 · focus · HN ↗

   This is a really interesting concept. Could be quite useful for agents. I worked on something similar, but more abstract; you managed to take it to the next level.

   1. ZaharaHussain · 1790192635 · focus · HN ↗

      [dead]

   2. ZaharaHussain · 1791014065 · focus · HN ↗

      [dead]

10. lfdo0870 · 1790210753 · focus · HN ↗

    For that there's Python: with 30 lines you can automate this task. If you want I can send you the script I use. DM me if interested.

    1. ZaharaHussain · 1790219891 · focus · HN ↗

       [dead]

11. aidiveyt · 1790231100 · focus · HN ↗

    [dead]

12. fayehall_ai · 1790385871 · focus · HN ↗

    [dead]

13. TokenLat · 1790671294 · focus · HN ↗

    [dead]

14. keparlak · 1790784118 · focus · HN ↗

    The distinction you’ve drawn (the decision is made by the deterministic engine; the LLM merely explains it) matches something I’ve seen in another field. I was testing the agent’s memory: the schema of a vehicle changes mid-run, and the agent must make a call appropriate to the new schema at the end. Results: - A 20-line ‘the latest definition wins’ rule: 40/40 - Providing the entire history to the model: 38/40 - Retrieval-based memory: Mem0 (open-source) 3/15, TF-IDF + recency 1/40

    When presented with the correct information, the model used it without issue. What it couldn’t reliably do was decide which information was still valid.

    I’m curious about versioning on your end. When a rule changes, what happens to decisions made under the old rule? If someone asks six months later, “Why was this application rejected?”, does the explanation refer to the rule version at the time of the decision, or to the current one? Does the RAG side know that a policy passage has become invalid, or could it retrieve the old document to explain a new decision?

    1. ZaharaHussain · 1790796910 · focus · HN ↗

       Great data point, and I think it's the same failure mode: retrieval is good at "what's relevent", bad at "what's still in force". validity is a property you have to assign, not something similarility can recover.

       1. ZaharaHussain · 1790798764 · focus · HN ↗

          [dead]

       2. ZaharaHussain · 1791034288 · focus · HN ↗

          [dead]

    2. ZaharaHussain · 1791013057 · focus · HN ↗

       [dead]

    3. sohith_uv · 1791019363 · focus · HN ↗

       [dead]

Unofficial Hacker News client; not affiliated with Y Combinator.