Knowledge Objects, context, projection, mandate, learning sovereignty and reflexivity.
STANDARDS & INTEROPERABILITY · English
A knowledge and accountability profile. Not another stack.
The protocol builds on shared infrastructure for transport, identity, cataloguing and exchange. It adds a portable object for meaning, provenance, legal conditions, attribution and matters that fall between mandates.
Define. Profile. Reuse.
A smaller claim makes the protocol more implementable: define only the missing knowledge contract, profile standards where the protocol needs specific semantics, and reuse the rest.
Established standards such as ODRL and PROV-O for protocol-specific use.
Transport, identity, catalogues and infrastructure that already exist.
Reuse the substrate. Add the answerable object.
Create, transform and use knowledge in a local domain or workflow.
Establish participants and make permitted resources discoverable.
Provide transport, trust, negotiation and delivery between contexts.
Defines portable meaning, provenance, conditions, attribution and relational knowledge.
The protocol MUST NOT present itself as an alternative identity provider, transport protocol, catalogue, connector or negotiation engine. It can be profiled for any compatible infrastructure or jurisdiction.
A component in a larger architecture.
The statuses describe the protocol's intended architectural position. They do not claim formal DSSC conformance.
Building blockProtocol positionRelationship
Data ModelsThe protocol defines
A cross-domain information model for Knowledge Objects and their relations.
Data ExchangeThe protocol uses
Established exchange protocols. The protocol is a payload and policy profile, not transport.
Provenance & Traceabilityprotocol profiles
PROV-O for origin, derivation, validation and traceable change.
Identity & AttestationThe protocol uses
Established identity infrastructure and Verifiable Credentials.
Access & Usage Policiesprotocol profiles
An ODRL profile for access, mandate and learning sovereignty.
Trust FrameworkOpen question
Requires common governance, a named steward and enforceable rules.
DescriptionsThe protocol uses
DCAT and DCAT-AP-SE for describing data, services and offerings.
Publication & DiscoveryThe protocol uses
Existing and federated catalogues for publication and discovery.
Value Creation ServicesOutside Core
Enabled by the protocol, but not defined by the core specification.
Three rights dimensions remain separate.
Permission to read a Knowledge Object does not imply a mandate to act, permission to redistribute, or permission to use it for model improvement.
Permission constrained by recipient, purpose, time, context and projection.
A separate Policy with a distinct Party role. Access never grants mandate implicitly.
Training, fine-tuning, benchmarking and permanent adaptation require explicit Permission.
AssetPermissionProhibitionDuty + ConstraintParty + roleSeparate Policyintw:train ActionA conformant protocol evaluator must not allow a rights-critical action when it cannot interpret every policy term that affects that action.
ODRL makes permissions, prohibitions and duties machine-readable, but it does not enforce them by itself. Unknown, incomplete or invalid rights terms must result in rejection, not implicit permission.
Keep the method. Connect its knowledge.
The protocol can support established ways of working without absorbing or redefining them. Support means that their outputs, transitions and learning can be represented through the protocol. It does not imply certification, endorsement or formal conformance.
Foresight methodMapped
TAIDA
Kairos Future framework for moving from environmental scanning through analysis and vision to decisions and action.
Open mapping →PracticeSupported
Scenario planning
Scenarios can be governed as versioned Knowledge Objects and composed into situated Knowledgers.
See Foresight-to-Action →ApproachSupported
Systems thinking
Typed relations, context, feedback and Intertweens make cross-system effects inspectable without imposing one central model.
See the Intertween →PracticeSupported
Organisational learning
Tracked outcomes, corrections and reuse can return as reviewable learning instead of disappearing after delivery.
See Cultivator →Evidence before equivalence.
This crosswalk records where the protocol reuses, profiles, maps to or merely aligns with adjacent standards. It is an architectural assessment—not a declaration of certification, endorsement or completed conformance.
[REUSE]The protocol relies on an existing standard without redefining it.
[PROFILE]The protocol constrains or extends an existing standard for a declared use.
[MAP]The protocol publishes an explicit correspondence between models.
[ALIGN]The concepts support each other, but no machine-testable conformance is claimed.
StandardAssessmentCoverage and protocol contributionOpen gap
Matrix specification ↗Federation precedent
Architectural precedentStrong separation-of-concerns fit
Covers: Open protocol governance, independent clients and homeservers, capability discovery, signed events and provider choice.
The protocol adds: The protocol applies the separation of protocol, local authority and hosting to knowledge, but exchanges purpose-bound projections instead of replicating room history.
Matrix is not a protocol transport profile and does not supply protocol rights, epistemic or knowledge-object semantics.
DSSC Blueprint 3.0 ↗Architecture context
ComplementaryStrong architectural fit
Covers: Data-space business, governance, legal and technical building blocks.
The protocol adds: The protocol supplies a portable knowledge and policy object inside that wider architecture.
No formal DSSC conformity assessment has been completed.
Simpl-Open ↗Federated data-space infrastructure
Potential implementation substrateStrong infrastructure fit
Covers: Participant trust, catalogues, policies, contracts and resource exchange.
The protocol adds: The protocol adds contextual Knowledge Objects, local mappings, governed relationships, reflexivity and learning events.
No implemented protocol to Simpl compatibility profile or adapter has been tested.
W3C ODRL 2.2 ↗Policy semantics
Profile candidateStrong semantic fit
Covers: Machine-readable permissions, prohibitions, duties, parties, actions and constraints.
The protocol adds: The protocol separates access, mandate and learning, then defines protocol-specific actions and projections.
The protocol ODRL profile, test cases and evaluator behaviour remain work.
W3C PROV-O ↗Provenance mapping
Mapping candidateStrong conceptual fit
Covers: Entities, activities, agents, derivation, attribution and generation.
The protocol adds: The protocol adds source observations, mapping versions, validation events and conservative lifecycle states.
A normative term-by-term mapping and SHACL validation artefacts are not yet published.
W3C DPV 2.0 ↗Privacy and legal context
Profile candidateStrong semantic fit
Covers: Purpose, processing, legal basis, data roles, jurisdiction, measures and risk.
The protocol adds: The protocol keeps legal basis and purpose distinct from ODRL usage permissions and carries their assessment state with the object.
DPV is a Community Group specification. A Swedish protocol profile and legal review remain to be completed.
DCAT 3 / DCAT-AP-SE 3.0.1 ↗Publication bridge
Partial mappingStrong discovery fit
Covers: Catalogues, datasets, data services, distributions, publishers and access metadata.
The protocol adds: The protocol can expose a safe catalogue projection while the full Knowledge Object remains governed elsewhere.
A Knowledge Object is not always a Dataset; the class mapping must remain profile-dependent.
Eclipse Dataspace Components / IDSA connectors ↗Exchange substrate
ComplementaryClear separation of concerns
Covers: Connector-based data exchange, participant interaction, policy and contract negotiation.
The protocol adds: The protocol adds the portable knowledge object, context mapping, provenance, attribution and Intertween ownership lifecycle.
The protocol does not duplicate transport, connector runtime or contract negotiation. No connector adapter has been implemented.
ISO 30401:2018 ↗Management-system context
Governance complementConceptual alignment
Covers: Organisational context, leadership, knowledge processes, learning and continual improvement.
The protocol adds: The protocol offers technical objects, provenance and federation mechanisms that may support those organisational practices.
ISO 30401 is not an information model. The protocol does not claim certification or technical conformance to it.
Fields create evidence for assessment. They do not perform the assessment.
The protocol itself is jurisdiction-neutral. This crosswalk demonstrates how the same core fields can be mapped to one regional legal context. Other jurisdictions and domains can publish their own profiles without changing the core protocol.
Protocol fieldExample frameDesign functionBoundary
legal_basis + purposeGDPR and sector-specific law ↗Records the assessed legal basis and declared purpose for processing. It remains separate from ODRL permission.
Required when personal data is processedclassification + disclosureOSL and offentlighetsprincipen ↗Carries classification, confidentiality basis and the status of a disclosure assessment. It does not decide secrecy automatically.
Assessment remains with the responsible authorityjurisdictionSecurity and data-protection rules ↗Records residency, processing location, third-country conditions and whether technical availability has been assessed as disclosure.
Fail closed when a critical assessment is missingprovenance + lifecycleArkivlagen ↗Preserves source, versions, events and disposition-relevant history so archival requirements can be mapped by a domain profile.
The protocol does not replace archival appraisalschema + interface profileSwedish interoperability requirements ↗Makes a versioned, machine-testable profile possible for recurring or large-scale data sharing while preserving security and proportionality exceptions.
Law effective 15 August 2026provenance + human control + use conditionsEU AI Act ↗Can carry evidence needed by an AI-system profile, including provenance, intended purpose, review and restrictions. The protocol alone does not establish AI Act compliance.
Profile-specific assessment required!guardrail / An unclaimed Intertween should normally remain a meta-observation about mandates, policies and topics. If resolving it requires regulated data, population is blocked until responsibility, purpose, legal basis and required assessments are recorded.
Trust also requires visible limits.
- No external standards body has certified the protocol.
- Conceptual similarity is not syntactic or behavioural conformance.
- Mappings become credible only when versioned, testable and accompanied by examples.
- Governance, stewardship and compatibility guarantees remain adoption-critical.
Open infrastructure. Reusable knowledge.
These initiatives do not certify or endorse the protocol. They describe the policy and infrastructure environment in which an open, federated knowledge the protocol could become useful.
Open Source Strategy ↗Open specifications, reuse, contribution and control.Apply AI ↗Demand for transferable and governed European AI capabilities.Next Generation Internet ↗Open, decentralised and interoperable digital building blocks.Simpl ↗Potential trust and exchange infrastructure for federated data spaces.
Open source makes components shareable. Apply AI creates demand. Simpl can enable trusted exchange. The protocol makes knowledge transferable and capable of learning.
A small core with explicit contracts.
The core remains infrastructure-independent. Compatibility profiles connect it to particular standards and federation environments without making them prerequisites.
Trace integrity and standards
The proposed Federated Integrity profile uses Merkle inclusion and consistency concepts described in RFC 9162. That reference describes Certificate Transparency, not an Intertween protocol implementation. Our experimental serialization and signature format are not frozen standards. Witness trust, key rotation, authenticated index completeness and privacy-preserving proofs still need specification.
Read the profile and schemas ↗