Knowledge, connections, and what emerges between them.

Three concepts at the heart of protocol

Knowledge needs an identity, a context and a way to develop. These concepts explain what the protocol connects before we describe the operations that support it.

An intertween is itself a Knowledge Object. The register describes and connects these objects; it is a logical function, not a prescribed database or a single central repository.

The connections carry meaning too

“Refers to”, “derived from” and “challenges” say different things. Each relationship is an attributable assertion: who stated it, based on what evidence, by which method and in what context? A source citation, a reviewer’s interpretation and an AI suggestion must remain distinguishable.

The register maintains these assertions and their current states. Recording a connection makes it inspectable; it does not make it universally true. Separate history records how descriptions change.

Two guidelines. A shared question. A possible skill.

Illustrative scenario with fictional municipalities.

1. 01

   Describe the knowledge

   Two municipalities describe their guidelines as Knowledge Objects, identifying sources, versions and responsibility.

2. 02

   Connect the context

   Their local registers record references to the same legal provision. The guidelines specify different distance thresholds.

3. 03

   Make the emerging question addressable

   What explains the difference? An intertween links the question to the guidelines and supporting relationships. The difference alone does not prove either guideline wrong.

4. 04

   Develop a method

   A reviewer points out missing local context. A candidate skill emerges: check circumstances and missing evidence before judging differences. The method is another Knowledge Object, linked to the original question.

5. 05

   Learn from use

   Evaluation and adoption remain separate decisions. Applying the method may reveal another exception, creating a new observation or intertween.

This is a path through a branching network. One intertween may seed several skills, and many questions remain open. The original sources and question retain their identities.

From emerging insight to reusable capability

A skill describes a reusable method under specified conditions. Representing it as a Knowledge Object connects instructions, prerequisites, evidence and limitations to its origin. Possessing the description does not demonstrate the ability to perform it.

People and machines can contribute to this development. Human intentions and machine interpretations need to remain comparable; results and challenges inform the next version. When the methods for generating or evaluating further improvements also change, the loop becomes recursive.

The rules keep context and responsibility connected

These are protocol responsibilities. Recording conditions does not enforce them; the environment disclosing information or executing an activity must apply the relevant controls.

Operational roles support the core model

Wrapper, Mapper and the other roles describe how the work is carried out. They support the objects, relationships and emerging knowledge described above.

These roles describe the architecture; they do not establish that every operation is implemented or that the complete learning cycle is supported by the current validator.

From a local source to an assessed request

Getting started with a local node

The starting point is a locally governed register, not membership of a federation. It should be possible to describe and relate local knowledge before exchanging anything with another organisation. Creating a node remains implementation work: we have not published a ready-to-install node package, setup command or managed node service.

To understand the object format now, read the source-backed example and compare it with the Wrapper documentation. The browser validator checks the existing example format; it does not create a node, connect to an organisation’s systems or certify the newer Core Profile.

Connecting an existing system or another node

An existing catalogue or source system would connect through an adapter that maps its records to an agreed protocol profile. It does not become a conformant node simply by exporting JSON. Its identity, policy decisions, history and operational responsibilities must also be defined.

Connecting two nodes requires an agreed protocol version, authenticated node endpoints, compatible capabilities and rules for what may be discovered and requested. Each request needs a purpose and a local access decision. A permitted response needs source and version references, conditions and an exchange record. Joining a federation alone grants no access.

Proposed federation contract ↗ · Standards and interoperability ↗

What can be explored today

Tools & guides: getting started, implementation and adoption ↗

Full specification and reference wiki

Relational Trace and Federated Integrity ↗

The specification defines protocol’s object model, exchange rules and implementation requirements. The reference wiki explains its terms and fields. Standards mappings describe how protocol relates to existing protocols and vocabularies.

Interoperable local metadata registers

The protocol architecture connects locally governed metadata registers. Each node combines a register, a history of events, access rules and references to source systems. We are developing protocol to describe how permitted metadata and evidence can be exchanged while source content remains in its existing systems.

Metadata discovery and content access are separately governed. The index is not a shared content repository. The event log is not necessarily immutable. Implementation conformance depends on the named profile and the checks it requires.

The security model

Intertween is designed zero trust. No access follows from network position, from federation membership, from prior contact, or from having been granted access before. Every request is evaluated on its own terms: who is asking, for what purpose, against which object, at what moment. A request that was granted in April is evaluated again in May.

Membership grants nothing

Belonging to a federation is not a permission. Conditions are evaluated per request against what the object itself carries.

Scopes are not perimeters

Private, local, federated and open are defaults for policy evaluation, not zones inside which things are safe. Access is never inherited upward.

Discovery is not access

Seeing that an object exists and being permitted to read it are separate decisions, and either can be refused without the other.

Policy travels with the object

Rights, purpose and legal basis are attached to the object rather than held in a directory, so they survive the object moving.

Integrity on the object

Content is verified through its own hash rather than through the channel that delivered it.

This is not distrust of the custodian. Zero trust governs how access is decided: never from position or membership. It says nothing about the standing of a responsible authority. Custody stays local, and a kommun's own assessment remains authoritative and is never overridden by the framework. The two ideas are separate and neither one weakens the other.

In the terms a security architect will expect: the Mediator is the policy decision point, the local node is the policy enforcement point, and the Tracker is the audit plane.

