Canonical specification
Dot Protocol Specification v0.1
A Constitutional Representation Specification for Computationally Interoperable Knowledge Objects
Stefaan Vossen
Canonical Reference
This document constitutes the canonical normative specification of Dot Protocol v0.1. Research papers, implementations and future successor specifications should cite this document when referring to the normative definition of Dot Protocol.
Document Metadata:
Document Type: Constitutional Representation Specification
Status: Candidate Specification v0.1
Author: Stefaan Vossen
Research Programme: Dot Theory
Specification Identifier: DPS-0.1
Date: July 2026
Constitutional Status: Candidate Specification
Supersedes: None
Superseded By: —
Normative Language
See Section 3.
Constitutional Statement
Scientific representations are constitutional objects before they become computational objects. Computational objects possess explicit state. This specification defines the constitutional requirements through which independently constructed representations become computationally interoperable while preserving their declared representational meaning.
Specification Design Principle
This specification intentionally follows the Minimum Constitutional Description (MCD) principle established within Dot Theory. Every primitive object, requirement and invariant included herein has been retained only where its removal would reduce the specification's constitutional integrity or computational interoperability. The document therefore seeks completeness through minimality rather than through exhaustive enumeration.
Copyright and Research Use
© 2026 Stefaan Vossen.
This specification forms part of the Dot Theory research programme.
Short quotations for scholarly discussion, review and criticism are permitted with appropriate attribution.
Implementations, analyses, interoperability experiments and independent evaluations are encouraged provided that the original specification is appropriately cited and derivative modifications are clearly distinguished from the canonical specification.
The current canonical version is maintained at:
This document is a living specification intended to evolve through constitutionally governed successor states.
Table of Contents
1. Purpose
1.1 Purpose
1.2 Scope
1.3 Non-Goals
1.4 Relationship to the Dot Theory Constitutional Corpus
2. Normative Language
2.1 Normative Terminology
2.2 Constitutional Interpretation
2.3 Conformance
2.4 Informative Material
3. Problem Statement and Research Question
3.1 Problem Statement
3.2 Research Question
3.3 Research Hypothesis
3.4 Design Objectives
3.5 Expected Contribution
4. Definitions
4.1 Introduction
D-1 Representation
D-2 Representational Context
D-3 Computational State
D-4 Computational Interoperability
D-5 Representational Governance
D-6 Governed Knowledge Object (GKO)
D-7 Dot Protocol
D-8 Representational Provenance
4.2 Definition Relationships
5. Requirements
5.1 Introduction
5.2 General Requirements
5.3 Mandatory Representational Requirements
5.4 Constitutional Requirements
5.5 Minimality Requirement
5.6 Conformance Criterion
6. Object Model
6.1 Introduction
6.2 Object Hierarchy
6.3 Governed Knowledge Object Structure
6.4 Mandatory Object Relationships
6.5 Object Independence
6.6 Minimality Claim
6.7 Constitutional Relationship
7. Dot Protocol
7.1 Introduction
7.2 Protocol Overview
7.3 Protocol Operation P-1: Representation Registration
7.4 Protocol Operation P-2: Context Declaration
7.5 Protocol Operation P-3: Residual Declaration
7.6 Protocol Operation P-4: Provenance Registration
7.7 Protocol Operation P-5: Governed Knowledge Object Formation
7.8 Protocol Operation P-6: Revision
7.9 Protocol Invariants
7.10 Protocol Completion
8. Computational Operations
8.1 Introduction
8.2 Operational Principle
8.3 Supported Computational Operations
8.4 Computational Independence
8.5 Constitutional Consequences
8.6 Relationship to Artificial Intelligence
8.7 Computational Consequence
9. Reference Implementation
9.1 Introduction
9.2 Reference Domain
9.3 Example Representations
9.4 Governed Knowledge Objects
9.5 Computational Interoperability
9.6 Constitutional Agency
9.7 Generalisation
9.8 Reference Implementation Summary
10. Formal Schemas
10.1 Purpose
10.2 Canonical Governed Knowledge Object Structure
10.3 Identifier Requirements
10.4 YAML Reference Schema
10.5 Minimal YAML Instance
10.6 Explicit Null and Unknown States
10.7 JSON Reference Instance
10.8 JSON Schema
10.9 Schema Conformance
10.10 Schema Extensibility
10.11 Schema Translation
10.12 Formal Schema Status
11. Open Problems
11.1 Status of This Section
11.2 Central Conjecture
11.3 Minimality of the State Model
11.4 Definition of Representation
11.5 Framework Granularity
11.6 Operator Granularity
11.7 Admissibility and Failure Conditions
11.8 Residual Structure
11.9 Provenance Sufficiency
11.10 Revision and Representational Identity
11.11 Measurement of Interoperability
11.12 Relationship to Ingestion, Structure and Assessment
11.13 Agency and Constitutional Authority
11.14 Privacy, Data Protection and User Sovereignty
11.15 Adversarial Robustness
11.16 Automated Construction of Governed Knowledge Objects
11.17 Conformance Testing
11.18 Cross-Domain Evaluation
11.19 Comparison with Existing Approaches
11.20 Implementation Trade-offs
11.21 Criteria for Revision of the Specification
11.22 Version 0.1 Research Programme
11.23 Closing Statement
Acknowledgements and Development Provenance
Artificial-Intelligence Assistance Statement
Suggested Citation
Canonical Status and Successor Governance
Reading Guide
This document is a constitutional representation specification rather than a conventional research paper. Definitions establish the primitive objects of the specification. Requirements derive from those definitions. Protocol behaviour derives from the requirements. Reference implementations demonstrate one possible application of the specification. Later sections should therefore be interpreted in the context established by earlier sections.
1. Purpose
1.1 Purpose
This specification defines the Dot Protocol: a constitutional representation specification governing the minimum explicit computational state required for independently constructed representations to become computationally interoperable.
The specification addresses a representational problem rather than a reasoning problem.
Contemporary computational systems increasingly demonstrate strong capabilities in retrieval, summarisation, comparison and inference. However, these systems typically operate over representations whose governing context remains largely implicit, requiring frameworks, assumptions, admissibility conditions, provenance and revision history to be reconstructed retrospectively from documents, disciplinary convention or statistical inference.
Dot Protocol proposes that this representational context should instead become explicit computational state.
The protocol therefore specifies a minimal representational governance architecture through which independently constructed representations may remain computationally inspectable, interoperable, recoverable and revisable while preserving the conditions under which they were constructed.
The specification is intentionally independent of scientific discipline, ontology, mathematical formalism, programming language and implementation architecture. It defines constitutional requirements governing representations rather than prescribing how reasoning systems should operate upon them.
Accordingly, the protocol is intended to complement existing computational epistemic workflows—including search systems, language models, evidence synthesis, knowledge graphs and decision-support systems—rather than replace them.
The primary output of Dot Protocol is not a computational conclusion, but a Governed Knowledge Object whose representational context remains explicitly declared throughout its computational lifecycle.
1.2 Scope
This specification defines:
the primitive representational objects required by Dot Protocol;
the constitutional requirements governing those objects;
the minimum explicit computational state required for computational interoperability;
the protocol through which Governed Knowledge Objects are constructed;
the computational operations enabled by governed representations; and
one reference implementation illustrating application of the protocol.
1.3 Non-Goals
This specification does not:
determine the truth or falsity of represented claims;
prescribe scientific methodology, mathematical formalism or ontological commitments;
replace statistical inference, evidence assessment or peer review;
define implementation-specific software architectures or storage mechanisms; or
prescribe governance policies concerning privacy, legal authority or institutional responsibility.
Those matters remain the responsibility of the governing constitutional, scientific, legal or operational frameworks within which the protocol is deployed.
1.4 Relationship to the Dot Theory Constitutional Corpus
Dot Protocol forms part of the broader Dot Theory research programme.
The constitutional corpus—including the Constitutional Onboarding Record (COR), Constitutional Interoperability Review (CIR), Constitutional Provenance Chain (CPC), Operational Admissibility Protocol (OAP), Dependency Declaration Chain (DCC) and the Lexicon—governs the constitutional identity, admissibility, continuity and interoperability of frameworks.
Dot Protocol operates at a different constitutional layer.
Rather than governing frameworks, it governs the representations constructed within those frameworks by specifying the minimum explicit computational state required for those representations to become computationally interoperable.
The constitutional governance layer and the representational governance layer are therefore complementary. Constitutional governance determines the admissibility and continuity of frameworks. Representational governance determines the explicit computational state through which representations produced by those frameworks become inspectable, recoverable, interoperable and computationally reusable.
2. Normative Language
2.1 Normative Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as normative requirements governing conformant implementations of Dot Protocol.
These terms distinguish constitutional requirements from explanatory discussion and illustrative examples.
Unless explicitly stated otherwise, all normative statements apply to the representational objects defined within this specification rather than to any particular software implementation, scientific discipline, computational architecture or organisational workflow.
2.2 Constitutional Interpretation
Within this specification, normative language governs the constitutional properties of representations rather than their empirical correctness or scientific validity.
Accordingly:
Normative statements specify the constitutional conditions under which representations become computationally interoperable.
Normative statements do not prescribe scientific methodology, determine the truth of represented claims or require particular ontological commitments.
Conformance to this specification indicates compliance with the representational governance requirements defined herein. It does not imply correctness of the represented knowledge.
2.3 Conformance
A representation conforms to this specification only if it satisfies all mandatory requirements identified as MUST, MUST NOT, SHALL or SHALL NOT.
Requirements identified as SHOULD, SHOULD NOT, RECOMMENDED, MAY or OPTIONAL describe practices intended to improve interoperability, recoverability or computational utility but are not required for constitutional conformance.
2.4 Informative Material
Examples, explanatory notes, reference implementations, diagrams and discussion included within this specification are informative unless explicitly identified as normative.
Informative material is provided to illustrate possible implementations and should not be interpreted as extending or modifying the normative requirements of the specification.
3. Problem Statement and Research Question
3.1 Problem Statement
Contemporary computational systems increasingly demonstrate sophisticated capabilities in retrieval, summarisation, comparison and inference. Large language models, knowledge graphs, evidence synthesis systems and decision-support platforms routinely operate over representations originating from diverse scientific, technical and social domains.
These systems generally assume that the representations upon which they operate are already sufficiently defined to permit meaningful computational reasoning.
In practice, however, representations rarely exist independently of the conditions under which they were constructed.
Measurements depend upon observational conditions.
Models depend upon simplifying assumptions.
Definitions depend upon disciplinary conventions.
Claims depend upon admissibility conditions.
Interpretations depend upon representational frameworks.
Provenance and revision history frequently determine whether two apparently similar representations should be treated as equivalent, complementary or incompatible.
Much of this representational context remains implicit.
Human investigators often reconstruct it through disciplinary expertise, surrounding documentation and professional judgement. Computational systems must instead infer it retrospectively from available evidence.
This specification proposes that such reconstruction should not be the primary mechanism through which representational interoperability is achieved.
Instead, the representational conditions governing knowledge should themselves become explicit computational state.
3.2 Research Question
This specification addresses the following research question:
What is the minimum explicit computational state required for independently constructed representations to become computationally interoperable while preserving their declared representational meaning?
This question is intentionally representational rather than epistemic.
It does not ask how computational systems should reason.
It asks what explicit representational information must be preserved before computational reasoning can operate over independently constructed knowledge in a transparent, recoverable and interoperable manner.
3.3 Research Hypothesis
This specification proposes the following hypothesis.
Representations become computationally interoperable if and only if the minimum representational context required for their interpretation is preserved as explicit computational state.
Dot Protocol is presented as one candidate constitutional representation specification implementing this hypothesis.
The adequacy of the protocol therefore depends upon whether the computational state defined within this specification proves both constitutionally sufficient and constitutionally minimal for interoperable representation.
3.4 Design Objectives
The protocol defined within this specification is intended to satisfy the following design objectives.
DO-1. Minimality
The protocol SHALL preserve no primitive representational object whose removal does not reduce constitutional integrity or computational interoperability.
DO-2. Explicitness
Representational context SHALL be declared explicitly rather than reconstructed retrospectively wherever practicable.
DO-3. Recoverability
Representational state SHALL remain recoverable throughout successive revisions.
DO-4. Interoperability
Representations originating from independently developed frameworks SHOULD remain computationally comparable without requiring ontological convergence.
DO-5. Framework Independence
The specification SHALL remain independent of particular scientific disciplines, ontologies, mathematical formalisms and implementation architectures.
DO-6. Agency Preservation
The protocol SHALL govern representations rather than decisions.
Computational systems operating over governed knowledge objects MAY generate recommendations, identify inconsistencies and propose revisions, but the constitutional authority responsible for subsequent representational state SHALL remain explicitly identifiable.
The protocol therefore preserves constitutional agency while improving computational support.
3.5 Expected Contribution
If the research hypothesis is correct, computational interoperability need not depend primarily upon increasingly sophisticated reconstruction of implicit representational context.
Instead, interoperability may be achieved by preserving a constitutionally governed minimum computational state through which independently constructed representations remain inspectable, recoverable, interoperable and revisable throughout their computational lifecycle.
The remainder of this specification defines that proposed minimum computational state.
4. Definitions
4.1 Introduction
This section defines the primitive representational objects used throughout this specification.
These definitions are normative.
Later sections SHALL interpret the terms defined herein exactly as specified unless explicitly stated otherwise.
The definitions establish the minimum conceptual vocabulary required to specify Dot Protocol.
No additional primitive representational objects are introduced elsewhere within this specification.
D-1. Representation
A Representation is a constructed description, model, measurement, observation, computation, claim or other informational object intended to refer to some aspect of reality under declared representational conditions.
A representation is not the phenomenon it represents.
Different representations MAY refer to the same phenomenon while differing in framework, observational perspective, admissibility conditions, provenance or intended purpose.
Representations constitute the primitive objects governed by Dot Protocol.
D-2. Representational Context
Representational Context is the complete declared set of conditions under which a representation is constructed, interpreted and considered operationally meaningful.
Representational Context includes, where applicable,
governing framework;
observational operator;
admissibility conditions;
declared residuals;
representational provenance; and
revision history.
Representational Context determines the conditions under which a representation may participate in computational operations.
D-3. Computational State
Computational State is the explicit representational information preserved as part of a governed representation sufficient to permit computational operations without requiring reconstruction of implicit representational assumptions.
Within this specification, Computational State refers exclusively to representational state.
It SHALL NOT be interpreted as processor state, software execution state or computer memory.
D-4. Computational Interoperability
Computational Interoperability is the capacity of independently constructed representations to participate in computational operations while preserving their declared representational meaning.
Computational interoperability concerns representations rather than software systems.
Representations MAY therefore be computationally interoperable despite originating from different disciplines, organisations, ontologies or implementation architectures.
D-5. Representational Governance
Representational Governance is the constitutional discipline through which Representational Context is preserved as explicit Computational State throughout the lifecycle of a Representation.
Representational Governance governs representations prior to computational reasoning.
It neither determines the correctness of represented claims nor prescribes the reasoning procedures subsequently applied to them.
D-6. Governed Knowledge Object (GKO)
A Governed Knowledge Object (GKO) is a Representation whose Representational Context has been preserved as explicit Computational State in accordance with the requirements of this specification.
Governed Knowledge Objects constitute the primary computational artefacts produced by Dot Protocol.
Computational operations defined within this specification operate upon Governed Knowledge Objects rather than upon ungoverned representations.
D-7. Dot Protocol
Dot Protocol is the constitutional representation protocol defined by this specification through which Representations become Governed Knowledge Objects.
The protocol specifies the minimum explicit Computational State required for independently constructed Representations to become computationally interoperable while preserving their declared representational meaning.
Dot Protocol governs representations.
It does not govern scientific reasoning, empirical validation or decision-making.
D-8. Representational Provenance
Representational Provenance records the representational ancestry of a Governed Knowledge Object by identifying the observations, measurements, representations, datasets, computational procedures and prior Governed Knowledge Objects from which the current representation derives.
Representational Provenance differs from Constitutional Provenance.
Constitutional Provenance governs frameworks and constitutional artefacts.
Representational Provenance governs representations.
4.2 Definition Relationships
The primitive objects defined above possess the following dependency structure.
Representation
│
▼
Representational Context
│
▼
Computational State
│
▼
Representational Governance
│
▼
Dot Protocol
│
▼
Governed Knowledge Object
│
▼
Computational Operations
Each subsequent section of this specification derives from these primitive definitions.
No later section SHALL redefine or modify the normative meaning established herein.
5. Requirements
5.1 Introduction
This section specifies the constitutional requirements governing conformant implementations of Dot Protocol.
These requirements define the minimum explicit computational state necessary for independently constructed representations to become computationally interoperable.
Unless otherwise stated, every requirement identified as SHALL, SHALL NOT, MUST or MUST NOT is normative.
5.2 General Requirements
R-1 Representation Requirement
Every Governed Knowledge Object MUST originate from exactly one declared Representation.
Dot Protocol governs representations.
It does not govern phenomena, observations or reality directly.
R-2 Explicit Context Requirement
Every Governed Knowledge Object SHALL preserve its Representational Context as explicit Computational State.
Representational Context MUST NOT rely solely upon reconstruction from surrounding documentation, disciplinary convention or statistical inference.
R-3 Computational State Requirement
All mandatory representational information required by this specification SHALL be preserved as explicit Computational State.
Implicit contextual assumptions SHALL NOT constitute conformant computational state.
5.3 Mandatory Representational Requirements
Every Governed Knowledge Object MUST preserve the following six representational declarations.
R-4 Framework Declaration
A Governing Framework SHALL be declared.
The declared framework identifies the representational system within which the Representation is constructed.
R-5 Operator Declaration
An Observational Operator SHALL be declared.
The operator identifies the observational, interpretative or computational perspective from which the Representation is produced.
R-6 Admissibility Declaration
Admissibility Conditions SHALL be declared.
These conditions specify the representational circumstances under which the Representation is considered valid.
R-7 Residual Declaration
Declared Residuals SHALL be preserved.
Residuals identify known assumptions, omissions, simplifications, unresolved questions or intentionally excluded representational structure.
Residuals SHALL NOT be interpreted as errors.
R-8 Provenance Declaration
Representational Provenance SHALL be preserved.
Provenance records the representational ancestry from which the current Representation derives.
R-9 Revision History Declaration
Revision History SHALL be preserved.
Successive admissible representational states SHALL remain computationally recoverable.
Previous admissible states SHALL NOT be destroyed through revision.
5.4 Constitutional Requirements
R-10 Framework Independence
Conformant implementations SHALL NOT require commitment to any particular scientific discipline, ontology, mathematical formalism or implementation architecture.
R-11 Representation Independence
Dot Protocol SHALL govern representations independently of the computational systems operating upon them.
Search systems, language models, knowledge graphs, databases and reasoning engines MAY implement Dot Protocol without modification to their internal reasoning procedures.
R-12 Agency Preservation
Dot Protocol governs representations rather than decisions.
Computational systems operating over Governed Knowledge Objects MAY generate recommendations, identify inconsistencies and propose revisions.
However, the constitutional authority responsible for subsequent representational state SHALL remain explicitly identifiable.
Conformance to this specification SHALL NOT imply transfer of constitutional agency to computational systems.
5.5 Minimality Requirement
R-13 Minimum Constitutional Description
The primitive representational objects defined by this specification constitute the proposed minimum explicit Computational State required for computational interoperability.
Conformant implementations MAY preserve additional representational information.
Additional information SHALL NOT modify the normative interpretation of the mandatory representational declarations defined by this specification.
5.6 Conformance Criterion
A representation conforms to Dot Protocol if and only if:
it satisfies every mandatory requirement specified within this section;
its Representational Context has been preserved as explicit Computational State; and
it therefore constitutes a Governed Knowledge Object as defined in Section 4.
Representations failing to satisfy one or more mandatory requirements SHALL NOT be considered conformant Governed Knowledge Objects.
Normative Consequence:
A representation that does not preserve explicit Representational Context MAY remain scientifically useful, empirically correct or operationally valuable. It is, however, non-conformant with this specification and therefore SHALL NOT be considered computationally interoperable under Dot Protocol.
6. Object Model
6.1 Introduction
Dot Protocol governs representations by transforming them into Governed Knowledge Objects (GKOs).
A Governed Knowledge Object is not merely a proposition accompanied by supporting evidence. It is a Representation whose Representational Context has been preserved as explicit Computational State in accordance with the requirements specified in Section 5.
The Object Model defined herein specifies the minimum constitutional structure required for conformant Governed Knowledge Objects.
6.2 Object Hierarchy
Dot Protocol defines the following object hierarchy.
Underlying Phenomenon
│
▼
Representation
│
▼
Representational Context
│
▼
Computational State
│
▼
Governed Knowledge Object
│
▼
Computational Operations
This hierarchy is normative.
Computational operations SHALL operate upon Governed Knowledge Objects rather than directly upon ungoverned Representations.
6.3 Governed Knowledge Object Structure
Every conformant Governed Knowledge Object SHALL contain exactly one Representation together with its mandatory Representational Context.
Conceptually, a Governed Knowledge Object consists of:
Governed Knowledge Object
├── Representation
├── Framework
├── Operator
├── Admissibility
├── Residuals
├── Representational Provenance
└── Revision History
The six declared representational objects together constitute the minimum explicit Computational State required by this specification.
6.4 Mandatory Object Relationships
The objects comprising a Governed Knowledge Object SHALL satisfy the following constitutional relationships.
O-1 Representation
Every Governed Knowledge Object SHALL contain exactly one declared Representation.
O-2 Framework
Every Representation SHALL declare one governing Framework.
Multiple Representations MAY declare the same Framework.
O-3 Operator
Every Representation SHALL declare at least one Operator.
Operators identify the representational perspective under which the Representation is constructed.
O-4 Admissibility
Every Representation SHALL declare one or more Admissibility Conditions.
Admissibility Conditions determine when the Representation remains constitutionally valid.
O-5 Residuals
Every Representation SHALL preserve declared Residuals.
Residuals MAY be revised.
Residuals SHALL remain recoverable through Revision History.
O-6 Representational Provenance
Every Representation SHALL preserve Representational Provenance.
Representational Provenance SHALL identify the representational ancestry from which the Representation derives.
O-7 Revision History
Every Governed Knowledge Object SHALL preserve every admissible representational revision.
Successive revisions SHALL constitute successor representational states.
Previous admissible states SHALL remain computationally recoverable.
6.5 Object Independence
The objects defined within this specification are constitutionally independent.
Frameworks SHALL NOT be inferred from Provenance.
Operators SHALL NOT be inferred from Frameworks.
Residuals SHALL NOT be inferred from Admissibility.
Revision History SHALL NOT replace Provenance.
Each mandatory object SHALL therefore be declared explicitly.
6.6 Minimality Claim
Dot Protocol proposes that the six mandatory representational declarations defined in Section 5 constitute the minimum explicit Computational State necessary for computational interoperability.
The specification does not claim that additional representational objects cannot exist.
Rather, it claims that removal of any mandatory object defined herein reduces either:
constitutional integrity;
representational recoverability;
computational interoperability; or
representational transparency.
The burden of proof therefore rests upon either:
demonstrating that one or more mandatory objects may be removed without reducing those properties; or
demonstrating that additional mandatory objects are constitutionally required to preserve them.
Accordingly, the Object Model presented herein is intended to be both minimal and falsifiable.
6.7 Constitutional Relationship
The Object Model specified by Dot Protocol operates within the broader constitutional governance architecture of Dot Theory.
Constitutional Governance determines the admissibility, provenance and continuity of frameworks.
Dot Protocol governs the representations constructed within those frameworks by preserving the minimum explicit Computational State required for computational interoperability.
The two governance layers are therefore complementary.
Constitutional governance governs frameworks.
Representational governance governs representations.
7. Dot Protocol
7.1 Introduction
Dot Protocol specifies the constitutional process through which a Representation becomes a Governed Knowledge Object (GKO).
The protocol governs the construction of representational state prior to computational reasoning. It does not prescribe the reasoning procedures subsequently applied to Governed Knowledge Objects.
Conformant implementations SHALL preserve the protocol operations specified within this section.
7.2 Protocol Overview
The protocol consists of six sequential operations.
Representation
│
▼
Context Declaration
│
▼
Residual Declaration
│
▼
Provenance Registration
│
▼
Governed Knowledge Object
│
▼
Revision
Each operation preserves additional explicit Computational State while maintaining the constitutional integrity of the Representation.
7.3 Protocol Operation P-1: Representation Registration
The protocol SHALL begin with the declaration of a Representation.
The Representation constitutes the primitive object governed by Dot Protocol.
The protocol SHALL NOT operate directly upon physical phenomena, observations or reality independently of Representation.
Output:
Representation.
7.4 Protocol Operation P-2: Context Declaration
The Representational Context SHALL be declared explicitly.
At minimum, Context Declaration SHALL preserve:
Framework;
Operator; and
Admissibility Conditions.
Context Declaration transforms implicit representational assumptions into explicit Computational State.
Context SHALL NOT rely solely upon reconstruction from surrounding documentation or disciplinary convention.
Output:
Representation with declared Context.
7.5 Protocol Operation P-3: Residual Declaration
Declared Residuals SHALL be preserved.
Residuals identify assumptions, simplifications, omissions, unresolved questions or intentionally excluded representational structure.
Residuals SHALL constitute governed representational objects.
Residuals SHALL remain recoverable through subsequent revisions.
Output:
Representation with declared Residuals.
7.6 Protocol Operation P-4: Provenance Registration
Representational Provenance SHALL be recorded.
Provenance SHALL identify the representational ancestry from which the Representation derives.
Where applicable, Provenance MAY reference:
observations;
measurements;
datasets;
publications;
computational procedures;
prior Governed Knowledge Objects.
Output:
Representation with declared Provenance.
7.7 Protocol Operation P-5: Governed Knowledge Object Formation
Following successful completion of the preceding protocol operations, the Representation SHALL become a Governed Knowledge Object.
A Governed Knowledge Object SHALL satisfy every mandatory requirement specified in Section 5.
Computational operations defined by this specification SHALL operate only upon Governed Knowledge Objects.
Output:
Governed Knowledge Object.
7.8 Protocol Operation P-6: Revision
Governed Knowledge Objects SHALL support constitutional revision.
Revision SHALL preserve:
previous admissible representational states;
Revision History;
Representational Provenance.
Revision SHALL produce successor Governed Knowledge Objects.
Previous admissible representational states SHALL remain computationally recoverable.
Output:
Successor Governed Knowledge Object.
7.9 Protocol Invariants
The following invariants SHALL hold throughout every conformant implementation.
I-1 Representation Invariant
Every Governed Knowledge Object SHALL preserve exactly one Representation.
I-2 Context Invariant
Representational Context SHALL remain explicit throughout the computational lifecycle of the Governed Knowledge Object.
I-3 Recoverability Invariant
Every admissible representational state SHALL remain computationally recoverable.
I-4 Provenance Invariant
Representational Provenance SHALL remain continuous across successive revisions.
I-5 Agency Invariant
Dot Protocol governs representations rather than decisions.
Computational systems MAY generate recommendations, comparisons and proposed revisions.
The constitutional authority responsible for determining subsequent representational state SHALL remain explicitly identifiable.
This invariant preserves the Constitutional Invariant of Agency established by the broader Dot Theory constitutional corpus.
7.10 Protocol Completion
A Representation SHALL be considered conformant with Dot Protocol if and only if:
every mandatory requirement defined in Section 5 has been satisfied;
every mandatory protocol operation defined in this section has been completed; and
the resulting Governed Knowledge Object preserves explicit Computational State in accordance with this specification.
Protocol completion does not imply scientific correctness, empirical validity or operational suitability.
Protocol completion indicates only that the Representation conforms to the constitutional representational governance requirements defined herein.
8. Computational Operations
8.1 Introduction
Dot Protocol does not define new reasoning algorithms.
Instead, it specifies the representational conditions under which computational reasoning operates.
Accordingly, the computational operations defined within this section describe operations enabled by Governed Knowledge Objects whose Representational Context has been preserved as explicit Computational State.
These operations are independent of any particular reasoning engine, language model, knowledge graph or computational architecture.
8.2 Operational Principle
Computational operations SHALL operate upon Governed Knowledge Objects rather than directly upon ungoverned Representations.
Because Governed Knowledge Objects preserve explicit Representational Context, computational systems MAY reason over representational structure without reconstructing that structure retrospectively from surrounding documentation.
The protocol therefore shifts computation from inference over implicit context to computation over explicit representational state.
8.3 Supported Computational Operations
A conformant implementation MAY perform one or more of the following computational operations.
CO-1 Representation Comparison
Compare two or more Governed Knowledge Objects while preserving their declared Representational Context.
Comparison SHALL distinguish similarities arising from representational structure from similarities arising solely from linguistic expression.
CO-2 Framework Comparison
Identify whether apparently conflicting Representations arise from different governing Frameworks.
Framework comparison SHALL preserve independent Framework identity.
CO-3 Operator Comparison
Determine whether differing conclusions arise from differing observational or interpretative Operators.
Operator comparison SHALL distinguish observational differences from empirical disagreement.
CO-4 Admissibility Evaluation
Compare declared Admissibility Conditions across multiple Representations.
Admissibility evaluation MAY determine whether apparently conflicting Representations remain simultaneously admissible.
CO-5 Residual Inspection
Inspect declared Residuals associated with one or more Governed Knowledge Objects.
Residual inspection MAY identify omitted assumptions, unresolved questions or representational limitations without requiring reconstruction from surrounding documentation.
CO-6 Provenance Tracing
Traverse Representational Provenance across successive Governed Knowledge Objects.
Provenance tracing SHALL preserve complete representational ancestry throughout computational revision.
CO-7 Revision Recovery
Recover previous admissible representational states preserved through Revision History.
Revision recovery SHALL preserve Constitutional Continuity while permitting computational inspection of historical Representations.
CO-8 Interoperability Assessment
Determine whether independently constructed Representations satisfy the representational conditions necessary for computational interoperability.
Interoperability assessment concerns representational compatibility rather than empirical correctness.
8.4 Computational Independence
The computational operations defined by this specification SHALL remain independent of:
implementation language;
database architecture;
storage mechanism;
reasoning algorithm;
machine learning model;
scientific discipline;
ontological commitment.
Conformant implementations MAY employ symbolic, statistical, neural, hybrid or future computational approaches without modification to the constitutional requirements defined by Dot Protocol.
8.5 Constitutional Consequences
By preserving explicit Representational Context as Computational State, Dot Protocol enables computational systems to distinguish:
empirical disagreement from representational disagreement;
differing Frameworks from differing evidence;
differing Operators from differing observations;
unresolved Residuals from contradictory claims;
successive revisions from independent Representations.
These distinctions are computational consequences of explicit representational governance rather than properties of any particular reasoning algorithm.
8.6 Relationship to Artificial Intelligence
Dot Protocol complements rather than replaces contemporary artificial intelligence systems.
Language models, knowledge graphs, search systems and decision-support platforms MAY continue to perform retrieval, summarisation, comparison and inference.
Dot Protocol instead governs the Representations upon which those systems operate.
Accordingly, improvements in computational capability increase the effectiveness of reasoning performed over Governed Knowledge Objects without requiring modification to the protocol itself.
The protocol therefore scales naturally with advances in computational reasoning.
8.7 Computational Consequence
The primary computational consequence of Dot Protocol is that Representational Context becomes explicit Computational State.
As a result, computational systems operate over governed Representations rather than inferred contextual assumptions.
The protocol therefore improves computational transparency, recoverability, interoperability and revisability without prescribing how reasoning itself should be performed.
9. Reference Implementation
9.1 Introduction
This section provides one illustrative implementation of Dot Protocol.
The purpose of the reference implementation is not to validate any particular scientific, clinical or computational methodology.
Rather, it demonstrates how independently constructed Representations become computationally interoperable through explicit preservation of Representational Context as Computational State.
The reference implementation is informative.
It illustrates one conformant application of the specification defined in the preceding sections.
9.2 Reference Domain
This reference implementation considers the digitally mediated human.
Modern healthcare increasingly depends upon independently constructed Representations originating from multiple computational systems.
Examples include:
electronic health records;
laboratory measurements;
medical imaging;
wearable devices;
home monitoring systems;
patient-reported outcome measures;
environmental observations;
clinical decision-support systems.
Each system constructs Representations under different Frameworks, Operators, Admissibility Conditions and Provenance.
Although these Representations frequently concern the same individual, they are generally constructed independently and therefore possess distinct Representational Context.
Dot Protocol governs the interoperability of these Representations without requiring their underlying computational systems to adopt common ontologies, reasoning algorithms or implementation architectures.
Figure 9.1. Representational Governance of the Digitally Mediated Human
Digitally Mediated Human
│
┌─────────────┬─────────────┬─────────────┐
▼ ▼ ▼ ▼
Clinical Wearables Environment Self Report
▼ ▼ ▼ ▼
[───── Independent Representations (Framework-specific) ─────]
│
▼
Dot Protocol v0.1
│
▼
Governed Knowledge Objects
│
▼
Computational Operations
│
▼
Computational Recommendations
│
▼
Constitutional Actor (Agency Preserved)
Figure 9.1. Modern digitally mediated individuals are represented simultaneously through multiple independently constructed representational systems. Dot Protocol does not merge these representations. Instead, it governs their explicit representational context, allowing them to become computationally interoperable while preserving constitutional agency.
9.3 Example Representations
Consider the following independently constructed Representations.
Representation
Framework
Operator
Electronic Health Record
Clinical Medicine
Physician
Continuous Glucose Monitor
Biomedical Sensor
Device Measurement
Smart Watch Activity
Consumer Wearable
Activity Monitoring
Home Environmental Sensor
Environmental Monitoring
Automated Observation
Patient Questionnaire
Self-Reported Health
Patient
Each Representation remains constitutionally independent.
Dot Protocol does not merge these Representations.
Instead, it governs their explicit Representational Context.
9.4 Governed Knowledge Objects
Each Representation becomes a Governed Knowledge Object by preserving the mandatory Computational State defined by this specification.
Conceptually:
Electronic Health Record
Framework
Operator
Admissibility
Residuals
Representational Provenance
Revision History
↓
Governed Knowledge Object
The same transformation occurs independently for every Representation participating within the computational ecosystem.
9.5 Computational Interoperability
Once governed, the Representations become computationally interoperable.
Computational systems MAY now perform operations such as:
comparing admissible Representations originating from different healthcare providers;
identifying differences arising from observational Operators rather than clinical disagreement;
preserving multiple simultaneously admissible Representations;
tracing Representational Provenance across successive clinical revisions;
recovering previous representational states during longitudinal analysis;
integrating independently constructed Representations without loss of declared context.
These operations derive from explicit Representational Governance rather than from retrospective inference.
9.6 Constitutional Agency
Dot Protocol governs Representations rather than clinical decisions.
Computational systems operating over Governed Knowledge Objects MAY generate recommendations, identify inconsistencies or propose revised Representations.
The constitutional authority responsible for subsequent representational state SHALL remain explicitly identifiable.
Accordingly:
clinicians retain clinical responsibility;
patients retain personal agency;
institutions retain organisational responsibility;
computational systems provide governed computational support.
The protocol therefore preserves constitutional agency while improving computational interoperability.
9.7 Generalisation
Although healthcare provides a convenient reference implementation, the protocol is not healthcare-specific.
The same constitutional architecture applies wherever independently constructed Representations require computational interoperability.
Examples include:
scientific research;
engineering;
environmental monitoring;
legal reasoning;
education;
financial systems;
digital identity;
autonomous systems.
Healthcare therefore functions as an illustrative implementation rather than a privileged application domain.
9.8 Reference Implementation Summary
This implementation demonstrates that Dot Protocol governs the Representations associated with a digitally mediated individual rather than the computational systems producing those Representations.
The protocol enables independently constructed Representations to become Governed Knowledge Objects while preserving their declared Representational Context as explicit Computational State.
Consequently, computational interoperability arises through governed Representations rather than through reconstruction of implicit contextual assumptions.
10. Formal Schemas
10.1 Purpose
This section provides formal machine-readable schemas for representing Governed Knowledge Objects in accordance with Dot Protocol.
The schemas are implementation-neutral serialisations of the normative Object Model and Requirements defined in Sections 5 and 6.
The schemas do not replace those normative sections.
Where a schema and the normative text appear to conflict, the normative requirements of this specification SHALL take precedence.
A conformant implementation MAY use YAML, JSON, RDF, a graph database, a relational database or another suitable technical architecture, provided that the mandatory representational state remains explicit, recoverable and semantically equivalent to the structure defined herein.
10.2 Canonical Governed Knowledge Object Structure
A Governed Knowledge Object SHALL contain:
a persistent identifier;
one declared Representation;
one declared Framework;
at least one declared Operator;
one or more Admissibility Conditions;
a Residual declaration;
Representational Provenance; and
Revision History.
The following abstract structure is normative:
GovernedKnowledgeObject
├── identifier
├── specification
├── representation
│ ├── identifier
│ ├── content
│ ├── type
│ └── status
├── representationalContext
│ ├── framework
│ ├── operators[]
│ ├── admissibilityConditions[]
│ ├── residuals[]
│ ├── provenance
│ └── revisionHistory[]
└── optionalMetadata
The representation property contains the informational object governed by the protocol.
The representationalContext property contains the explicit Computational State required for constitutional conformance.
10.3 Identifier Requirements
FS-1 Governed Knowledge Object Identifier
Every Governed Knowledge Object SHALL possess a persistent identifier.
The identifier SHALL distinguish the Governed Knowledge Object from all other Governed Knowledge Objects within the implementing system.
FS-2 Representation Identifier
The Representation contained within a Governed Knowledge Object SHALL possess its own identifier.
The Governed Knowledge Object identifier and Representation identifier SHOULD remain distinct because the same Representation MAY participate in more than one governed context or successor state.
FS-3 Revision Identifiers
Every representational revision SHALL possess a persistent revision identifier.
Revision identifiers SHALL NOT be reused for different representational states.
10.4 YAML Reference Schema
The following YAML structure illustrates a minimal conformant Governed Knowledge Object.
governedKnowledgeObject:
identifier: "gko-example-0001"
specification:
name: "Dot Protocol Specification"
version: "0.1"
identifier: "DPS-0.1"
representation:
identifier: "rep-example-0001"
type: "claim"
content: "Example represented content."
status: "active"
representationalContext:
framework:
identifier: "framework-example-0001"
name: "Example Framework"
version: "1.0"
operators:
- identifier: "operator-example-0001"
type: "human-observer"
description: "Declared observational or interpretative operator."
admissibilityConditions:
- identifier: "admissibility-example-0001"
description: "Conditions under which the representation remains admissible."
status: "satisfied"
residuals:
- identifier: "residual-example-0001"
description: "Known unresolved or intentionally excluded structure."
status: "open"
provenance:
sources:
- identifier: "source-example-0001"
type: "publication"
reference: "Example source reference"
derivationDescription: "Description of how the representation was constructed."
revisionHistory:
- revisionIdentifier: "revision-example-0001"
version: "1.0"
status: "current"
timestamp: "2026-07-01T00:00:00Z"
responsibleAuthority: "Example constitutional actor"
predecessor: null
changeDescription: "Initial governed representation."
optionalMetadata:
title: "Example Governed Knowledge Object"
language: "en"
confidence:
value: null
method: null
links: []
notes: []
The example values are informative.
The presence and constitutional functions of the mandatory properties are normative.
10.5 Minimal YAML Instance
A technically minimal instance MAY use a more compact structure, provided that no mandatory declaration is omitted.
identifier: "gko-0001"
representation:
identifier: "rep-0001"
content: "Example represented content."
framework:
identifier: "framework-0001"
operators:
- identifier: "operator-0001"
admissibilityConditions:
- description: "Declared condition of admissibility."
residuals:
- description: "No known residuals declared."
status: "none-declared"
provenance:
sources:
- identifier: "source-0001"
revisionHistory:
- revisionIdentifier: "rev-0001"
version: "1.0"
status: "current"
A declaration that no residuals are presently known is not equivalent to omitting the Residual field.
Similarly, a declaration that provenance is unavailable is not equivalent to omitting Provenance.
The protocol requires explicit state, including explicit declarations of absence, uncertainty or unavailability.
10.6 Explicit Null and Unknown States
Conformant implementations SHALL distinguish between:
a value that is known and declared;
a value that is explicitly unknown;
a value that is unavailable;
a value that is not applicable;
a value that has not yet been reviewed; and
a mandatory field that is absent.
These states SHALL NOT be collapsed into an undifferentiated null value where doing so would reduce recoverability or interoperability.
Recommended controlled status values include:
declared
unknown
unavailable
not-applicable
pending-review
none-declared
withdrawn
superseded
An absent mandatory field constitutes non-conformance.
An explicitly declared unknown or unavailable value MAY remain conformant where the absence of knowledge is itself preserved as explicit Computational State.
10.7 JSON Reference Instance
The following JSON instance is semantically equivalent to the YAML reference structure.
{
"governedKnowledgeObject": {
"identifier": "gko-example-0001",
"specification": {
"name": "Dot Protocol Specification",
"version": "0.1",
"identifier": "DPS-0.1"
},
"representation": {
"identifier": "rep-example-0001",
"type": "claim",
"content": "Example represented content.",
"status": "active"
},
"representationalContext": {
"framework": {
"identifier": "framework-example-0001",
"name": "Example Framework",
"version": "1.0"
},
"operators": [
{
"identifier": "operator-example-0001",
"type": "human-observer",
"description": "Declared observational or interpretative operator."
}
],
"admissibilityConditions": [
{
"identifier": "admissibility-example-0001",
"description": "Conditions under which the representation remains admissible.",
"status": "satisfied"
}
],
"residuals": [
{
"identifier": "residual-example-0001",
"description": "Known unresolved or intentionally excluded structure.",
"status": "open"
}
],
"provenance": {
"sources": [
{
"identifier": "source-example-0001",
"type": "publication",
"reference": "Example source reference"
}
],
"derivationDescription": "Description of how the representation was constructed."
},
"revisionHistory": [
{
"revisionIdentifier": "revision-example-0001",
"version": "1.0",
"status": "current",
"timestamp": "2026-07-01T00:00:00Z",
"responsibleAuthority": "Example constitutional actor",
"predecessor": null,
"changeDescription": "Initial governed representation."
}
]
},
"optionalMetadata": {
"title": "Example Governed Knowledge Object",
"language": "en",
"confidence": {
"value": null,
"method": null
},
"links": [],
"notes": []
}
}
}
10.8 JSON Schema
The following JSON Schema provides a reference validation model for the canonical Governed Knowledge Object structure.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://www.dottheory.co.uk/schemas/dot-protocol-v0.1.schema.json",
"title": "Dot Protocol Governed Knowledge Object",
"description": "Reference schema for a Governed Knowledge Object conforming to Dot Protocol Specification v0.1.",
"type": "object",
"required": [
"governedKnowledgeObject"
],
"properties": {
"governedKnowledgeObject": {
"type": "object",
"additionalProperties": false,
"required": [
"identifier",
"specification",
"representation",
"representationalContext"
],
"properties": {
"identifier": {
"$ref": "#/$defs/nonEmptyString"
},
"specification": {
"$ref": "#/$defs/specificationReference"
},
"representation": {
"$ref": "#/$defs/representation"
},
"representationalContext": {
"$ref": "#/$defs/representationalContext"
},
"optionalMetadata": {
"$ref": "#/$defs/optionalMetadata"
}
}
}
},
"$defs": {
"nonEmptyString": {
"type": "string",
"minLength": 1
},
"statusValue": {
"type": "string",
"enum": [
"declared",
"active",
"satisfied",
"open",
"unknown",
"unavailable",
"not-applicable",
"pending-review",
"none-declared",
"withdrawn",
"superseded",
"current",
"historical"
]
},
"specificationReference": {
"type": "object",
"additionalProperties": false,
"required": [
"name",
"version",
"identifier"
],
"properties": {
"name": {
"$ref": "#/$defs/nonEmptyString"
},
"version": {
"$ref": "#/$defs/nonEmptyString"
},
"identifier": {
"$ref": "#/$defs/nonEmptyString"
}
}
},
"representation": {
"type": "object",
"additionalProperties": true,
"required": [
"identifier",
"content"
],
"properties": {
"identifier": {
"$ref": "#/$defs/nonEmptyString"
},
"type": {
"type": "string"
},
"content": {},
"status": {
"type": "string"
}
}
},
"framework": {
"type": "object",
"additionalProperties": true,
"required": [
"identifier"
],
"properties": {
"identifier": {
"$ref": "#/$defs/nonEmptyString"
},
"name": {
"type": "string"
},
"version": {
"type": "string"
},
"reference": {
"type": "string"
}
}
},
"operator": {
"type": "object",
"additionalProperties": true,
"required": [
"identifier"
],
"properties": {
"identifier": {
"$ref": "#/$defs/nonEmptyString"
},
"type": {
"type": "string"
},
"description": {
"type": "string"
}
}
},
"admissibilityCondition": {
"type": "object",
"additionalProperties": true,
"required": [
"description"
],
"properties": {
"identifier": {
"type": "string"
},
"description": {
"$ref": "#/$defs/nonEmptyString"
},
"status": {
"type": "string"
},
"failureCondition": {
"type": "string"
}
}
},
"residual": {
"type": "object",
"additionalProperties": true,
"required": [
"description",
"status"
],
"properties": {
"identifier": {
"type": "string"
},
"description": {
"$ref": "#/$defs/nonEmptyString"
},
"status": {
"type": "string"
}
}
},
"source": {
"type": "object",
"additionalProperties": true,
"required": [
"identifier"
],
"properties": {
"identifier": {
"$ref": "#/$defs/nonEmptyString"
},
"type": {
"type": "string"
},
"reference": {
"type": "string"
},
"timestamp": {
"type": "string",
"format": "date-time"
}
}
},
"provenance": {
"type": "object",
"additionalProperties": true,
"required": [
"sources"
],
"properties": {
"sources": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/source"
}
},
"derivationDescription": {
"type": "string"
}
}
},
"revision": {
"type": "object",
"additionalProperties": true,
"required": [
"revisionIdentifier",
"version",
"status"
],
"properties": {
"revisionIdentifier": {
"$ref": "#/$defs/nonEmptyString"
},
"version": {
"$ref": "#/$defs/nonEmptyString"
},
"status": {
"type": "string"
},
"timestamp": {
"type": "string",
"format": "date-time"
},
"responsibleAuthority": {
"type": "string"
},
"predecessor": {
"type": [
"string",
"null"
]
},
"changeDescription": {
"type": "string"
}
}
},
"representationalContext": {
"type": "object",
"additionalProperties": false,
"required": [
"framework",
"operators",
"admissibilityConditions",
"residuals",
"provenance",
"revisionHistory"
],
"properties": {
"framework": {
"$ref": "#/$defs/framework"
},
"operators": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/operator"
}
},
"admissibilityConditions": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/admissibilityCondition"
}
},
"residuals": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/residual"
}
},
"provenance": {
"$ref": "#/$defs/provenance"
},
"revisionHistory": {
"type": "array",
"minItems": 1,
"items": {
"$ref": "#/$defs/revision"
}
}
}
},
"optionalMetadata": {
"type": "object",
"additionalProperties": true,
"properties": {
"title": {
"type": "string"
},
"language": {
"type": "string"
},
"confidence": {
"type": [
"object",
"null"
],
"properties": {
"value": {
"type": [
"number",
"string",
"null"
]
},
"method": {
"type": [
"string",
"null"
]
}
}
},
"links": {
"type": "array",
"items": {
"type": "string"
}
},
"notes": {
"type": "array",
"items": {
"type": "string"
}
}
}
}
}
}
10.9 Schema Conformance
An implementation conforms to the reference schema where:
every mandatory property is present;
every mandatory property contains an explicit declaration;
the object validates against the reference JSON Schema or an implementation-specific schema preserving equivalent normative structure;
previous revisions remain recoverable; and
schema translation does not collapse distinctions established by this specification.
Syntactic validation alone does not establish constitutional conformance.
A technically valid object MAY remain constitutionally non-conformant where its fields are populated with undeclared, misleading or non-recoverable content.
Conformance therefore requires both:
structural validity; and
substantive preservation of the declared representational state.
10.10 Schema Extensibility
Implementations MAY extend the canonical schema.
Extensions SHOULD:
use namespaced properties;
preserve all mandatory Dot Protocol properties;
declare their originating framework;
preserve extension provenance;
avoid redefining normative properties;
declare any additional admissibility conditions; and
remain recoverable through Revision History.
An extension MUST NOT alter the normative meaning of Framework, Operator, Admissibility, Residuals, Representational Provenance or Revision History while claiming conformance with Dot Protocol v0.1.
10.11 Schema Translation
Governed Knowledge Objects MAY be translated between serialisation formats.
A schema translation is conformant only where it preserves:
Representation identity;
every mandatory state declaration;
Representational Provenance;
Revision History;
explicit unknown and unavailable states; and
the distinction between absent information and explicitly declared absence.
Translation between YAML, JSON, RDF, relational structures or graph representations SHALL NOT be treated as constitutionally lossless unless these invariants have been demonstrated to remain recoverable.
10.12 Formal Schema Status
The schemas defined in this section are reference schemas for Dot Protocol Specification v0.1.
They are intended to support implementation, comparison and testing.
They do not establish that the proposed object model is uniquely minimal.
Future successor specifications MAY revise the schema where implementation, falsification or interoperability testing demonstrates that:
a mandatory property is redundant;
an additional mandatory property is required;
a property requires decomposition;
controlled vocabularies require formalisation; or
the present serialisation model fails to preserve declared representational meaning.
Any such change SHALL be issued through a successor specification rather than retrospective modification of Dot Protocol Specification v0.1.
11. Open Problems
11.1 Status of This Section
This section identifies unresolved questions concerning the conceptual adequacy, minimality, implementation and evaluation of Dot Protocol Specification v0.1.
Unless explicitly stated otherwise, this section is informative.
The existence of an open problem does not by itself render the specification non-conformant or inadmissible. Open problems identify areas in which the present candidate specification remains subject to implementation, comparison, critique and attempted falsification.
Dot Protocol v0.1 should therefore be understood as a testable candidate state model rather than a completed or uniquely established standard.
11.2 Central Conjecture
This specification is organised around the following conjecture:
Conjecture C-1
Independently constructed representations become computationally interoperable if and only if the minimum Representational Context required for their interpretation is preserved as explicit Computational State.
This conjecture contains two distinct claims.
C-1A: Sufficiency
If the minimum required Representational Context is preserved as explicit Computational State, independently constructed Representations can participate in common computational operations without loss of their declared representational meaning.
C-1B: Necessity
If independently constructed Representations participate in common computational operations without loss of declared representational meaning, the context required to preserve that meaning must be computationally available in an explicit or functionally equivalent form.
The sufficiency claim may be evaluated through conformant implementations and cross-domain reference cases.
The necessity claim is stronger and remains open to counterexample.
A successful counterexample would demonstrate computational interoperability without explicit or functionally equivalent preservation of the context required to interpret the participating Representations.
11.3 Minimality of the State Model
Dot Protocol v0.1 proposes six mandatory representational declarations:
Framework;
Operator;
Admissibility Conditions;
Residuals;
Representational Provenance;
Revision History.
The specification claims minimal sufficiency rather than unique minimality.
The following questions remain open:
Can one mandatory declaration be derived reliably from the others?
Can two declarations be combined without reducing recoverability or interoperability?
Does a conformant Representation require more than one Framework in some cases?
Can the Operator always be represented as part of the Framework?
Is Revision History required for immediate interoperability, or only for persistent interoperability through time?
Is Representational Provenance logically necessary for interoperability, or constitutionally necessary for trustworthy interoperability?
Does the state model omit a mandatory distinction required in adversarial or high-risk environments?
Are the six declarations minimal across all domains, or only across the present reference cases?
The proposed state model should be revised if implementation or analysis establishes that:
a mandatory declaration can be removed without material loss;
a mandatory declaration cannot be represented independently;
two declarations are constitutionally indistinguishable;
an omitted declaration is necessary across materially different domains; or
the current decomposition produces systematic ambiguity.
11.4 Definition of Representation
The definition of Representation remains load-bearing.
This specification defines a Representation broadly enough to include descriptions, measurements, models, claims, computations and other informational objects intended to refer under declared conditions.
Further work is required to determine:
whether Observation should remain a type of Representation or become a separate primitive object;
whether Claim should be defined as a derived object;
whether a Representation may contain multiple independently governable claims;
whether the same informational content may instantiate multiple Representations under different contexts;
how compound, nested and distributed Representations should be governed;
when a transformed Representation becomes a successor state and when it becomes a new Representation; and
whether representations generated dynamically by computational systems require additional state declarations.
The protocol should avoid treating textual, computational or observational similarity as sufficient evidence of representational identity.
11.5 Framework Granularity
A Framework identifies the representational system within which a Representation is constructed.
However, frameworks may be nested, overlapping or only partially declared.
Open questions include:
What is the minimum declaration sufficient to identify a Framework?
Can a Representation participate simultaneously in several Frameworks?
Should Framework relationships be hierarchical, graph-based or purpose-relative?
When does a methodological variation constitute a new Framework?
How should undeclared or partially recoverable Frameworks be represented?
Can a locally constructed analytical procedure count as a Framework?
How should framework versions be related to Representation revisions?
Future implementations may require explicit Framework identifiers, version references and constitutional links to relevant Declared Constitutional Corpora.
11.6 Operator Granularity
The Operator identifies the observational, interpretative or computational perspective from which a Representation is produced.
The Operator may be human, institutional, instrumental, computational or composite.
Open questions include:
Can an Operator be reduced to a Framework-relative role?
Must human, sensor and algorithmic Operators be represented differently?
How should composite Operators be decomposed?
How should a model-generated Representation declare the model, prompt, tools and human steering involved?
Can an Operator change without producing a new Representation?
What state is required to distinguish observer position from measurement procedure?
How should institutional or collective Operators be attributed?
How should an unknown Operator be represented without implying neutrality?
The specification may require a more formal Operator model in successor versions if implementations show that a single undecomposed declaration is insufficient.
11.7 Admissibility and Failure Conditions
Admissibility identifies the conditions under which a Representation remains operationally legitimate.
Further work is required to distinguish consistently between:
admissibility conditions;
applicability conditions;
inclusion criteria;
boundary conditions;
confidence thresholds;
validation conditions;
failure conditions; and
conditions imposed by external legal or institutional authority.
A Representation may remain constitutionally well formed while its declared Admissibility Conditions are unsatisfied.
Successor versions should clarify whether such an object remains a Governed Knowledge Object with an inadmissible status or becomes a distinct class of governed but non-admissible representation.
11.8 Residual Structure
Residuals preserve known assumptions, omissions, simplifications and unresolved structure.
Residual declaration is inherently incomplete because an author or system cannot declare what it has not detected.
Open questions include:
How should known unknowns be distinguished from suspected omissions?
Can computational systems generate candidate Residuals without treating them as author declarations?
Should Residuals be classified by source, severity, recoverability or expected effect?
When does an unresolved Residual become a Failure Condition?
How should adversarially concealed assumptions be represented once discovered?
How should disagreement over the existence or significance of a Residual be governed?
Can the absence of detected Residuals ever justify a none-declared status?
Should Residual discovery create a successor Governed Knowledge Object automatically?
Dot Protocol requires explicit Residual state but does not claim that such state can ever be exhaustive.
11.9 Provenance Sufficiency
Representational Provenance records the ancestry from which a Representation derives.
Open questions include:
What level of provenance granularity is minimally sufficient?
Must every inferential step be preserved?
How should unverifiable sources be declared?
How should derived data preserve relationships to raw data?
How should model-generated transformations record prompts, parameters, model versions and tool use?
How should confidential or legally restricted provenance be represented?
Can cryptographic commitments preserve provenance without disclosing protected content?
How should conflicting provenance claims be handled?
When does provenance loss render a Representation non-conformant rather than merely limited?
Provenance completeness is domain-dependent. The protocol therefore requires explicit declaration but does not yet establish a universal completeness threshold.
11.10 Revision and Representational Identity
The protocol requires previous admissible states to remain recoverable.
The boundary between revision and replacement remains partly unresolved.
Further work should determine:
when modification produces a successor state of the same Representation;
when modification produces a new Representation;
how forks and merges should be represented;
whether revision histories should be linear or graph-based;
how withdrawn or corrected Representations should remain discoverable;
how conflicting successor states should coexist;
whether a merge can preserve the independent identity of all predecessor Representations; and
how revision authority should be declared.
The Constitutional Provenance Chain provides a governance model for successor constitutional states. Further analysis is required to determine the precise relationship between constitutional succession and representation-level revision.
11.11 Measurement of Interoperability
This specification defines Computational Interoperability conceptually but does not provide a quantitative metric.
Potential evaluation dimensions include:
proportion of mandatory state recovered;
degree of semantic preservation under translation;
success of cross-framework comparison;
reduction in contextual reconstruction;
provenance recoverability;
revision recoverability;
residual preservation;
consistency across independent implementations;
resistance to adversarial reinterpretation; and
capacity for downstream extension without destructive reformatting.
A useful interoperability measure should distinguish:
syntactic interoperability;
structural interoperability;
semantic interoperability;
constitutional interoperability; and
operational interoperability.
No single scalar score should be assumed sufficient without validation.
11.12 Relationship to Ingestion, Structure and Assessment
Dot Protocol is intended to provide a common representational substrate for AI-assisted epistemic workflows.
Further implementation is required to determine how the protocol interacts with:
source ingestion;
claim extraction;
argument mapping;
evidence assessment;
confidence calibration;
crux identification;
detection of correlated evidence;
rhetorical analysis;
missing-perspective discovery; and
continuous knowledge-base maintenance.
Dot Protocol does not itself perform these functions.
The open question is whether preserving explicit Representational Context materially improves their reliability, transferability and capacity to compound across investigators.
This should be tested against strong contemporary baselines rather than assumed.
11.13 Agency and Constitutional Authority
Invariant I-5 requires the constitutional authority responsible for subsequent representational state to remain identifiable.
Open questions include:
Who constitutes the responsible constitutional actor in collective or institutional settings?
How should delegated authority be represented?
How should guardianship, clinical responsibility and institutional stewardship be distinguished?
Can several actors possess different kinds of authority over the same Governed Knowledge Object?
How should disagreement between constitutional actors be preserved?
What constitutes meaningful non-engagement?
How should refusal, postponement, override and request for clarification be represented?
When may automated action remain constitutionally admissible?
How should emergency or legally mandated interventions be distinguished from voluntary optimisation?
The Constitutional Invariant of Agency does not require that every computational action receive contemporaneous human approval.
It requires that authority, delegation and override conditions remain explicit rather than silently transferred to a computational system.
11.14 Privacy, Data Protection and User Sovereignty
The reference implementation concerns digitally mediated human experience and therefore raises legal and ethical questions beyond the present protocol.
Dot Protocol does not itself determine:
ownership of personal data;
lawful grounds for processing;
consent requirements;
access rights;
portability rights;
data-retention periods;
clinical confidentiality;
surveillance law;
medical-device regulation; or
institutional liability.
These matters remain governed by applicable legal and constitutional frameworks, including relevant data-protection and healthcare legislation.
Future implementations should investigate whether Governed Knowledge Objects can support user-controlled or delegated interoperability without requiring centralised possession of all underlying data.
Potential mechanisms include:
local processing;
selective disclosure;
cryptographic commitments;
federated computation;
permissioned access;
revocable delegation; and
representation-level rather than dataset-level exchange.
No privacy or sovereignty benefit should be inferred solely from conformance with Dot Protocol.
11.15 Adversarial Robustness
Explicit state may improve inspectability but does not prevent deceptive declaration.
A malicious or motivated actor may:
declare a misleading Framework;
omit a relevant Operator;
define permissive Admissibility Conditions;
conceal Residuals;
fabricate Provenance;
manipulate Revision History; or
overwhelm users with formally complete but practically unusable declarations.
Future work should therefore distinguish structural conformance from trustworthy conformance.
Potential safeguards include:
independent review;
cryptographic verification;
provenance authentication;
competing Governed Knowledge Objects;
anomaly detection;
declaration-quality scoring;
explicit contestation records;
Constitutional Interoperability Review; and
successor-state correction rather than retrospective alteration.
Dot Protocol makes representational declarations inspectable.
It does not guarantee that declarations are honest.
11.16 Automated Construction of Governed Knowledge Objects
Governed Knowledge Objects may be constructed manually, automatically or through human–AI collaboration.
Open implementation questions include:
which declarations may be extracted reliably from existing documents;
which declarations require author confirmation;
how uncertainty in extracted context should be represented;
how computationally proposed Residuals should be distinguished from accepted Residuals;
how conflicting extractions should be adjudicated;
how automation quality should be measured;
whether automated generation should produce provisional rather than conformant objects; and
how model and prompt provenance should be preserved.
A future implementation may distinguish:
author-declared state;
machine-extracted state;
reviewer-confirmed state;
contested state; and
computationally inferred candidate state.
These distinctions should remain explicit.
11.17 Conformance Testing
The present specification defines structural and constitutional requirements but does not provide an executable conformance suite.
A future conformance suite should test at least:
presence of mandatory declarations;
distinction between absence and explicitly declared unknown state;
preservation of Representation identity;
recovery of predecessor states;
preservation of Provenance under revision;
schema translation without declared state loss;
independence of mandatory state variables;
explicit identification of constitutional authority; and
support for the Computational Operations defined in Section 8.
Conformance testing should include adversarial and malformed examples rather than only successful reference cases.
11.18 Cross-Domain Evaluation
The healthcare reference implementation is insufficient to establish generality.
Dot Protocol should be evaluated across cases with materially different representational structures, including:
contested scientific disputes;
mature scientific safety arguments;
nutrition and public-health evidence;
legal interpretation;
engineering specifications;
historical analysis;
environmental monitoring;
computational model comparison; and
multi-framework scientific collaboration.
A candidate state model should not be considered general merely because its vocabulary can be applied nominally across domains.
It should demonstrate operational advantage across cases with different evidential, temporal, adversarial and institutional structures.
11.19 Comparison with Existing Approaches
Further work should compare Dot Protocol with existing representational and epistemic infrastructure, including:
knowledge graphs;
provenance standards;
argument-mapping systems;
scientific workflow languages;
ontology-alignment methods;
semantic-web standards;
evidence-grading frameworks;
model cards and data sheets;
audit trails;
version-control systems; and
AI-assisted research environments.
The relevant question is not whether these systems already preserve some Dot Protocol fields.
The relevant questions are:
whether the complete proposed state model already exists elsewhere;
whether existing approaches preserve equivalent constitutional distinctions;
whether Dot Protocol improves interoperability without unnecessary duplication; and
whether the proposed abstraction provides operational value beyond combining established metadata practices.
A finding that an existing standard already provides equivalent functionality would reduce the novelty claim and should inform successor specifications.
11.20 Implementation Trade-offs
Explicit representational state introduces costs.
These may include:
increased authoring burden;
schema complexity;
incomplete or inconsistent declarations;
higher storage requirements;
version-management overhead;
user-interface complexity;
governance delays; and
incentives to satisfy fields formally rather than substantively.
The protocol should be evaluated not only by the capabilities it enables but by whether those capabilities justify the cost of declaration and maintenance.
Minimum Constitutional Description remains the governing design principle.
Successor versions SHOULD remove any requirement whose practical burden consistently exceeds its interoperability contribution.
11.21 Criteria for Revision of the Specification
Dot Protocol Specification v0.1 should be revised where implementation, analysis or attempted falsification demonstrates one or more of the following:
a mandatory object is redundant;
an additional mandatory object is necessary;
a normative definition produces systematic ambiguity;
an invariant cannot be maintained;
a protocol operation cannot be implemented independently of a specific architecture;
schema translation causes unavoidable loss of declared representational meaning;
the protocol fails to improve meaningful interoperability over strong baselines;
the protocol permits systematic representational collapse or misleading equivalence;
constitutional agency cannot be preserved under plausible implementations; or
a simpler candidate specification achieves equal or greater interoperability.
Changes SHALL be issued through an explicitly identified successor specification.
Dot Protocol Specification v0.1 SHALL remain independently recoverable and SHALL NOT be retrospectively modified after canonical publication.
11.22 Version 0.1 Research Programme
The immediate research programme following publication of this specification should include:
independent review of the primitive definitions;
field-by-field minimality analysis;
attempted falsification of Conjecture C-1;
implementations in at least two serialisation architectures;
cross-domain worked examples;
comparison against strong AI-assisted research baselines;
adversarial testing;
conformance-test development;
usability evaluation;
refinement of the healthcare reference implementation; and
constitutional review of proposed successor states.
The principal objective is not to defend Version 0.1.
It is to determine what survives disciplined implementation and critique.
11.23 Closing Statement
Dot Protocol Specification v0.1 proposes that scientific and computational representations require explicit constitutional state before they can become reliably interoperable.
The specification does not claim to provide the unique or final answer to that requirement.
It provides a defined candidate answer that can be implemented, inspected, compared, revised and falsified.
Its central contribution is therefore twofold:
it identifies the minimum computational state of representation as an explicit research problem; and
it provides a concrete candidate specification against which that problem may be investigated.
Scientific progress may arise not only through improved observations, stronger evidence or more capable reasoning systems.
It may also arise through improving the constitutional and representational objects upon which reasoning operates.
Acknowledgements and Development Provenance
Dot Protocol Specification v0.1 was authored by Stefaan Vossen as part of the Dot Theory research programme.
The specification developed through the practical application and progressive formalisation of Dot Theory’s constitutional, admissibility and interoperability architecture. Its development was informed by Constitutional Onboarding Review (COR), Constitutional Interoperability Review (CIR) and wider framework-comparison work undertaken within the Informational Physics Institute.
Particular acknowledgement is due to the framework authors and collaborators whose participation in constitutional onboarding, interoperability analysis and methodological discussion exposed practical requirements concerning attribution, constitutional identity, provenance, residual preservation, successor-state governance and independent review.
Collaborative contributions, reviews and implementation observations do not transfer authorship or constitutional authority over this specification unless explicitly declared through a successor constitutional record.
Artificial-Intelligence Assistance Statement
Artificial-intelligence systems were used as research and drafting instruments during the development of this specification.
Their use included structural analysis, terminology comparison, consistency checking, schema drafting, adversarial questioning, textual refinement and the exploration of alternative formulations.
All constitutional objects, normative requirements, design decisions and final wording were reviewed and accepted under the authorial authority of Stefaan Vossen.
Artificial-intelligence systems are not authors, constitutional operators or responsible authorities within this specification. Their outputs were treated as provisional representations requiring human review, selection, revision or rejection.
This use of artificial intelligence reflects the Constitutional Invariant of Agency established within the specification: computational systems may support the construction and evaluation of representations, but responsibility for subsequent representational state remains attributable to the constitutional actor.
Suggested Citation
Vossen, Stefaan. Dot Protocol Specification v0.1: A Constitutional Representation Specification for Computationally Interoperable Knowledge Objects. Dot Theory, July 2026. Specification identifier: DPS-0.1. Available from the canonical Dot Theory website www.dottheory.co.uk.
Canonical Status and Successor Governance
This publication constitutes the canonical release of Dot Protocol Specification v0.1 under specification identifier DPS-0.1.
Following canonical publication, this version shall remain independently recoverable and shall not be retrospectively modified. Corrections, refinements or architectural changes shall be issued through explicitly identified successor specifications in accordance with the constitutional provenance and successor-state principles of Dot Theory.
──────────────────────────── ⊙ ────────────────────────────
End of Dot Protocol Specification v0.1
