The register describes the knowledge
In the model we are developing, each organisation has a local node. Its register describes documents and data, who is responsible for them and how they relate. We are designing around content remaining in existing systems.
Within an organisation’s control
Documents, decisions and data
Metadata register · event log · access rules
Only metadata and history permitted to be visible
Federated index
Discovery across nodes, with references to the sources.
Understand the relational metadata register ↗
Five questions distinguish the functions
| Question | Function | Describes |
|---|---|---|
| What exists? | Metadata register | Knowledge objects, actors, agents, systems and their relationships. |
| Where is it? | Federated index | Addresses and access paths for resources permitted to be discovered. |
| What happened? | Relational Trace (proposed) | Separate event history: origin, versions, changes, validations, contributions and reuse. |
| What is permitted? | Policy and rights | Authority, legal basis, classification, jurisdiction, purpose and conditions of use. |
| How do nodes cooperate? | protocol | Shared models, messages, verification and federation rules. |
Relational here describes the connections between objects, actors, agents and systems. It is a conceptual model, not a requirement to use a particular database product.
Discovery and access are different decisions
- 01
Describe locally
The node registers metadata, relationships, rights and references to source systems.
- 02
Make permitted parts discoverable
Policy determines which metadata, relationships and parts of the history others may see. Metadata itself can need protection.
- 03
Evaluate use at the source
A reference makes it possible to request a resource. Authority, purpose and conditions still need to be evaluated for that specific request.
- 04
Keep an attributable record
The event log records changes, validations, contributions and reuse. Permitted history can travel between nodes.
SCRIPTED SCENARIO
What may an agent see and do?
A case officer asks a local agent to compare a method. That agent asks an external agent for help. Follow who requests what and how the source node would need to respond at each boundary.
Fictional example. All decisions are scripted. No node, identity check or policy engine runs here.
The officer sets the purpose: compare a method for checking a sensor. The organisation remains responsible for its source material.
Choose whose view to inspect
ACTOR AND ACCOUNTABILITY
Case officer
- Acts for
- Fictional Municipality
- Mandate
- Review method and decide on use.
- Accountable party
- The source organisation for its mandate and decisions.
THE LOCAL NODE’S RESPONSE
Which view is returned?
The organisation must assess the person’s own access. Delegating to A does not expand it.
- What this actor sees
- The original and local context under the officer’s own permissions. This view is not passed onward in the scenario.
- Permitted operation
- Review and make an independent decision within the officer’s mandate.
What should be traceable?
mandate-recordedhuman · agentA
This is a teaching view for the reader. A real event log would have its own access rules; B does not see the entire list. Events, receipts and executed actions are not verified in this demo.
Inspect the scenario JSON ↗ Agents and mandates in the specification ↗
A contribution can be visible without revealing a name.
It should be possible to show a contribution without revealing the contributor to everyone. Intertween separates participation, authority to act and the identity details a recipient may see. The same principle applies to participating organisations and software.
- Identified: the recipient sees permitted identity details. This alone says nothing about how the identity was verified.
- Masked or pseudonymous: the recipient sees limited details or a reference such as “Contributor A”. The identity may be known locally, but disclosure requires a separate decision.
- Anonymous: no identifying link is retained for the contribution in this context. Later identification cannot be promised. Other details may still identify the contributor and need assessment.
- Unknown: the source lacks identity information or identity has not been established. This differs from withholding a known identity.
For example, a municipality may show evidence that an authorised technician inspected a sensor without disclosing their name. An anonymous fault report may also be useful, but must not be represented as an authorised inspection without supporting evidence.
Hiding a name on screen is insufficient. Identifiers, locations, timestamps, relationships and history can also reveal the contributor. The same rules need to apply to search, exports and linked information.
Read the specification requirements ↗Proposed temporal governance: contributions, identity, mandates and entitlements ↗
A rights-aware tracker for knowledge
Think of a torrent tracker helping participants locate a resource. Similarly, Intertween can help people and agents discover knowledge objects and their relationships while content stays at its source.
What the analogy explains
- References to resources and nodes.
- Shared discovery with local control.
- No required central content store.
Where the analogy ends
- Rights, jurisdiction and responsibility must be evaluated.
- Relationships and history are part of the model.
- Explicit rules govern sharing; free replication is not assumed.
Tracker is a teaching analogy, not the protocol’s category name. The Tracker component also has the specific role of recording events.
How can we detect changed history?
The register shows current state. Relational Trace is our proposed separate history, where corrections and challenges are added as new events. A federated index helps discover material; it is not the sole keeper of historical evidence.
We are exploring whether signed checkpoints retained by other authorised nodes can make changes detectable. Proofs need their own access rules and may expose identity. A checkpoint can reveal a difference but cannot reconstruct missing events without retained records.
Read the proposal and boundaries ↗ Try the local experiment ↗The register and its history need different names
Metadata register is the main term for the node’s descriptions of what exists and how it connects. Event log is the generic history function. Relational Trace is the proposed history profile with explicit integrity requirements. Ledger may appear in technical comparisons but should not stand for the entire node or Intertween.
Knowledger remains a governed, versioned composition of knowledge objects. It is neither the node’s register nor its event log.
Source: “Intertween as a relational metadata register”, communication memo, 19 September 2026. Status: recommended conceptual model.
Explore the vocabulary Technical descriptionIntention, activity and evidence
We explore how an AI system could participate through a local node: permitted context and skill descriptions go in; references to results, versions used and evaluations come back. Human intentions and the system’s interpretation need to remain comparable.
The node describes conditions and decisions. The execution environment must enforce whether an activity may proceed. This is a proposed model, not an operational agent connector or runtime enforcement service.