futurisold

Words of wisdom.

This, combined with contracts, could make a lot of things so much fun now!

For those who don't know (which is probably everyone but me), I ported the design-by-contract pattern in Python and combined it with LLMs. This was early 2025. I originally wrote about it here: https://leoveanu.com/2025-03-01-dbc/ . Contracts are a core feature of SymbolicAI ever since. The community seems to have loved it too (https://news.ycombinator.com/item?id=44399234).

I think I'm starting to glimpse the implications and it's gonna change agentic workloads if it holds up to scrutiny. It's too early for me to tell anything other than jot down some rough thoughts.

In short, you get blazingly fast semantic branching you can use in control flows. For contracts, I can now directly take the data model that you have to design and convert it into Jev's expected format. Or I can use Jev for semantic branching in postconditions.

If my understanding is correct, that should be doable, but I need to think more about it. It could be that with Jev I can finally “compile contracts” and better chain them into workflows, which is something I always wanted but didn't know how to do properly.

Eager to test. On the waiting list.

Hi HN. I wrote a deep dive into the math behind the XOR metric used in DHT networks. It turns out it perfectly maps onto the bizarre, 19th-century idea of p-adic numbers. I included a few interactive visualizations to make the ultrametric geometry a bit easier to digest. Hope you enjoy it!

How I use agentic coding.

why isn't this on the main page already? it's something very useful and well-done!

Thank you to everyone for participating in the discussion and for your overall support! As I said, I didn't expect this. I'm always just an email or tweet away, so you know how to reach me. It was great talking to you all!

Oh, definitely. I recommend you go for contracts. I've used something similar for a contract that iteratively "stitched together" a broken ontology graph. Here's some of the data models for inspiration -- you could have something similar for your ops, and write the contract to solve for one op, then apply the op, etc.

---

    class Merge(LLMDataModel):
        indexes: list[int] = Field(description="The indices of the clusters that are being merged.")
        relations: list[SubClassRelation] = Field(
            description="A list of superclass-subclass relations chosen from the existing two clusters in such a way that they merge."
        )
    
        @field_validator("indexes")
        @classmethod
        def is_binary(cls, v):
            if len(v) != 2:
                raise ValueError(
                    f"Binary op error: Invalid number of clusters: {len(v)}. The merge operation requires exactly two clusters."
                )
            return v
    
    
    class Bridge(LLMDataModel):
        indexes: list[int] = Field(description="The indices of the clusters that are being bridged.")
        relations: list[SubClassRelation] = Field(
            description="A list of new superclass-subclass relations used to bridge the two clusters from the ontology."
        )
    
        @field_validator("indexes")
        @classmethod
        def is_binary(cls, v):
            if len(v) != 2:
                raise ValueError(
                    f"Binary op error: Invalid number of clusters: {len(v)}. The merge operation requires exactly two clusters."
                )
            return v
    
    
    class Prune(LLMDataModel):
        indexes: list[int] = Field(description="The indices of the clusters that are being pruned.")
        classes: list[str] = Field(description="A list of classes that are being pruned from the ontology.")
    
        @field_validator("indexes")
        @classmethod
        def is_unary(cls, v):
            if len(v) > 1:
                raise ValueError(
                    f"Unary op error: Invalid number of clusters: {len(v)}. The prune operation requires exactly one cluster."
                )
            return v
    
    
    class Operation(LLMDataModel):
        type: Merge | Bridge | Prune = Field(description="The type of operation to perform.")

---

Thanks for bringing this up. I'm fairly familiar with Peirce's triadic semiotics and Montague's semantics, and they show up in some of my notes. I haven't turned those sketches into anything applied yet, but the design space feels *huge* and quite promising intuitively.

I'd argue it's all of them. Contracts simply make better agents. I believe it also gives a very nice bias on how to talk about agents -- as apps obeying contracts. If you find time, please read this blog post; it gives the underlying motivation for using contracts in agent design: https://futurisold.github.io/2025-03-01-dbc/

It's subjected to randomness. But you're ultimately in control of the LLMs's hyperparams -- temperature, top_p, and seed -- so, you get deterministic outputs if that's what you need. However, there are downsides to this kind of LLM deterministic tweaks because of the inherent autoregressive nature of the LLM.

For instance, with temperature 1 there *could be* a path that satisfies your instruction which otherwise gets missed. There's interesting work here at the intersection of generative grammars and LLMs, where you can cast the problem as an FSM/PA automaton such that you only sample from that grammar with the LLM (you use something like logits_bias to turn off unwanted tokens and keep only those that define the grammar). You can define grammars with libs like lark or parsimonious, and this was how people solved JSON format with LLMs -- JSON is a formal grammar.

Contracts alleviate some of this through post validation, *as long as* you find a way to semantically encode your deterministic constraint.

This is the correct view. Since the instruction was ambiguous, the LLM did its best to satisfy it -- and it did.

Yes, that's correct. If using say openai, then every semantic ops are API calls to openai. If you're hosting a local LLM via llama.cpp, then obviously there's no inference cost other than that of hosting the model.

We hear you. We might end up renaming it. In the paper we have a footnote about the name choice -- it's meant to credit the foundational work of Newell and Simon that inspired this project.

Oh, thank you; refactoring artifacts. Fixed now.

+

That's very kind of you, thank you. Let's sync and see if we can align on something. You can find me on X, or shoot me an email at [email protected]

I'm struggling to understand the question. I'll revisit this when I wake up since it's quite late here.

Shortly, yes to all. We actually had an experiment going from theory of mind to emotion, but it's hanging right now since I feel the models aren't quite there yet and it yields diminish returns relative to effort. But could easily be revived. Minsky isn't my fav though, I'm leaning more toward Newell/Simon and friends from that generation.

Wolfram's also too busy running his TOE exps to focus on LLMs (quite sadly if you ask me).

> I'm surprised that they haven't revamped it

No worries! I can't find it right now, but Wolfram had a stream (or short?) where he introduced "Function". We liked it so much we implemented it after one day. Usage: https://github.com/ExtensityAI/symbolicai/blob/main/tests/en...

Thank you! I'm not familiar with that project, will take a look

One last comment here on contracts; an excerpt from the linked post I think it's extremely relevant for LLMs, maybe it triggers an interesting discussion here:

"The scope of contracts extends beyond basic validation. One key observation is that a contract is considered fulfilled if both the LLM’s input and output are successfully validated against their specifications. This leads to a deep implication: if two different agents satisfy the same contract, they are functionally equivalent, at least with respect to that specific contract.

This concept of functional equivalence through contracts opens up promising opportunities. In principle, you could replace one LLM with another, or even substitute an LLM with a rule-based system, and as long as both satisfy the same contract, your application should continue functioning correctly. This creates a level of abstraction that shields higher-level components from the implementation details of underlying models."

Very nice, bookmarked for later. Interestingly enough, we share the same timeline. ~2yo is when a lot of interesting work spawned as many started to tinker.