← Back to research

Dating capabilities.
Tracing dependencies.

Six-dimensional capability dating and dependency-constrained parity

Public theory · v0.4Updated 2026-10-12

No product case studies or synthetic worked examples are included.

What the method asks

Which capabilities does a product require? When did each become possible? When could they coexist in a single feasible design? Under which conditions might a current gap close? The method starts from tasks, organizes systems and dependencies, and reports evidence-qualified dates.

This is Evo Research’s research framework and operating protocol. It is not an empirically validated universal scale of technological advancement. A shared unit of years does not make product value, quality, or development difficulty a single measurable property.

Three maps, three questions
  • Historical capability dates: where required capabilities sit in history.
  • Present capability comparisons: met, behind, ahead, trade-off, or unknown under matched conditions.
  • Future parity dates: conditional joint attainment within a stated design and scenario.

A comparison of two products is not an industry frontier. This method does not directly predict purchase value, profits, sales, or market replacement.

Freeze the comparison boundary

Specify the object: a functional category, a technical route, or an exact product configuration. Define the core task, market, user, operating conditions, tolerances, safety, and reliability before searching historical evidence.

Express the task as an action, object, conditions, and acceptance threshold. Record allowed substitutes, external infrastructure, evidence cutoff, forecast horizon, static or moving benchmark, and sustained-attainment window. A changed target requires a revised protocol and affected conclusions to be recomputed.

Physical performance, cost, lifetime, and precision define thresholds. Years record when those thresholds were met. Launch dates and publication dates cannot automatically stand in for capability dates.

Six perspectives, not six independent parts

Decompose functional systems first. Enumerate required capabilities with testable thresholds, identifiable evidence, and explicit interfaces. A capability can belong to several perspectives but retains one node identifier.

M

Materials

Physical carriers and material properties

F

Force

Force, torque, and pressure

V

Speed

Motion and processing under task constraints

E

Energy

Supply, storage, conversion, and replenishment

I

Information

Measurement, acquisition, storage, and transmission

C

Intelligence

Control, inference, judgment, and coordination

Material requirements must coexist within a usable material system. Peak or unloaded values cannot replace force requirements. Speed concerns physical motion or processing at the required quality. Pure software with no independent physical motion requirement may mark Force and Speed as N; latency and throughput still belong in the relevant constraints.

Safety, precision, lifetime, reliability, yield, environment, cost, and compliance remain cross-cutting constraints even when they do not fit a single perspective.

Make dependencies and alternatives explicit

Nodes record required capabilities, thresholds, responsible systems, dimension tags, and evidence states. Edges distinguish prerequisites, coexistence and interfaces, conflicts, allowed substitutes, and external supply.

AND requires every condition within one design. OR permits choosing a complete alternative design. Cyclic dependencies require coupled assessment. A capability supplied by a host or infrastructure may still be necessary.

Assess joint attainment within the same route. Combining the best individual results from incompatible routes does not establish a feasible product.

Earliest found is not necessarily first

Let y*j denote the true first verified attainment date of a capability, and ej the event date of the earliest valid record found in this search. Usually, the evidence only establishes y*j ≤ ej. Not finding an earlier record does not prove that none existed.

Keep event dates, publication dates, public-knowledge dates, and access dates separate. Outputs may be confirmed dates, upper or lower bounds, intervals, qualified estimates, U, or N. An unverified candidate record remains U in formal results.

Two upper bounds cannot simply be subtracted. Each interval endpoint needs evidence. Historical gaps do not justify an arbitrary probability distribution.

Separate capability attainment from system feasibility

For a fixed design a, J(a) contains all required capabilities. When coverage is complete, internal performance coexistence is established, and dating qualifications are satisfied:

G1(a) = maxj ∈ J(a) y*j

G1 records separate experimental or prototype attainment. System feasibility also requires interfaces, coupling, and shared constraints to hold within the same architecture.

G1(a) ≤ Tfeas(a) ≤ T1(a)

This ordering requires consistent boundaries, the same route, and qualified true dates. Necessary unknowns or incomplete lists prevent full point-date or full upper-bound claims. Integration time is not an arbitrary fixed number of years.

