Lexicon admission (OAP)
IPI Operational Admissibility Protocol
Status:
Working methodological and governance document developed in collaboration with participants of the Informational Physics Institute (IPI).
Version 1.0 Candidate
Operationally constrained.
Non-totalising.
Revisable.
This document does not define ontology, consciousness, reality, or universal semantic closure. Dot Theory is a governance architecture for ontological construction and those are different pursuits.
Its purpose is instead to establish procedural admissibility conditions for:
• cross-framework comparison,
• semantic interoperability,
• contextual operational translation,
• residual preservation,
• and bridge-validity discipline.
The protocol therefore functions as:
• a governance layer for the IPI-Dot Collaborative Lexicon,
• an admissibility discipline for cross-framework mapping,
• a semantic stabilisation protocol,
• and a procedural interoperability framework.
This document should not be interpreted as:
• a unifying ontology,
• a framework-ranking system,
• a metaphysical synthesis engine,
• or a replacement for empirical or mathematical work performed within individual frameworks.
The protocol governs the conditions under which frameworks may be compared operationally without forcing equivalence, semantic collapse, or hidden ontology importation.
For a schematic overview of the layered operational structure within which admissibility evaluations are situated, see the Operational-Admissibility Matrix: https://www.dottheory.co.uk/paper/admissibility-matrix
1. Motivation
As multiple frameworks entered active comparison within IPI discussions, it became increasingly apparent that semantic interoperability itself required formal operational discipline.
The problem is not merely terminological disagreement.
The deeper issue is that:
• frameworks frequently operate at different operational layers,
• preserve different invariants,
• project different structures,
• embed observers differently,
• and maintain distinct admissibility domains.
Without explicit governance, several predictable failure modes emerge:
• semantic drift,
• projection collapse,
• ontology leakage,
• hidden framework assimilation,
• false equivalence claims,
• category collapse between operational layers,
• and irreversible loss of residual structure.
This protocol therefore establishes a minimal operational discipline intended to preserve structured interoperability without forcing total convergence.
The goal is not elimination of disagreement.
The goal is admissible disagreement.
2. Foundational Operational Principle
The protocol adopts the following minimal operational position:
Operational interoperability between frameworks does not require ontological equivalence.
Instead, admissibility depends upon:
• contextual localisation,
• explicit mapping discipline,
• preserved invariants,
• declared residuals,
• operational domain validity,
• and identifiable failure conditions.
Equivalence claims therefore remain:
• local,
• contextual,
• projection-sensitive,
• and operationally constrained.
3. Purpose and Non-Purpose
3.1 Purpose
The protocol exists to:
• preserve operational clarity,
• reduce semantic drift,
• support contextual interoperability,
• localise disagreement,
• preserve residual structure,
• constrain bridge claims,
• and maintain admissibility during cross-framework comparison.
3.2 Non-Purpose
The protocol does not:
• adjudicate ontology,
• define consciousness,
• validate metaphysical claims,
• establish universal semantics,
• force theoretical synthesis,
• or replace empirical science.
No framework entering this protocol is required to:
• abandon its primitives,
• inherit another framework’s ontology,
• or accept global equivalence claims.
4. Admissibility Principles
The following operational principles govern admissible interoperability.
4.1 Contextual Admissibility
All operational claims remain context-sensitive.
A mapping admissible within one operational domain may become inadmissible outside that domain.
Operational validity is therefore local rather than globally assumed.
4.2 Projection Awareness
All projections preserve only partial structure.
Projection may destroy:
• recoverability,
• distinguishability,
• experiential locality,
• or operational invariants.
Equivalent projections do not imply equivalent source structures, representational regimes, or underlying states.
4.2.1 Representational Transition Discipline
Operational interoperability frequently requires transitions between distinct representational regimes, including mathematical, computational, conceptual, observational, phenomenological, governance, and physical representations.
Such transitions shall not be treated as self-evident.
Every representational transition should explicitly declare:
• source representational regime,
• target representational regime,
• bridge conditions,
• preserved invariants,
• residual structures,
• admissibility conditions,
• and declared failure criteria.
Mathematical coherence alone shall not be interpreted as sufficient justification for physical, empirical, computational, conceptual, or ontological interpretation.
4.3 Residual Preservation
Residual structure must be explicitly declared whenever mappings occur.
Residuals may include:
• informational loss,
• phenomenological non-transportability,
• observer-local structure,
• scale-dependent divergence,
• or unresolved mechanistic gaps.
Residuals are not automatically interpreted as:
• metaphysical failure,
• proof of incompleteness,
• or hidden ontology.
4.4 Observer Embedding Awareness
Observer participation within an operational domain may constrain:
• accessibility,
• interpretation,
• actualisation,
• and representational legitimacy.
Observer embedding does not automatically imply:
• idealism,
• relativism,
• or observer-created ontology.
4.5 Recoverability Sensitivity
Recoverability must never be assumed.
Lossless translation between frameworks is exceptional rather than default.
Mappings must therefore specify:
• preserved structure,
• unrecoverable structure,
• and projection limits.
4.6 Non-Equivalence Preservation
Operational interoperability does not imply:
• ontological identity,
• semantic identity,
• phenomenological equivalence,
• or mechanistic equivalence.
Framework disagreement remains admissible.
5. Layer Separation Discipline
The protocol distinguishes several operational categories which should not be collapsed into a single undifferentiated framework.
These include:
• semantic structures,
• operational layer taxonomies,
• bridge-validity architectures,
• phenomenological structures,
• representational systems,
• empirical prediction systems,
• and ontology claims.
Failure to preserve these distinctions risks semantic collapse and hidden framework importation.
The current IPI discussions have already demonstrated the importance of maintaining explicit separation between:
• the lexicon itself,
• operational positioning systems,
• and bridge-validity requirements.
For example:
• The lexicon defines admissibility-sensitive terminology.
• OA/L-style operational taxonomies localise where mechanisms operate.
• Bridge-discipline frameworks constrain admissible transformations between frameworks.
These objects should remain operationally distinct.
6. Mapping Discipline Requirements
All bridge claims or interoperability proposals should specify:
6.1 Source Structure
The originating framework, representation, or operational domain.
6.2 Target Structure
The framework or operational domain receiving the mapping.
6.2.1 Representational Regimes
Where applicable, bridge proposals should identify:
• source representational regime (ℛ₁),
• target representational regime (ℛ₂).
This declaration distinguishes representational transitions from changes occurring solely within a single representational regime.
6.3 Mapping Type
The proposed relationship between the source and target structures should be explicitly declared.
Examples include:
• projection,
• representational transition,
• representational bridge,
• restriction mapping,
• morphism,
• approximation,
• analogy,
• operational equivalence,
• phenomenological correspondence,
• empirical overlap,
• computational translation,
• mathematical formalisation,
• physical interpretation,
• or other explicitly declared mapping disciplines.
Where representational transitions occur between distinct mathematical, computational, conceptual, observational, phenomenological, governance, or physical regimes, the mapping should identify:
• the source representational regime (ℛ₁),
• the target representational regime (ℛ₂),
• the representational bridge (RB),
• preserved invariants,
• declared residuals,
• admissibility conditions,
• and failure conditions.
Representational transitions should not be treated as self-evident merely because two structures appear mathematically, computationally, or empirically related. The transition itself constitutes an admissible operational object requiring explicit declaration and evaluation.
6.4 Preserved Invariants
The structure claimed to remain operationally stable across the mapping.
6.5 Residual Structure
The structure not preserved.
Residuals must be explicitly named wherever possible.
6.6 Operational Domain
The contextual region within which the mapping remains admissible.
6.6.1 Terms of Use and Cooperative Admissible Space
Operational interoperability may require the declaration of Terms of Use in addition to Terms of Acceptance.
Terms of Use specify the conditions under which independently developed frameworks, operators, representations, models, or explanatory structures may cooperate within a defined inquiry.
The purpose of Terms of Use is not to establish ontological equivalence.
Rather, the purpose is to establish a procedurally declared operational region within which comparison, translation, measurement, prediction, evaluation, or interoperability may proceed.
Successful declaration of Terms of Use may establish a Cooperative Admissible Space:
A*
where:
A* ⊂ (A₁ ∩ A₂ ∩ ... ∩ Aₙ)
and:
A₁, A₂, ... Aₙ
represent the admissible spaces of participating frameworks, operators, or representational systems.
A* therefore denotes the mutually declared operational region within which participating structures may be treated as sufficiently equivalent for the stated purpose of inquiry.
Examples of structures potentially included within A* include:
• shared observables,
• shared measurements,
• shared mappings,
• shared invariants,
• shared bridge conditions,
• shared residual declarations,
• and shared evaluation procedures.
A* does not imply:
• ontological identity,
• semantic identity,
• mechanistic equivalence,
• framework containment,
• reduction,
• derivation,
• or complete interoperability.
Rather, A* represents a declared cooperation space under explicitly stated conditions.
The purpose of A* is not to eliminate disagreement.
The purpose of A* is to localise where cooperation remains admissible despite disagreement.
The resulting operational region may subsequently become the domain within which projection-relative classification, projection-relative measurement, bridge evaluation, and interoperability analysis are performed.
6.7 Failure Conditions
Conditions under which:
• the mapping collapses,
• equivalence becomes inadmissible,
• or operational interoperability fails.
6.8 Residual Status
Residual status refers to known unresolved structures, open derivations, approximation gaps, explanatory limitations, or accepted incompletenesses that remain compatible with continued framework operation.
Residual status differs from failure conditions and may evolve as derivations, formalisations, or empirical results relocate incompletenesses deeper within a framework. Such movement does not necessarily alter the framework's failure conditions.
A residual may represent:
• an unresolved derivation,
• a structural approximation,
• a known discrepancy,
• an unexplained parameter,
• or an outstanding bridge requirement.
Residuals should be recorded explicitly rather than concealed through premature closure.
Frameworks may remain admissible while carrying declared residuals.
6.8.1 Framework Admissibility History Declaration
Frameworks may undergo admissibility-relevant status transitions during their development.
Examples include:
• implicit commitments becoming explicit,
• assumptions becoming derived consequences,
• assumptions becoming theorems,
• hidden dependencies becoming declared components,
• residuals becoming bridge conditions,
• bridge conditions becoming operational procedures,
• operator clarification,
• admissibility strengthening,
• failure-condition revision,
• interoperability reclassification.
Where such transitions have been documented, associated Framework Admissibility History (FAH) records should be referenced.
Frameworks with no documented admissibility-relevant transitions may declare:
Framework Admissibility History:
• None Declared
The purpose of this declaration is not historical archiving.
The purpose is preservation of admissibility-relevant framework evolution.
Framework evolution may itself constitute an admissible object of analysis.
6.9 Bridge Case Evaluation
A proposed bridge relation between frameworks should specify:
• source framework,
• target framework,
• operational localisation,
• mapping type,
• preserved invariants,
• residual structures,
• admissibility conditions,
• failure conditions,
• empirical bridge conditions (where applicable),
• source representational regime,
• target representational regime,
• representational bridge (where applicable).
• and claimed relationship status.
Possible relationship statuses include:
• operational overlap,
• admissible mapping,
• operational equivalence,
• partial interoperability,
• unresolved,
• failed interoperability,
• containment claim under review,
• or rejected.
Bridge cases should be evaluated on the basis of declared structure rather than assertion.
6.10 Relationship Categories
The protocol distinguishes:
• Operational Overlap
Shared operational structures or invariants.
• Admissible Mapping
A valid transformation between frameworks preserving declared invariants.
• Operational Equivalence
Local equivalence under specified operational conditions.
• Partial Interoperability
Successful interoperability within a restricted domain.
• Containment Claim
Assertion that one framework fully subsumes another.
These categories should not be treated as interchangeable.
6.11 Recommended Evaluation Workflow
Bridge cases should, where practical, be evaluated using the following sequence:
Operational Localisation
Identify where the proposed mechanism, representation, or claim is asserted to operate.
Mapping Specification
Define the proposed relationship between source and target structures.
Preserved Invariant Identification
Specify which structures are claimed to survive the mapping.
Residual Declaration
Identify structures that are not preserved.
Residual Status Assessment
Identify any known unresolved structures, open derivations, approximation gaps, unexplained residuals, accepted limitations, or outstanding bridge requirements that remain compatible with continued framework operation.
Admissibility Evaluation
Determine the operational domain within which the mapping remains valid.
Failure Condition Analysis
Specify circumstances under which the mapping ceases to remain admissible.
Relationship Classification
Classify the result as:
• operational overlap,
• admissible mapping,
• operational equivalence,
• partial interoperability,
• containment claim under review,
• unresolved,
• failed interoperability,
• or rejected.
The protocol does not require successful interoperability. It requires explicit evaluation:
Operational Localisation
↓
Mapping Specification
↓
Terms of Use Declaration
↓
Cooperative Admissible Space Identification (A*)
↓
Preserved Invariant Identification
↓
Residual Declaration
↓
Residual Status Assessment
↓
Admissibility Evaluation
↓
Failure Condition Analysis
↓
Relationship Classification
7. Governance Discipline
7.1 Term Governance
Proposed additions to the lexicon should include:
• proposed term,
• operational role,
• domain of use,
• preserved invariants,
• admissibility conditions,
• residual structures,
• residual status,
• failure conditions
• overlap analysis,
• notation conflicts,
• and ontology-neutrality declaration.
7.2 Notation Conflict Awareness
Shared notation should not be assumed neutral automatically.
The current discussions have already demonstrated the possibility of:
• notation overlap,
• symbol reuse,
• and operational ambiguity between frameworks.
Notation conflicts should therefore be explicitly identified.
7.3 Provisional Status
All protocol structures remain:
• provisional,
• revisable,
• operationally constrained,
• and subordinate to methodological clarity.
7.4 Admission Status Categories
Framework-specific terms may carry one of the following statuses:
• Shared interoperability term
• Framework-specific candidate
• Contested bridge term
• Under review
• Notation conflict
• Deprecated
Status changes should occur only through documented review and contributor discussion.
7.5 Framework Submission Template
Framework-specific candidate terms should, where possible, be submitted using the following structure:
Identity
• Term
• Source Framework
• Originator
• Submitted By
• Submission Type
• Submission Date
• Framework Version
• Admission Status
Optional:
• Term Category (options):
• Foundational Term
• Operational Term
• Protocol Term
• Bridge Term
• Derived Term
Submission Provenance:
Framework submissions constitute operator-generated renderings of framework structures.
Accordingly, all submissions shall declare provenance.
Provenance records:
• the originating author(s) of the framework,
• the individual or entity submitting the entry,
• and the relationship between the submitter and the framework.
This distinction permits framework declarations, authorised contributions, external interpretations, classifications, and historical reconstructions to coexist without being conflated.
Submission Types:
O0 – Originator Declaration
Submitted by the framework originator.
O1 – Authorised Contributor
Submitted by a recognised contributor or framework steward.
O2 – External Interpretation
Submitted by an external reviewer, analyst, or scholar.
O3 – External Classification
Submitted through application of another framework or classification architecture.
O4 – Historical Reconstruction
Submitted where the framework originator is unavailable or unable to participate.
Operational Description:
• Operational Role
• Admissibility Domain
Representational Analysis:
• Representational Regime (ℛ), where applicable
• Representational Transition (RT), where applicable
• Representational Bridge (RB), where applicable
• Source Representational Regime (ℛ₁), where applicable
• Target Representational Regime (ℛ₂), where applicable
Interoperability Analysis:
• Preserved Invariants
• Overlap with Existing Terms
• Divergence from Related Frameworks
• Residual Structures (where applicable)
• Residual Status*
Note: Representational Analysis identifies the representational conditions under which a submitted object operates. Where a framework introduces or relies upon transitions between mathematical, computational, observational, conceptual, governance, phenomenological, or physical representations, the associated representational regime(s), representational transition(s), and representational bridge(s) should be explicitly declared. This permits representational assumptions themselves to become admissible objects of evaluation rather than remaining implicit within framework descriptions.
Framework Admissibility History (FAH):
• None Declared
or
• FAH-001
• FAH-002
• FAH-003
Where applicable, framework submissions should reference associated Framework Admissibility History (FAH) records documenting admissibility-relevant status transitions during framework development.
FAH template:
Record Identifier(Object Type-Framework-Sequence Number eg FAH-DT-001):
Framework:
Framework Version:
Originator:
Submitted By:
Submission Type:
Submission Date:
Component:
Previous Status:
Bridge Evaluation:
• Empirical Bridge Conditions
• Failure Conditions**
Technical Notes:
• Notation Cautions
*Residual Status refers to known unresolved structures, open derivations, approximation gaps, explanatory limitations, accepted incompletenesses, or outstanding bridge requirements that remain compatible with continued framework operation.
Residual Status should not be interpreted as failure.
**Failure Conditions describe observations, circumstances, empirical results, or operational constraints that would render the proposed mechanism, mapping, explanatory structure, interoperability claim, or framework component inadmissible.
This template is intended to support interoperability review rather than standardisation, assimilation, framework ranking, or forced convergence.
The purpose of the template is to make explicit:
• what a term does,
• where it operates and originates from,
• what it preserves,
• how it relates to other frameworks,
• what remains unresolved,
• how it may be evaluated,
• and where its limits lie.
Framework-specific submissions should therefore prioritise operational clarity over semantic uniformity.
8. Residual Declaration Discipline
The protocol adopts explicit residual declaration as a central methodological requirement.
Whenever frameworks are compared, participants should attempt to specify:
• what survives projection,
• what remains inaccessible,
• what is observer-local,
• what becomes non-recoverable,
• and what remains operationally undecidable.
Residual tracking is treated as a stabilising feature rather than a failure state.
The protocol therefore rejects the assumption that successful interoperability requires elimination of disagreement.
Instead:
structured disagreement may itself remain admissible.
9. Operational Localisation and Vertical Positioning
Several IPI discussions have highlighted the importance of distinguishing between operational layers.
Frameworks may operate primarily within:
• generative domains,
• admissibility or constraint domains,
• representational domains,
• phenomenological domains,
• or realised physical domains.
Operational positioning systems such as:
• OA structures,
• RA structures,
• and related vertical taxonomies,
attempt to localise where mechanisms function without necessarily forcing ontological equivalence.
The protocol does not enforce any single taxonomy.
However, it requires that:
• operational localisation be made explicit,
• layer transitions be identified,
• and bridge claims specify where cross-layer transformations occur.
10. Examples of Admissible Structured Disagreement
The protocol does not attempt to erase disagreement between frameworks.
Instead, it attempts to preserve operational legibility during disagreement.
Several recent IPI exchanges illustrate this behaviour.
10.1 UIFT and FFGFT Scale Divergence
Recent discussion between Onur Teker and Johann Pascher demonstrated:
• mathematical overlap at the thermodynamic level,
• divergence at cosmological scale predictions,
• explicit localisation of disagreement,
• and empirical bridge conditions.
Importantly:
• the frameworks were not collapsed into equivalence,
• residual divergence remained explicit,
• and empirical discriminability was preserved.
This constitutes an example of admissible structured disagreement.
10.2 Semantic Neutrality Concerns
Discussions involving Diana Haskins and Eric Porter highlighted the risk that:
• semantic interoperability systems may unintentionally import hidden commitments,
• notation may cease to remain neutral,
• or interoperability layers may become assimilative.
These concerns are treated within the protocol as stabilising governance constraints rather than obstacles.
10.3 Cross-Layer Localisation
José Guevara Calderon’s operational layer proposal highlighted the need to distinguish between:
• generative structures,
• admissibility structures,
• representational systems,
• phenomenological structures,
• and physical realisation domains.
The protocol treats such separation attempts as admissibility-preserving operational localisation tools rather than ontology claims.
10.4 Containment Claim Evaluation
Claims that one framework contains, derives, subsumes, or fully encompasses another should be treated as bridge cases rather than accepted by assertion.
Containment claims should specify:
• operational localisation,
• preserved invariants,
• admissible mappings,
• residual structures,
• divergence points,
• failure conditions,
• and empirical distinctions where applicable.
Absence of such specification should be treated as insufficient evidence for containment.
Containment claims may therefore remain:
• supported,
• unsupported,
• contested,
• partially supported,
• or unresolved.
10.5 Mathematical Overlap Without Equivalence
Two frameworks may employ mathematically similar normalisation structures while differing in score-generation discipline, admissibility conditions, interpretation, and empirical bridge conditions. Shared mathematical form alone therefore does not establish equivalence or containment.
11. Relationship to Existing Frameworks
This protocol does not supersede existing frameworks.
It instead attempts to preserve operational interoperability between partially overlapping systems.
Frameworks presently discussed within IPI include, but are not limited to:
• Dot Theory,
• UIFT,
• FFGFT,
• HPF-related architectures,
• RA/PM-oriented structures,
• recursive epistemic systems,
• informational field proposals,
• contextual admissibility systems,
• and phenomenological architectures.
The protocol does not require these frameworks to:
• share ontology,
• share primitives,
• share semantic closure,
• or share mechanistic commitments.
Instead, it attempts to preserve:
• explicit localisation of agreement,
• explicit localisation of disagreement,
• bridge-validity discipline,
• and operational legibility.
Where sufficient operational accord exists between participating frameworks, the resulting cooperation domain may be represented as a Cooperative Admissible Space (A*) under declared Terms of Use.
12. Failure Conditions
Operational interoperability becomes inadmissible when:
• frameworks are collapsed into equivalence without declared invariants,
• residual structure is suppressed or ignored,
• ontology claims are silently imported,
• notation ambiguity becomes unresolved,
• operational domains are exceeded,
• projection loss is ignored,
• or empirical distinguishability is erased.
The protocol therefore treats:
• semantic restraint,
• explicit locality,
• and declared incompleteness
as stabilising methodological features.
12.1 Failure Escalation
Failure of a mapping, bridge relation, equivalence claim, or containment claim should not be interpreted as failure of either framework.
Instead, failure indicates that:
• interoperability conditions were not satisfied,
• residual structures remain unresolved,
• operational domains were exceeded,
• or the proposed mapping was inadmissible.
Framework validity and interoperability validity should be treated as distinct questions.
Failure of interoperability should not be interpreted as failure of the participating frameworks themselves.
13. Concluding Statement
This protocol should not be interpreted as an attempt to construct a universal meta-theory.
Its purpose is narrower.
The protocol exists to preserve operational admissibility during comparison between partially overlapping representational systems.
It therefore functions as:
• a governance layer,
• a semantic restraint discipline,
• a contextual interoperability protocol,
• and an admissibility-preserving bridge structure.
The protocol remains:
• provisional,
• revisable,
• non-totalising,
• and subordinate to operational clarity.
In this sense, the protocol is not intended to eliminate disagreement.
It is intended to preserve the conditions under which disagreement may remain operationally meaningful without collapsing into semantic incoherence.
14. Protocol Evolution
This protocol is expected to evolve through application.
Future revisions may incorporate:
• additional bridge-case examples,
• framework-specific governance requirements,
• empirical interoperability studies,
• notation conflict resolution procedures,
• and refined admissibility evaluation criteria.
Operational deployment should inform future protocol development.
15. Scope Limitation
This protocol governs:
• interoperability claims,
• bridge relations,
• admissibility evaluation,
• semantic coordination,
• and framework comparison.
It does not govern:
• ownership,
• authorship,
• intellectual property,
• publication priority,
• patent claims,
• or attribution disputes.
Such matters remain external to the protocol.
Operational Appendix
Appendix A: Representational Transition Declaration
The Operational Admissibility Protocol recognises that many framework comparisons require movement between distinct representational regimes rather than solely between frameworks.
Such transitions shall not be treated as implicit consequences of mathematical, computational, empirical, conceptual, or explanatory success.
Rather, representational transitions are themselves admissible operational objects requiring explicit declaration and evaluation.
Accordingly, where a framework proposes, implies, or depends upon movement between distinct representational regimes, the following information should be declared wherever practicable.
Representational Transition Declaration
Source Representational Regime (ℛ₁)
The representational regime from which the proposed transition originates.
Target Representational Regime (ℛ₂)
The representational regime to which the proposed transition is directed.
Representational Bridge (RB)
The declared operational structure through which the transition is proposed to occur.
Bridge Conditions
The assumptions, operators, mappings, constraints, or procedures required for the bridge to remain admissible.
Preserved Invariants
The structures claimed to remain operationally stable across the transition.
Residual Structures
The structures not preserved, incompletely transported, or remaining unresolved following the transition.
Admissibility Conditions
The contextual conditions under which the representational transition remains operationally legitimate.
Failure Conditions
The observations, derivations, operational constraints, or empirical results that would render the proposed representational transition inadmissible.
Operational Principle
Mathematical coherence alone does not constitute sufficient justification for transitions between mathematical, computational, observational, conceptual, governance, phenomenological, or physical representations.
The representational transition itself constitutes an admissible object requiring explicit declaration, provenance, justification, residual localisation, and operational evaluation.
Purpose
The purpose of this appendix is not to restrict theoretical development.
Rather, it is to preserve explicit governance over the representational operations through which frameworks acquire mathematical, computational, observational, empirical, conceptual, or physical interpretation.
By treating representational transitions as first-class operational objects, the protocol seeks to reduce hidden assumptions, improve interoperability, strengthen bridge evaluation, and preserve the recoverability of residual structures during cross-framework comparison.
Attribution and Collaborative Status
This document emerged through active discussion and methodological exchange within the Informational Physics Institute (IPI) community.
The protocol incorporates and responds to operational concerns, distinctions, proposals, and cautions raised across discussions involving multiple contributors, including:
• José Tomas Guevara Calderon,
• Diana Haskins,
• Eric Porter,
• Johann Pascher,
• Onur Teker,
• Peter M. Austin,
• and other participating researchers.
The document should therefore be treated as an evolving collaborative methodological effort rather than a closed or authorially finalised system.
Addendum: Operational-Admissibility Matrix
The Operational-Admissibility Matrix provides a schematic orientation tool for locating claims, mappings, bridge proposals, observations, and interoperability relations across the layered structure of the Contextual Admissibility Research Programme. It should be read as complementary to the Lexicon and Operational Admissibility Protocol rather than as an independent framework: https://www.dottheory.co.uk/paper/admissibility-matrix
