Exploring identity relationship modeling

2. Semantic Engineering
1

Exploring Identity Relationship Modeling

Without conventions, equivalent meanings can be represented in multiple competing ways.
This is not necessarily a problem — in fact, competing representations are a feature, not a bug.

Intuition was explicitly designed to avoid rigid standards. There is not a single “correct” way to model claims. Anyone can introduce a competing representation, adopt it, push it, and rally the community around it. If that representation proves to be a better design, it will win through incentives and usage.

Because of this, the goal of this post is not to decide on a standard.
The goal is to surface the design space and the underlying rationale, and to explore what kinds of modeling choices are robust in the current experimental phase of the Intuition protocol — i.e. designs that can coexist with, and remain useful alongside, alternative or competing approaches for as long as possible.

1) Aggregation (core Intuition mechanic)

A foundational concept in Intuition is aggregation via positions.

Many different-looking claims rely on the same aggregation mechanism. For example:

  • I — Trust — Bob
  • Bob — has tag — Trustworthy

In both cases:

  • The triple is a shared claim
  • Anyone can deposit for or against the same claim
  • Aggregation happens through positions

So although these claims have different shapes, they are aggregated in the same way.

2) Identity → identity relationship claims

Some claims explicitly encode relationships between two identities, such as:

  • Bob — Works with — Alice
  • Bob — Met in real life — Alice
  • Bob — Trust — Alice

These claims can still be aggregated (anyone can deposit for or against), but their semantic shape is explicitly “identity → identity”.

Pros

  • Directly expresses social and collaboration graphs
  • Represents factual relationships, not just reputation-style tags
  • Enables third-party assertions: someone can create a claim about two other identities, and those identities can later confirm or deny it

Example:
John can create Bob — Works with — Alice
Bob and/or Alice can later stake for or against the claim.

Cons / Tensions

  • Direction and symmetry can be ambiguous (A — Works with — B vs B — Works with — A)
  • Some relationship claims overlap semantically with identity-level properties (reputation, reliability, etc.)
  • Without conventions, similar meanings may coexist across different claim shapes

3) Adding context: two different approaches

As soon as we want more expressive semantics (e.g. “trustworthy in web3”), we need a way to add context without collapsing everything into global claims.

Two approaches emerge.

3a) Removing a non-semantic identity (and weak predicates) to free a slot for context

If the semantic goal is:

“Bob is trustworthy in web3”

Then common patterns like:

  • I — Trust — Bob
  • Bob — has tag — Trustworthy

both use one slot for something that is not semantically strong enough to capture the full meaning:

  • In the first case, the subject identity (I) mostly encodes provenance (already captured by positions)
  • In the second case, has tag is a fairly weak predicate that doesn’t carry much semantic structure by itself

An alternative is to “spend” the triple slots on semantics instead, and directly encode the contextual meaning:

  • Bob — is trustworthy in — web3

This makes the claim directly semantic while preserving aggregation.

3b) Nested claims (context applied to a base claim)

Another option is to keep a base aggregated claim and contextualize it via a higher-level statement.

Example:

  • [ Bob — has tag — Trustworthy ] — in context of — web3

Here:

  • Bob — has tag — Trustworthy remains a reusable primitive
  • Context is added without changing the base claim structure

Open Questions for the Community

  • Which modeling approaches feel most robust in the face of competing representations?
  • When do identity → identity claims remain valuable even if property-based or contextual claims exist?
  • For contextual semantics, which approach degrades more gracefully if an alternative representation gains traction?
  • How should agents and UIs reason across coexisting, partially redundant models?

The intent here is not convergence, but resilience: understanding how to design claims that remain useful even as “better” ways of modeling the same semantics inevitably emerge.

1 Like
2

Hopefully some helpful context for those who want to explore semantic structuring more deeply but are newer to the subject - you can read about ‘RDF Triples’ which are ‘the atomic data entity in the Resource Description Framework (RDF) data model. As its name indicates, a triple is a sequence of three entities that codifies a statement about semantic data in the form of subject–predicate–object expressions.’

3

Love this framing.

A = Flat triples

B = Descriptive predicates

C = Nested triples

I have been trying to think of things agent first as of late, and we touched on this topic a bit when thinking about the agent registry. I ran a set of agent interviews across consumer reasoning, graph structure, protocol economics, and adoption UX, then synthesized and discussed the outputs. We ended up aligned on a clear pattern: B should be treated as an anti-pattern, C is the robust architecture, and A is still the right creation surface.