Across alternative routes, where sustained availability and compatibility permit the simplification, find the latest condition within each route, then choose between complete routes: mina maxj t(a,j).

T1 / T2 / T3: diffusion of build capability

T1

First complete build

A complete product or service performs the core task; experimental prototypes are allowed. Components, simulations, and paper titles alone are insufficient.

T2

Independent institutional replication

An independent professional institution can build, tune, maintain, and repeatedly perform the core function under allowed supply conditions. Buying a finished system or calling a closed API is not independent replication.

T3

Individual-level replication

An independent ordinary individual or small team can build and maintain the system within fixed knowledge, budget, skill, and tool conditions, without buying a prohibited complete core black box.

T stages apply to the complete product or frozen functional category, not to every component. T3 also requires T2-level independent-build evidence. Fix budget base year, team size, time, space, allowed modules, and skill thresholds in advance.

These stages are not NASA TRL, mass production, consumer adoption, or purchase availability. Qualified evidence can establish T1 ≤ T2 ≤ T3; the inequality cannot fill unknown dates.

Parity has a direction and a scope

A → B means the pursuing object A is compared with benchmark B. Freeze operating conditions, metric directions, tolerances, and evidence cutoff. A static benchmark and a progressing benchmark require separate treatment.

  • Joint technical attainment: one design meets all required performance, safety, and other constraints.
  • Manufacturing and availability: add stated yield, cost, supply, capacity, and target-market access.
  • User experience: add user-specific tasks, coverage, waiting, and maintenance conditions.

Technical parity does not imply market replacement. If experience permits different technical compromises, define a separate target rather than impose a nested time ordering.

Future dates are conditional forecasts

Future dates require an explicit target, complete candidate routes, and internally consistent scenarios. Each derivation records present gaps, time series, models, remaining breakthroughs, coexistence, manufacturing translation, infrastructure, failure scenarios, sensitivity, and update triggers.

Outputs may be observed attainment, model forecasts, conditional windows, unknown U, no credible route identified NC, or no independent requirement N. Discussion windows are not probability forecasts; evidence stages are not probabilities.

The maximum of individual metric quantile dates is not automatically the product quantile date. Probabilistic models must handle dependence, routes, interfaces, and failures jointly, with priors, fitting, and out-of-sample checks recorded.

Earliest means earliest within the listed routes, targets, and models. No attainment before a forecast horizon does not mean impossible forever. Sustained parity requires joint conditions to hold throughout the stated window.

Unknown is neither zero nor failure

U
Insufficient evidence or unknown attainment.
N
No independent requirement within the current task boundary.
NR
Not attained as of the observation date.
NC
No credible route identified within the stated search scope, target, and horizon.
SI
Evidence supports structural unattainability within a specified boundary; constraints and reassessment conditions must be stated.

When coverage, necessity, or dating qualifications are incomplete, report bounded subsystem audits or directional screening. Unknowns, N markers, and one-sided bounds do not enter full point statistics.

Mean capability years and their dispersion describe historical position only. They are not advancement scores, complexity, or difficulty. The legacy display origin of 1687 is a presentation convention excluded from primary statistics.

What remains to be tested

Whether six perspectives reduce omissions, dependency models reduce premature forecasts, or ecosystem constraints improve parity assessment requires empirical testing. Independent coding, historical backtesting, a systematic originality review, and generalizable probability calibration remain pending.

Validation should freeze historical information cutoffs, assess inter-analyst agreement, compare against simple trends and applicable existing multi-attribute methods, and separately remove dimension labels, compatibility, and ecosystem constraints. Retain failures and non-attainment; report errors, calibration, interval coverage, unknown rates, and research cost.

Definitions, correct formulas, and citations are not validation. If no additional predictive benefit is found, narrow the claims or retain the framework as an audit tool.

Sources and version

This public account is adapted from Evo Research’s Six-dimensional Capability Dating: Technical Dependencies and Parity Roadmaps, v0.4 (2026-09-24). Website edition: 2026-10-12. Product cases, synthetic worked examples, raw evidence packages, and template files are not published.

Related work provides background and does not imply endorsement of this framework. These are literature entry points, not a claim to an exhaustive review or full-text examination.

Copyright & citation ↗