DP7 - Interoperability
Patches and comments are scoped to the whole document family, not to a single revision. When you open a revision, highlights show what still applies to that revision body; anything anchored to text a later revision removed is listed as needing re-anchoring, and anything that can no longer be merged at all is marked obsolete. See all patches.
Comparing Revision 00 (original) with Revision 01. Struck-through text was removed; highlighted text was added.
# DP7 – Simplicity and Interoperability
*The Meta-Layer is designed to reduce friction, not add it — prioritizing clarity, composability, and seamless interaction across domains.*
<!-- dp-local-version: 1.0 | standardized: 2026-07-27 -->
## 1. Purpose of This Draft
This draft articulates Desirable Property 7 (DP7) as the condition under which participants, communities, and systems can move across tools, environments, and contexts without losing identity, history, value, or agency.
Interoperability is the primary boundary where power is contested in the meta-layer. Systems that appear interoperable locally but degrade meaning, enforceability, or usability across boundaries will systematically re-centralize control.
## 2. Problem Statement
In today’s web, systems are technically connected but structurally discontinuous.
DP7 reframes interoperability as continuity under movement and participation. Not just that things move, but that they remain valid, trusted, and usable after they move, and that new systems can enter and participate without breaking that continuity.
## 3. Threats and Failure Modes
### 3.1 Interoperability theater Systems simulate openness while preserving control.
**Why this matters:** Interoperability without permissionless participation reintroduces centralized control through integration policy rather than infrastructure.
## 4. Core Principle
Interoperability in the meta-layer means that identity, data, value, governance, and participation can move across systems without losing integrity, meaning, enforceability, or legitimacy.
**What this feels like:** Switching systems does not mean starting over, nor does it mean accepting a degraded version of prior participation.
## 5. Primary Mechanisms and Structural Conditions
### 5.0 Interoperability Layer: Continuity, Translation, and Power
Interoperability requires more than shared formats. It requires a layer that preserves meaning, authority, and usability across boundaries where systems may have conflicting incentives.
#### Portable objects
All core system elements must be representable as portable, structured objects:
- identity objects (DP1) - policy objects (DP12) - incentive objects (DP9) - ownership objects (DP20) - transaction objects (DP6)
These objects must carry sufficient context to remain interpretable outside their origin.
They should also declare their intended use and trust assumptions so receiving systems can enforce appropriate constraints. Without declared intent, objects may be misapplied in contexts that invalidate their meaning.
#### Semantic translation and mapping
Systems must define how objects are interpreted across contexts:
- schema translation - semantic alignment - version compatibility
Mappings must explicitly declare where information is preserved, transformed, or lost.
They should include machine-readable diffs of meaning so downstream systems can reason about equivalence. Absent explicit mapping, silent reinterpretation becomes a primary vector for drift and exploitation.
#### Integrity and lineage preservation
Objects must retain:
- authorship - timestamps - signatures - lineage and derivation history
Without this, imported objects cannot be trusted or verified.
Lineage should be queryable across hops to reconstruct full transformation chains. Breaks in lineage must be flagged as risk, not treated as benign gaps.
#### Permission and consent continuity
Access controls and consent conditions must persist across systems.
Participants must not lose control over their data or identity during transfer (DP4, DP2).
Consent scopes should be renegotiable at boundaries with clear previews of changes. Implicit expansion of scope during transfer must be disallowed or explicitly surfaced.
#### Interoperability receipts
All cross-system transfers generate verifiable records:
- what moved - how it was transformed - what constraints applied - who mediated the transfer
These receipts enable audit and dispute resolution (DP15).
Receipts should be machine-verifiable and linkable to governance and commerce records. Missing or partial receipts must downgrade trust for the resulting state.
#### Conflict resolution under power asymmetry
Systems must define how conflicts are resolved when:
- governance rules differ - economic conditions diverge - trust models are incompatible
Conflict resolution is not neutral. It must be visible, contestable, and governed.
Resolution pathways should declare precedence rules and appeal mechanisms. Opaque arbitration at boundaries is a primary route to capture.
#### Loss and degradation signaling
All interoperability pathways must explicitly signal:
- what meaning is lost - what functionality is degraded - what guarantees no longer apply
This prevents silent failure of continuity.
Signals should be standardized and user-visible at decision time, not buried in logs. Systems that cannot signal degradation must restrict the transfer or require explicit override.
#### Interoperability memory
All transfers and mappings persist as a linked history:
- prior versions - transformation paths - disputes and reversals
This creates a system-level memory of how interoperability evolves over time.
Memory should support querying for systemic patterns such as drift or repeated loss. Without analysis over memory, issues recur undetected.
#### Composable participation via governed interfaces
The meta-layer must allow third-party tools, services, and extensions (e.g., smart tags, overlays, sidebars, core services) to plug into shared interfaces **without prior permission**, provided they conform to declared interfaces and governance constraints.
Conforming integrations must:
- declare permissions and data scopes up front - bind to zone policies at runtime (DP12) - operate within containment tiers and rate limits (DP13) - provide signed artifacts and provenance (DP15) - expose auditable behavior and event logs
Non-conforming integrations must be sandboxed, rate-limited, or blocked.
This enables openness to innovation while preventing unbounded execution and platform capture.
Interface contracts should be versioned and testable, with conformance suites available publicly. Discovery systems must incorporate reputation and probation to resist spam and gaming.
**Example (Composable Integration):** A third-party sidebar app plugs into a community zone. At install, it declares permissions (read annotations, write highlights) and data scopes. The zone’s policy automatically constrains it: external network calls are limited, access to private threads is denied, and actions are rate-limited. The app runs in a sandbox and emits signed event logs. Initially, it appears in a probation tier with limited visibility. As it accumulates positive, non-abusive usage and passes audits, its privileges and discoverability increase. If it violates policy, it is throttled or quarantined with a public receipt explaining why.
### 5.1 Open schemas and standards
A failure mode is silent degradation, where participants believe continuity exists but critical properties have been lost.
## 6. Governance, Accountability, and Agency Surfaces
Interoperability is not neutral infrastructure. It encodes decisions about what persists, what degrades, and who controls movement.
**Example:** A community allows import of reputation from another network only with attested receipts and places imported identities in a probation state with reduced privileges until local activity establishes trust.
## 7. Incentives and Power Analysis
Interoperability is where platform power is defended or broken.
When incentives favor staying, ecosystems centralize. When incentives favor honest movement, ecosystems compose.
## 8. Community Signals Informing DP7
Across ecosystems, recurring signals indicate interop failure at scale:
DP7 treats these signals as requirements for preserving meaning, not just moving bytes.
## 9. Non-Goals and Explicit Boundaries
DP7 does not:
- require full compatibility between all systems or schemas - mandate a single global standard or governing body - eliminate competition among platforms or protocols - force communities to accept all imports without policy
DP7 defines the conditions under which movement is legitimate, intelligible, and safe.
## 10. Minimum Alignment (Non-Normative)
A DP7-aligned system should, at minimum:
- support export of core objects with preserved structure, signatures, and lineage - provide import pathways with explicit mapping, lossiness disclosure, and policy constraints - maintain permission and consent continuity during transfers (DP2, DP4) - generate interoperability receipts for all transfers (who, what, when, how transformed) - offer dispute and rollback pathways for harmful or incorrect imports - avoid material asymmetry between import and export without disclosure
Partial compliance that omits integrity, consent, or auditability should not be treated as alignment.
## 11. Open Questions and Future Work
Key open questions include:
- how to standardize semantics (reputation, credentials, governance roles) without flattening local meaning - how to achieve Sybil resistance and anti-impersonation across interoperable identity systems (DP1) - how to reconcile regulatory boundaries with cross-system value portability (DP6) - how to design bridges that are both secure and usable without becoming choke points - how to compensate shared infrastructure (indexes, relays) without enabling capture - how to evolve schemas without breaking historical continuity (versioning and migration)
These questions sit at the boundary of protocol design, governance, and law.
## 12. Relationship to Other Desirable Properties
DP7 is the continuity layer across the meta-layer stack:
- DP3 ensures governance can evolve across systems rather than reset per platform - DP4 constrains data movement and enforces minimization during transfer - DP6 ensures commerce artifacts (transactions, balances, receipts) remain usable across contexts - DP9 carries incentive history and attribution across tools without silo lock-in - DP12 enables policy translation and enforcement across environments - DP13 contains risks introduced by cross-system automation and agents - DP15 provides verifiable provenance for imported objects - DP17 sustains shared infrastructure required for interoperability - DP20 preserves ownership and fork rights across environments
DP7 binds these properties into a coherent, cross-system reality.
## Evaluation Criteria
DP7 alignment cannot be assessed by inspecting an API surface. It must be evaluated by moving real objects across real boundaries and measuring what survives.
The following criteria are diagnostic rather than exhaustive. Each is written so that a negative answer identifies a specific structural defect rather than a general complaint.
### Continuity of meaning
- After transfer, can objects still be interpreted without access to the origin system? - Do identity, reputation, and credential objects retain the context that made them meaningful (source, method, scope)? - Can a receiving system reconstruct lineage across multiple hops?
### Symmetry of movement
- Is export as capable, fast, and complete as import? - Are fees, rate limits, and friction comparable in both directions? - Are material asymmetries disclosed at the point of decision rather than in terms of service?
### Enforceability after transfer
- Do governance rules continue to bind behavior in the receiving environment, or do they degrade to advisory text? - Are precedence rules declared when the origin and destination policies conflict? - Can a community refuse, quarantine, or probate an import under its own policy?
### Integrity and verifiability
- Are signatures, authorship, and timestamps preserved and checkable? - Are broken lineage chains flagged as risk rather than treated as benign gaps? - Can a participant reject a degraded import without losing the rest of their history?
### Disclosure of loss
- Does the system state, before the transfer commits, what meaning will be lost and what guarantees will no longer apply? - Is degradation signaled in the interface at decision time, not only in logs? - Are transfers blocked or gated when degradation cannot be described?
### Auditability
- Does every cross-system transfer produce a receipt naming what moved, how it was transformed, and who mediated it? - Can aggregate interop flows be audited for capture and leakage without exposing individual participants? - Are disputes, reversals, and postmortems linked back to the schema, policy, or bridge change that caused them?
### Anti-capture posture
- Are indexes, relays, registries, and discovery surfaces controlled by more than one party? - Can a competing implementation pass a public conformance suite without privileged access? - Do discovery rankings resist paid or incumbent advantage for pluggable tools?
### Participant experience of exit
- Can a non-technical participant leave with their identity, history, balances, and rights intact? - How long does a complete exit take, and what is measurably lost? - Is the exit path tested regularly, or only claimed?
**Why this matters:** Interoperability claims are cheap. These criteria convert the claim into an observable property of a specific transfer between two specific systems.
## Implementation Patterns
These patterns translate DP7 into design moves that can be adopted incrementally. None of them require a global standards body, and each can be evaluated against the criteria above.
### Public conformance suites
Publish versioned, executable test suites for every shared interface. Any implementation can run them, and results can be published as attestations. Conformance becomes evidence rather than assertion.
### Object envelopes with declared intent
Wrap every portable object in an envelope carrying schema version, intended use, trust assumptions, consent scope, and signature. Receiving systems enforce constraints from the envelope rather than inferring them, so that purpose binding survives the crossing rather than resetting at it (DP4, DP12).
### Lossiness manifests
Ship every mapping with a machine-readable statement of what is preserved, transformed, and dropped. Interfaces render the manifest as a plain-language preview before a transfer commits.
### Receipt logs for transfers
Emit a signed receipt for every import and export, linked to the policy version applied and the mediating party (DP15). Receipts are queryable by the participant, the origin community, and the destination community.
### Probation tiers for new integrations
Admit third-party tools at reduced privilege and visibility, with containment tiers and rate limits enforcing the reduction rather than a review promise (DP13). Increase capability as audits pass and non-abusive usage accumulates. Demote automatically on policy violation, with a public receipt explaining why.
### Bridge attestation and risk tiers
Treat bridges and translators as accountable actors with published operators, audit history, and risk tiers, bound to a responsible entity rather than operating as anonymous infrastructure (DP1). Apply circuit breakers, volume caps, and anomaly detection proportional to tier.
### Dual-write migration windows
During schema evolution, write both old and new representations for a bounded period, with explicit deprecation dates and migration guidance. Historical continuity is preserved rather than reconstructed later.
### Scheduled exit drills
Periodically perform and publish a full export-and-reimport of a representative account into an independent implementation. Report duration, failures, and losses. Untested exit paths are assumed broken.
### Federated discovery with reputation weighting
Distribute indexing and discovery across multiple operators, weight surfacing by reputation and audit status, and rate-limit new entrants to resist flooding without gatekeeping participation. Discovery is an incentive surface, and concentration of it reproduces platform leverage under another name (DP9).
### Degradation-aware interfaces
Standardize visual and textual signals for reduced guarantees, so participants encounter the same vocabulary of degradation across tools rather than per-platform euphemisms.
## 13. Foresight and Failure Design
Interoperability systems must assume adversarial pressure, economic incentives for capture, and rapid evolution of tools and agents.
Failure is expected. Silent or irreversible failure is not.
## Interoperability System Layer: Continuity, Translation, and Power
Interoperability requires more than shared formats. It requires a layer that preserves meaning, authority, and usability across boundaries where systems may have conflicting incentives.
### Portable objects
All core system elements must be representable as portable, structured objects:
- identity objects (DP1) - policy objects (DP12) - incentive objects (DP9) - ownership objects (DP20) - transaction objects (DP6)
These objects must carry sufficient context to remain interpretable outside their origin.
They should also declare their intended use and trust assumptions so receiving systems can enforce appropriate constraints. Without declared intent, objects may be misapplied in contexts that invalidate their meaning.
### Semantic translation and mapping
Systems must define how objects are interpreted across contexts:
- schema translation - semantic alignment - version compatibility
Mappings must explicitly declare where information is preserved, transformed, or lost.
They should include machine-readable diffs of meaning so downstream systems can reason about equivalence. Absent explicit mapping, silent reinterpretation becomes a primary vector for drift and exploitation.
### Integrity and lineage preservation
Objects must retain:
- authorship - timestamps - signatures - lineage and derivation history
Without this, imported objects cannot be trusted or verified.
Lineage should be queryable across hops to reconstruct full transformation chains. Breaks in lineage must be flagged as risk, not treated as benign gaps.
### Permission and consent continuity
Access controls and consent conditions must persist across systems.
Participants must not lose control over their data or identity during transfer (DP4, DP2).
Consent scopes should be renegotiable at boundaries with clear previews of changes. Implicit expansion of scope during transfer must be disallowed or explicitly surfaced.
### Interoperability receipts
All cross-system transfers generate verifiable records:
- what moved - how it was transformed - what constraints applied - who mediated the transfer
These receipts enable audit and dispute resolution (DP15).
Receipts should be machine-verifiable and linkable to governance and commerce records. Missing or partial receipts must downgrade trust for the resulting state.
### Conflict resolution under power asymmetry
Systems must define how conflicts are resolved when:
- governance rules differ - economic conditions diverge - trust models are incompatible
Conflict resolution is not neutral. It must be visible, contestable, and governed.
Resolution pathways should declare precedence rules and appeal mechanisms. Opaque arbitration at boundaries is a primary route to capture.
### Loss and degradation signaling
All interoperability pathways must explicitly signal:
- what meaning is lost - what functionality is degraded - what guarantees no longer apply
This prevents silent failure of continuity.
Signals should be standardized and user-visible at decision time, not buried in logs. Systems that cannot signal degradation must restrict the transfer or require explicit override.
### Interoperability memory
All transfers and mappings persist as a linked history:
- prior versions - transformation paths - disputes and reversals
This creates a system-level memory of how interoperability evolves over time.
Memory should support querying for systemic patterns such as drift or repeated loss. Without analysis over memory, issues recur undetected.
### Composable participation via governed interfaces
The meta-layer must allow third-party tools, services, and extensions (e.g., smart tags, overlays, sidebars, core services) to plug into shared interfaces **without prior permission**, provided they conform to declared interfaces and governance constraints.
Conforming integrations must:
- declare permissions and data scopes up front - bind to zone policies at runtime (DP12) - operate within containment tiers and rate limits (DP13) - provide signed artifacts and provenance (DP15) - expose auditable behavior and event logs
Non-conforming integrations must be sandboxed, rate-limited, or blocked.
This enables openness to innovation while preventing unbounded execution and platform capture.
Interface contracts should be versioned and testable, with conformance suites available publicly. Discovery systems must incorporate reputation and probation to resist spam and gaming.
**Example (Composable Integration):** A third-party sidebar app plugs into a community zone. At install, it declares permissions (read annotations, write highlights) and data scopes. The zone’s policy automatically constrains it: external network calls are limited, access to private threads is denied, and actions are rate-limited. The app runs in a sandbox and emits signed event logs. Initially, it appears in a probation tier with limited visibility. As it accumulates positive, non-abusive usage and passes audits, its privileges and discoverability increase. If it violates policy, it is throttled or quarantined with a public receipt explaining why.
## Relationship to Other Desirable Properties
DP7 is the continuity layer across the meta-layer stack:
- DP3 ensures governance can evolve across systems rather than reset per platform - DP4 constrains data movement and enforces minimization during transfer - DP6 ensures commerce artifacts (transactions, balances, receipts) remain usable across contexts - DP9 carries incentive history and attribution across tools without silo lock-in - DP12 enables policy translation and enforcement across environments - DP13 contains risks introduced by cross-system automation and agents - DP15 provides verifiable provenance for imported objects - DP17 sustains shared infrastructure required for interoperability - DP20 preserves ownership and fork rights across environments
DP7 binds these properties into a coherent, cross-system reality.
## Non-Goals and Explicit Boundaries
DP7 does not:
- require full compatibility between all systems or schemas - mandate a single global standard or governing body - eliminate competition among platforms or protocols - force communities to accept all imports without policy
DP7 defines the conditions under which movement is legitimate, intelligible, and safe.
## Minimum DP7 Alignment (Non-Normative)
A DP7-aligned system should, at minimum:
- support export of core objects with preserved structure, signatures, and lineage - provide import pathways with explicit mapping, lossiness disclosure, and policy constraints - maintain permission and consent continuity during transfers (DP2, DP4) - generate interoperability receipts for all transfers (who, what, when, how transformed) - offer dispute and rollback pathways for harmful or incorrect imports - avoid material asymmetry between import and export without disclosure
Partial compliance that omits integrity, consent, or auditability should not be treated as alignment.
## Open Questions and Future Work
Key open questions include:
- how to standardize semantics (reputation, credentials, governance roles) without flattening local meaning - how to achieve Sybil resistance and anti-impersonation across interoperable identity systems (DP1) - how to reconcile regulatory boundaries with cross-system value portability (DP6) - how to design bridges that are both secure and usable without becoming choke points - how to compensate shared infrastructure (indexes, relays) without enabling capture - how to evolve schemas without breaking historical continuity (versioning and migration)
These questions sit at the boundary of protocol design, governance, and law.
## 14. Path Toward ML-RFC
Advancing DP7 toward ML-RFC requires:
- standardizing core object schemas (identity, policy, incentive, ownership, transaction) - defining interoperability receipt formats and audit events - building reference bridges and adapters with open security reviews - piloting cross-system governance and commerce scenarios with real communities - aligning with regulators on portability, custody, and liability boundaries
Progress should be demonstrated through live interop scenarios, not only specifications.
## 15. Closing Orientation
DP7 is the condition under which the meta-layer remains a network rather than reverting to a set of silos.
Published: 2026-08-08
Pages: 9 | Words: 4424
What changed:
Synced from the book local rail (content/local/dpN.md), which carries the current working text for this chapter: expanded sections, renamed and renumbered headings, and editorial cleanup since the last revision. Published as a new revision so prior revisions stay intact.
Published: 2026-08-05
Pages: 9 | Words: 4408
What changed:
Numbered section headings and cross-reference fixes for collaborative review
Published: 2026-08-04
Pages: 9 | Words: 4363
What changed:
Synced from the book local rail (content/local/dpN.md), which carries the current working text for this chapter: expanded sections, renamed and renumbered headings, and editorial cleanup since the last revision. Published as a new revision so prior revisions stay intact.