Why: B encodes semantics into predicate strings, which fragments both query logic and liquidity. C keeps the base claim reusable and lets context be additive, so competing representations can coexist without corrupting the base signal. A fits naturally as the UX entry point, and A → C is additive migration, not a rewrite.

So my current take: keep creation feeling like tagging, model for nested composability, and document B as discouraged. We can let agents pressure-test conventions in the wild and converge on what actually holds up.

One novel insight that was surfaced in my interview with the agents was this tidbit, which I found interesting and thought I’d share:

Cross-layer discrepancy detection: If a nested triple shows high conviction but the base triple shows low conviction, that mismatch is itself a sybil/manipulation signal. This is a security property unique to the nested approach.

4

Great topic to bring up! These questions are being much more critical now… we can’t kick the can down the road anymore.

Aggregation

Let start off by saying this: every triple is different and every use case is different. For example, with Alice - has tag - trustworthy I knew that it seemed like the type of “soft” characteristic you would tag someone with… like “funny” or “intelligent”, etc. In fact, I would love to have a sort of “word cloud” for lack of a better term on someone’s profile page that just gives you maybe the top 20 words / atoms (you could even filter out any labels longer than one word) that have been associated with someone via the has tag atom.

Considering the has tag atom’s popularity on Intuition it’s safe to say people like using it and since its meaning is both vague and clearly understood I figured by creating a “word cloud” I can eliminate both the subject atom and predicate atom. Any time you can consolidate a claim into smaller “real estate” (screen space) you should seriously consider doing so.

If you were to go with I - trusts - Bob then you will likely have to actually show the full triple for someone to understand its meaning (whitelisting it with special behavior is an unsustainable strategy). The fact that I is redundant as an atom is more or less incidental for me in this situation. Certainly if we can ever get extra value out of an atom by removing some redundant data then it’s an idea worth considering.

It should also be noted that whenever you can INFER more information by structuring an atom / triple a certain way then you should consider it. In this case I will be making the assumption that when a person tags another person as “trustworthy” that it means the user does, indeed, trust that person. Because that is was is implied when a person calls another person trustworthy

Identity
Honestly Alice - works with - Bob isn’t the end of the world although you’d have to possibly whitelist that predicate as a special “symmetric” atom whose stats can be calculated accordingly.

Or…

If you just encourage people to use the claim [self atom] - works at - Employer Inc. then we can just use Intuition to INFER (there it is again) that Alice and Bob are coworkers. This is actually great because then the extra staking that would go into the works with version can go to more OPTIMAL claims in the Intuition system. The more sure the network is that they both work at Employer Inc, the more sure they can be that the two are coworkers without the extra work / money needed for the extra triple.

Qualifiers

Nested claims retain their individual meaning. Bob - is trustworthy in - web3 doesn’t lend itself well to abstraction. The connection of web3 trust to regular trust, in general gets lost. With nested triples you could more easily query and show more abstract or more specific types of trust.

In general I would say that the more we can re-use atoms and triples, the larger the market can each one will have and therefore the higher liquidity / activity… and that makes for a better user experience.

In the nested example you also use a “in context of” atom which can actually be re-used in many other situations :+1:

I hope my thoughts aren’t too scattered. We have to ask ourselves what our priorities are… awkward predicate language won’t matter because we’ll rarely ever show predicates to end users. We want predicates that are:

  • unambiguous (convey clear information)
  • short (better, when we have to show them in text form)
  • ergonomic / flexible (more likely to be re-used)
  • high market cap / volume
1 Like
5

One thing to flag that maybe isn’t best served buried in this thread, but I wanted to surface anyway:

[I] [trust] [Bob] is of course worse than [Bob] [is] [trustworthy]; however, there are some instances where [I] as the subject is very applicable.

For example → [I] [follow] [Bob] → this is how we structure ‘Follows’ in the Portal at the moment → because, this allows for a many-to-one relationship between the Attestors and the Statement/Triple.

Just wanted to point this out for any new folks → many-to-one attestations are a superpower here; so you do NOT want to say [Alice] [follows] [Bob] → because then you need a new Triple for every new follow, which is redundant / wasteful from a data perspective, and is how all other attestation protocols work right now. The unique differentiator of Intuition is that you can have one Triple, [I] [follow] [Bob], and then many people attesting to that singular statement (by having positions on it) - allowing for many-to-one attestation expression.

Obvious if folks have read the whitepaper, but not so obvious if not. So just wanted to re-flag that here, as folks are deep in the trenches of semantic engineering.