Giving systems a reason to act

In one team, if one internal system publishes an event and another internal system consumes it, the surrounding business logic is often implicit. Developers and their agents know what the message means, as the infrastructure is managed under the same governance. The decision to act on a message is part of a shared operational context.

Across organisations, that implicit context disappears. A message needs to arrive, be understood, be aligned to the receiving system’s model, and be trusted enough to influence the receiving organisation’s state.

Let’s consider a simple example: a radio station publishes that it is playing a song. The most natural RDF model is also the shortest one:

1
2
@prefix radio1: <https://example.org/radio1/> .
radio1:radio radio1:plays radio1:Q57 .

This looks nice: the statement is simple and straightforward. Yet, from the moment another system consumes this triple, questions can be raised: When was this statement made? Was it retrieved from the radio station itself? Was it observed by a listener? Was it planned in a playlist three days ago? Is it still true now? Should it overwrite what my system already knows, or is this complementary knowledge?

The triple may be interoperable, it does not yet have the proper trust context. A consumer that wants to show the currently playing song, calculate royalties, update a listening history, or trigger a notification will need different levels of confidence. As this consumer, you would of course not load the triple as a universal truth, but would load the triple within a context first—e.g., attach the fact that the triple was retrieved at a certain moment—before trusting it for your own business process later on.

The quest towards universal truth

Knowledge engineers are trained to avoid statements that only happen to be true for a moment. We want to model facts in a way that remains true beyond the current state of a system, or want to be explicit about that state. Instead of saying that the radio plays a song, we introduce an activity, a playlist item, or an observation.

1
2
3
4
5
6
7
@prefix radio1: <https://example.org/radio1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

radio1:Play123 a radio1:PlaylistItem ;
    radio1:on radio1:radio ;
    radio1:song radio1:song57 ;
    radio1:startDate "2026-06-28T14:03:00+01:00"^^xsd:dateTime .

This is better: the model now says something less fragile. It no longer merely asserts the current state of the radio. It describes a playlist item that starts at a particular moment. This is the kind of richer local semantics I want systems to publish before they prematurely align to someone else’s simplified model.

Yet, even this richer model does not make the statement automatically actionable across organisations. The playlist may have changed after publication. The statements may have been retrieved too early or too late. Another source may have copied the information without the same authority. A consumer may trust the radio station’s own publication, while treating a third-party mirror differently.

What would give your system the right reasons to act? When will the right level of trust be triggered?

Trust anchors become trust triggers

I call the pieces of information that help answer that concern trust anchors. A timestamp can be a trust anchor. A source can be a trust anchor. A signature, credential, access policy, observation method, licence, or data quality statement can be a trust anchor. None of these automatically forces a consumer to believe the data. They provide reasons a consumer can evaluate.

A trust trigger appears when such trust anchors are strong enough for a receiving system to act. It is a piece of information, in context, that passes the receiving organisation’s assertion process.

A producer can publish useful trust anchors, and the consumer decides whether they are sufficient. The same message may trigger a state change in one organisation, be stored for later analysis in another, and be ignored by a third. Trust is the result of a process in a concrete system.

This is also where interoperability and trust meet. The incoming information first needs to be aligned to the consumer’s model. Then it needs to be evaluated against the consumer’s rules. These activities happen at the same boundary: the moment external information becomes internal state.

Every time data travels, it gets a new context

As soon as a consumer retrieves the radio station’s data, I would dare to say that even then it should not just import these statements as they are in their own system. A consumer should wrap the payload in a new context, to for example record when the data was retrieved, where it came from, and what exactly was retrieved.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@prefix radio1: <https://example.org/radio1/> .
@prefix mysystem: <https://example.org/mysystem/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

_:message a mysystem:IncomingMessage ;
    prov:wasDerivedFrom <https://example.org/radio1/> ;
    prov:generatedAtTime "2026-06-28T13:58:00+01:00"^^xsd:dateTime .

