This document defines the three canonical branches of the Omniabase framework.
These branches are not independent theories. They are three consequences of the same foundational move:
a phenomenon should not be treated as exhausted by a single representation.
Each branch answers a different question, produces different outputs, and leads to different implementation paths.
Omniabase becomes operational in three canonical ways:
- Diagnostics -> when the question is whether structure holds
- Coordinate Discovery -> when the question is what hidden structure emerges
- Cross-Representation Translation -> when the question is how different descriptions still relate to the same object
These branches are distinct, but structurally linked.
They share:
- the same foundational principle
- the same rejection of single-view sufficiency
- the same emphasis on recoding and comparison
- the same separation between measurement, interpretation, and decision
Omniabase Diagnostics studies whether an observed structure remains stable beyond a single representation.
It asks whether apparent stability survives representational change.
When something looks stable in one representation, does that stability survive when the representation changes?
This branch may be used to measure:
- robustness
- fragility
- divergence
- drift
- regime instability
- collapse proximity
- representation dependence
Typical outputs include:
- robustness scores
- fragility indicators
- instability alerts
- divergence signals across codings
- post-hoc gates
- escalation triggers
This is the defensive branch of Omniabase.
Its role is not to primarily discover hidden structure, but to determine when apparent structural coherence is weak, local, or representation-dependent.
- post-hoc auditing of model outputs
- early warning sensing in dynamical systems
- anomaly detection
- pre-failure diagnostics
- monitoring pipelines
- structural evaluation layers
- regime shift sensing
Examples of repositories aligned with this branch include:
OMNIAlon-mirroromnia-limitPre-Deployment-Structural-GateOMNIA-RADAR
Omniabase Coordinate Discovery uses multiple representations to expose hidden axes, latent variables, structural separations, and descriptive coordinates that may remain compressed or invisible in standard views.
What structure becomes visible only when a phenomenon is observed across multiple codings rather than a single one?
This branch may be used to extract or reveal:
- hidden coordinates
- latent factors
- invisible symmetries
- regime separations
- generator distinctions
- more faithful descriptive axes
- structural reductions of complex phenomena
Typical outputs include:
- new coordinates
- structural maps
- latent-variable candidates
- regime diagrams
- generator separations
- descriptive axes for modeling and forecasting
This is the generative branch of Omniabase.
Its role is not primarily to test whether a system holds, but to reveal dimensions of the phenomenon that standard single-view descriptions fail to expose.
- dynamical systems
- chaos and nonlinear structure
- complex signals
- scientific modeling
- pattern discovery
- exploratory structure finding
- regime analysis
- multi-scale phenomena
Examples of repositories aligned with this branch include:
omniabase-coordinate-discovery
Additional future repositories may extend this branch.
Omniabase Cross-Representation Translation studies how different descriptions of the same object retain, lose, or distort shared structural content.
It is the branch that measures compatibility across descriptive boundaries.
When two descriptions appear different, how much are they still describing the same structural object?
This branch may be used to measure:
- compatibility between descriptions
- alignment between formalisms
- shared invariant residues
- dependence on encoding
- translatability across views
- structural incompatibility between representations
Typical outputs include:
- compatibility scores
- alignment measures
- translatability maps
- invariant residue profiles
- incompatibility signals
- bridges across formalisms or models
This is the interface branch of Omniabase.
Its role is not primarily to detect collapse or to discover hidden coordinates, but to determine how structure persists across descriptive differences.
- translation across formalisms
- model-to-model comparison
- multimodal alignment
- sensor fusion
- simulation vs reality comparison
- structural interoperability
- human-AI structural interfaces
Examples of repositories aligned with this branch include:
omega-translatorHASC-Human-AI-Structural-Compatibility-Protocol
A future dedicated Omniabase translation repository may formalize this branch more explicitly.
Question: Does the structure hold?
Primary concern: stability vs fragility
Typical posture: defensive
Question: What hidden structure emerges?
Primary concern: latent axes and better coordinates
Typical posture: generative
Question: How much structural continuity exists across descriptions?
Primary concern: compatibility and shared residue
Typical posture: interface / bridge
All three branches must preserve the same non-negotiable constraints.
No branch may assume that one representation is enough by default.
Structural sensing must remain distinct from semantic explanation.
Meaning and action must not be collapsed into the same layer.
Not every representation change is valid. Recoding must remain constrained, explicit, and structurally meaningful.
Branches must be defined by what they measure, expose, or compare structurally, not by broad narrative promises.
Not every repository in the ecosystem belongs directly to one canonical branch.
Some act as epistemic gateways, historical precursors, or conceptual satellites.
observer-suspension functions as a pre-layer for Omniabase:
- it weakens the monopoly of the privileged observer
- it prepares the transition from observer-centered description
- it opens the path toward representation-variable analysis
It should be read as a gateway into Omniabase, not as the whole framework.
The canonical branches are stable. Implementations may evolve.
This means:
- branches are conceptual families
- repositories are contingent realizations
- new repositories may appear
- old repositories may be superseded
- the branch taxonomy remains the same unless the framework itself changes
The three canonical branches of Omniabase are:
- Diagnostics -> tests whether structure survives representational change
- Coordinate Discovery -> reveals hidden structure through multiple codings
- Cross-Representation Translation -> measures compatibility across different descriptions
Together, they define the main operational directions of the Omniabase framework.