Two observations land on exactly the same point in a plot. Are they the same state of the system?
Add their direction of travel and the answer may change. One is heading right, the other left. The position was correct; it simply left out something the question needed.
Research is full of these moments. A geometric view reveals a pattern. A derivative explains it. A numerical bound tests whether it survives between the sampled points. The useful result comes from connecting the views and preserving what each one can establish.
That is a practical role for 8DB's omnimodal architecture. Its Navier-Stokes experiment implementation brings native spatial queries, interval arithmetic, typed stored evidence and order-based comparisons into one workflow. Each mechanism contributes a different operation, with its own meaning and checks.
A small example you can see
Consider the plane curve r(θ) = (sin θ, sin 2θ). The angle θ is an auxiliary parameter. It does not represent physical time in this example.
At θ = 0 and θ = π, the curve passes through the same position: (0, 0). But its derivative is r′(θ) = (cos θ, 2 cos 2θ). The two derivative vectors are (1, 2) and (−1, 2). One points up and right; the other up and left.
A query using position alone treats those observations as coincident. A query that includes the derivative can distinguish them. Select the two views below to see what information changes.
This is an illustrative calculation, separate from the fluid experiments. The browser draws the formula; it does not run the 8DB solver or reproduce a Navier-Stokes result.
One curve · two questions
Same point. Different direction.
At θ = 0 and θ = π, both observations sit at (0, 0). Add the derivative to distinguish their directions.
Position at the crossing
Same position at the crossing
Coincident: a position-only comparison cannot distinguish these two observations.
Keep the question attached to the view
The example suggests a useful way to organize a research object. Keep the formula and its parameters, the geometry it defines, sampled positions, derivatives, any weights used in averages, and the evidence supporting a bound. Link each representation to the version and assumptions that produced it.
A table can hold these quantities, and a well-designed scientific workflow can connect them. The opportunity for 8DB is to make the relevant structures and operations native to a shared store. Researchers can then follow the connection from a promising observation to the precise calculation it calls for.
Different views still answer different questions. An average with uniform weights and an average with phase-dependent weights are different quantities. A nearest-neighbour match among samples answers a local search question. A bound over a continuous domain needs an argument that covers that domain, including the gaps between samples.
Interval analysis provides established methods for enclosing numerical results and handling roundoff. It is one way to move from a plausible picture to a checked numerical statement, provided the calculation covers the claimed inputs and domain.
The affordable calculation may be the one that asks a more precise question. If a geometric relation or a valid bound settles that question, generating a more detailed trajectory may add cost without changing the decision. The comparison starts with what the answer must establish, then counts the work needed to establish it.
Put the representations to work
In 8DB's implemented Taylor–Green experiment workflow, spatial queries help construct a Fourier calculation. The point-cloud coordinates are integer wavevectors: mathematical mode indices in an abstract coordinate space. Native region queries find the mode pairs needed by the calculation. An exhaustive comparison checks coverage of the declared finite support.
The numerical stage uses outward interval arithmetic to evaluate the predictor, residual and error bounds. The stored evidence records the configuration, support plan and predecessor it depends on. Reopening the experiment reconstructs the support, checks the dependency relationships and recomputes the committed numerical chain before accepting the recovered state.
This makes the connection operational. The spatial representation helps enumerate the calculation's inputs; the numerical engine checks bounds; the stored dependencies preserve which inputs belong to which result. A coordinate match alone cannot stand in for the numerical evidence.
The implementation review behind this article is pinned to the September source snapshot identified below. It is not a new performance campaign. The experiment concerns specified unforced, periodic Taylor–Green data under its stated analytic and arithmetic assumptions. Its numerical certificates are distinct from a formal proof or a general solution of the Navier-Stokes problem.
Keep useful alternatives in play
Two experiment configurations may offer different trade-offs. One can have a tighter error bound; another can require less computational work. Collapsing both into one score hides the choice the researcher actually needs to make.
The experiment's native order comparison retains attained results that are tied or incomparable under its declared criteria. Those criteria include exact rational time, endpoint error and accumulated ordered-pair evaluations. The work counter measures a particular calculation cost; it does not include every stage or establish a wall-clock ranking.
The comparison also checks that runs use the same viscosity and analytic weight. Taking the best coordinate from each result does not create a new certified experiment. The frontier keeps real alternatives available for the next decision.
Preserve the connection when something changes
A shared identifier tells you that views belong together. To reuse a result safely, you also need the input version, derivation and applicable assumptions. If the formula or configuration changes, dependent results need review or recomputation before they can support the revised question.
This is a familiar provenance problem. W3C's PROV model provides vocabulary for derivation and revision. In the reviewed 8DB experiment path, immutable evidence references and explicit dependencies support a concrete recovery check. A changed configuration becomes a separate run; an old certificate is not silently repurposed for it.
For a related example, When Evidence Changes, Know Which Decisions Need Review shows how recorded support can narrow a reassessment. 8DB | Native Multimodal Data: One Database, More Ways to Find Answers explores the broader idea of connected views.
Start with one question your current view obscures
Choose a research object you already understand: a curve, a simulation state or a set of candidate designs. Identify one question that becomes easier in a second representation. Then define the link back to the original object and the evidence needed to accept an answer.
That is a manageable first test of the benefit: can the connected workflow reveal a useful distinction, preserve its meaning and help you check the next step?
Send Ashley a non-confidential example with the object, the question and the two views you want to connect. That gives us a concrete starting point for an 8DB evaluation.
Implementation reference
This editorial review inspected docs/navier-stokes/EXPERIMENT-ENGINE.md and the experiment's spatial, comparison, frontier and recovery code at 8DB revision d5d0f58e. The source and claim map are retained with this article's editorial record. The interactive curve is original explanatory material, not output from that experiment. No new database execution or comparative benchmark is reported here.
Evidence scope Illustrative mathematics · Source-reviewed native experiment workflow. Explore the evidence.