_:message {
    radio1:Play123 a radio1:PlaylistItem ;
    radio1:on radio1:radio ;
    radio1:song radio1:song57 ;
    radio1:startDate "2026-06-28T14:03:00+01:00"^^xsd:dateTime .
}

To keep data in its own context in RDF, I like to use blank node graphs, as in the example above. If I want to use those triples in the default graph, I’ll have to make an effort, such as creating a query that explicitly selects messages from a certain source.

Publishers can of course also provide context in the way the consumers would add it themselves. A publisher can describe the production context of a message, and a consumer can then add its own reception context around it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@prefix radio1: <https://example.org/radio1/> .
@prefix ex: <https://example.org/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

_:receivedMessage a ex:ReceivedMessage ;
    prov:generatedAtTime "2026-06-28T13:58:00+01:00"^^xsd:dateTime ;
    prov:wasDerivedFrom <https://example.org/radio1/feed> .

_:receivedMessage {
    _:publishedMessage a ex:PublishedMessage ;
        prov:generatedAtTime "2026-06-28T13:57:30+01:00"^^xsd:dateTime .
}

_:publishedMessage {
    radio1:Play123 a radio1:PlaylistItem ;
        radio1:on radio1:radio ;
        radio1:song radio1:song57 ;
        radio1:startDate "2026-06-28T14:03:00+01:00"^^xsd:dateTime .
}

This pattern may look verbose for a toy example. In real data ecosystems, this is, however, exactly the information needed to decide whether a trigger should be accepted. The processor can check whether the producer generated the message recently enough. It can check whether the consumer retrieved it from an expected endpoint. It can check whether the source is authoritative for this kind of statement. It can check whether the message was signed, whether the payload matched the expected shape, and whether an alignment to the consumer’s internal vocabulary preserved the relevant meaning. This is the business logic of trust.

There is, of course, the question of why we would not use other techniques than blank node graphs, and how we would package quads instead of only triples. One option is to rename graph names and use multiple blank nodes, as long as producers and consumers share the same packaging rules. We explored this direction at ESWC2026 under the name Context Associations.

From eventual interoperability to eventual assertion

In my post on eventual interoperability, I argued that systems should not be forced to align too early. A producer should be able to model its own domain using terms that make sense in its own context. Later, when a concrete need appears, alignments can translate that rich model into the model expected by another system.

Eventually aligning the shape of the data is only one part of the boundary process. The receiving system also needs to assert whether the incoming information is good enough to act upon. The trust triggering part and the interoperability part thus go hand in hand.

This is where symbolic technologies become interesting. Alignments, validation rules, provenance checks, and policy decisions can all be made explicit. They can be tested. They can be reused. They can be audited. Most importantly, they can be separated from the producer’s domain model.

The producer does not need to guess every future consumer’s internal model. Alignments can be provided by the consumer, by the producer, or by ecosystem-level services. In the same way, assertions do not need to be treated as purely local and ad hoc decisions. Just as interoperability can become an ecosystem-level concern over time, assertion can as well. Trust can be curated within an ecosystem through shared patterns, artefacts, and governance, while each consumer still decides when information is strong enough to trigger internal state changes.

Trustflows

This brings me to the architectural idea I increasingly call trustflows. A trustflow is more than a data flow. It is a flow in which every meaningful state transition can be traced back to the information, context, alignments, and policies that justified it.

The input may be a write operation, a fetched dataset, a credential presentation, an event stream message, or a notification from a broker. The output may be a new resource state, an accepted assertion, a refused action, a derived insight, or another message. Between input and output sits the processor that aligns, validates, checks, derives, and decides.

This processor is where interoperability, legal compliance, and trust become operational. Treating them as separate concerns will lead to incomplete architectures. Alignment without trust creates understandable data that may still be unsafe to act upon. Trust without alignment creates confidence in data that the receiving system cannot use.

P.S.

The attentive reader might have noticed I deliberately did not use RDF1.2 triple terms. I think triple terms are useful to track the provenance of statements after the assertion process. During the assertion process, we should be able to describe message context and evaluation steps explicitly before promoting statements to asserted knowledge.