The seven roles

Wrapper

Preserves a source observation as a knowledge object, with identity, source, provenance, rights and lifecycle attached.

Mapper

Maps local meaning to another vocabulary without replacing local meaning.

Tracker

Records attributable lifecycle evidence in the proposed Relational Trace; independently witnessed integrity is an experimental extension.

Finder

Proposes separately governed relations between objects.

Assembler

Emits versioned manifests and projections.

Cultivator

Proposes governed improvements from feedback and outcomes.

Mediator

Resolves permitted exchange and records the decision.

Wrapper, Mapper and Tracker carry the adoption path. The remaining four are part of the model but are not needed to run the first step.

Visibility scopes

Knowledge circulates privately, locally, across a federation or openly, subject to the conditions attached to it. These are defaults for policy evaluation, not perimeters and not a required progression toward publication: private sits inside local sits inside federated, but access is never inherited upward and nothing is safe by virtue of being inside a scope. Publishing to a wider scope is always an explicit decision, and visibility is evaluated per object, per field and per relationship rather than for a whole object at once.

The shared place where permitted objects become visible to other actors is the Agora.

Actor identity and selective disclosure

An actor’s participation may be visible without revealing their identity. Participation, authority and identity disclosure are separate decisions. Identity disclosure is evaluated for each recipient and purpose, just like visibility of object fields and relationships.

Identified

The recipient sees permitted identity attributes. Visibility alone does not establish verification.

Masked / pseudonymous

A limited identity or context-scoped reference is visible. An underlying identity may be held locally; access to it requires a separate decision.

Anonymous

No identifying link is retained within the defined contribution context. Later identification cannot be promised, and indirect identifying clues must still be assessed.

Unknown

Identity was not established or is absent from the source. This is distinct from deliberately withheld identity and from anonymity.

A municipality might share a sensor inspection and evidence of an authorised maintenance role without revealing the technician’s name. An anonymous report can also be accepted where policy allows, but cannot satisfy an authority requirement without the required evidence.

Policy covers actor existence, identifiers, roles, relationships and history. Context-scoped pseudonyms reduce unnecessary linkage. Search results, exports, timestamps, locations, signatures and logs must not bypass masking. Protected audit evidence does not require public identification or a retained identity mapping for every contribution.

The current schemas, validator and demo do not implement or verify actor anonymity, masking, identity recovery or selective-disclosure enforcement.

An intertween

290 kommuner apply the same national laws. Each is entitled to interpret them locally, and each does, in riktlinjer, bedömningsstöd and accumulated practice. When two kommuner read the same paragraph differently, that divergence is real and it has consequences. It is also owned by nobody: not by either kommun, whose mandate ends at its own border; not by the tillsynsmyndighet, which supervises compliance rather than curating interpretation; not by the lagstiftare, who left the space open deliberately.

That is an intertween: a matter that exists between mandates, that no one is failing to handle, and that no one is positioned to see. It becomes owned only when an actor changes what they do about it. Ownership emerges; it is not assigned at detection.

Divergence is a legitimate outcome, not an error to be reconciled. Swedish myndighetsutövning requires an individual assessment in every case, and a local authority that adopted another's model and applied it mechanically would be acting unlawfully. What changes is that a kommun interpreting a paragraph can see that twenty others have interpreted it, on what basis, and what happened next, and can then decide differently, knowingly. A documented and reasoned divergence is a stronger legal position than an isolated one.

Parties

Five roles are kept apart, because collapsing them is how knowledge quietly becomes property.

creator

Who made the thing.

contributor

Who added evidence, translation, validation or context.

custodian

Who is answerable for maintaining and protecting it. A duty of care, not a property claim.

rightsHolder

Who may set conditions. Often nobody, and left empty rather than guessed.

beneficiary

Who any compensation would be owed to, where compensation exists at all.

Registering an object establishes none of these as ownership, and a content hash demonstrates that content is unchanged rather than who owns it. Knowledge is made legible and portable without being made alienable.

Standards profiled

PROV-O

Provenance and attribution. Used as published; the profile constrains which agents and activities must be present on a wrapped object, and extends nothing.

ODRL

Rights and usage policy. Permission, duty and prohibition ride with the object. Enforcement is deliberately left alone in this specification.

DPV

Purpose and legal context. Carries the legal basis a Swedish public body must be able to state.

DCAT

Discovery through existing catalogues, rather than a new catalogue.

Transport, identity, connectors and catalogues remain with existing infrastructure. Intertween does not compete with the rules; it is one way to implement them. Detailed mappings and conformance remain work to validate.

Conformance

Four levels, each establishing something the level below it does not.

Passing level 0 does not establish full protocol conformance, lawful processing, safe disclosure, production readiness or federation capability. The harness tests level 0 only, against sources that are already public.

What the existing checks establish. The object validator checks a limited structural profile; it does not verify source authenticity, permissions or node connectivity. The separate integrity experiment verifies selected signatures and history commitments in a local simulation. Neither establishes production federation, independent witnesses or full protocol conformance.

Validate an object against this profile →

Reference

The terms the demo marks with [Ref]. Definitions follow the published protocol specification. One group is marked as profile-level: those fields belong to the demo scenario and are illustrative rather than normative.

See the terms in the demo →