Six-dimensional capability dating and dependency-constrained parity

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.

Scope of the proposed contribution

The working paper separates three candidate contributions: task- and evidence-bound historical dating; joint attainment and alternatives within a coherent architecture; and separate tests of the usefulness of six-perspective organization and dependency constraints. This is a methodological integration and audit protocol, not a claim to the first mapping of performance to years, a new mathematical theorem, or a complete taxonomy of technology.

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.

Reporting scope and qualification

R1 — Directional screening: locate important gaps without implying a complete product assessment.
R2 — Bounded subsystem audit: examine capabilities, evidence, and dependencies within an explicit boundary.
R3 — Full joint assessment: assess a complete target only after closing the necessary-condition list and freezing targets and routes.

R1 / R2 / R3 describe coverage, not stages of technical maturity.

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.

Materials

Physical carriers and material properties

Force

Force, torque, and pressure

Speed

Motion and processing under task constraints

Energy

Supply, storage, conversion, and replenishment

Information

Measurement, acquisition, storage, and transmission

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.

One design: required capabilities + compatibility + external constraints

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

Record whether a capability is provided directly by the product (D), by a host or external infrastructure (H), has no independent requirement (N), or remains unknown (U). Record necessity separately as 1 / 0 / U. Provider location and necessity are distinct fields; an external H must not automatically become N.

Earliest found is not necessarily first

Let y*_j denote the true first verified attainment date of a capability, and e_j the event date of the earliest valid record found in this search. Usually, the evidence only establishes y*_j ≤ e_j. 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.

Logical property one: propagating intervals

With a complete necessary-condition list and valid bounds l_j ≤ y*_j ≤ u_j for every required node:

G1(a) ∈ [max_j l_j, max_j u_j]

This is a conservative envelope. It needs no independence assumption and does not establish simultaneous attainability of the endpoints. Incomplete coverage or a required U prevents a full point date or full upper bound; valid lower bounds on known necessary nodes may still support an overall lower bound.

For valid intervals [l_A, u_A] and [l_B, u_B], B − A is bounded by [l_B − u_A, u_B − l_A]. Two upper bounds alone do not establish a historical date difference.

Historical backtests use only information publicly knowable at the cutoff. An earlier event disclosed later is not an input available at the historical forecast date.

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) = max_{j ∈ 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) ≤ T_feas(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: min_a max_j t(a,j).

Joint records: true, false, and unknown

Actual physical attainment is binary. U records a lack of knowledge, not a third physical state. Compatibility c and required-node records x jointly determine:

Z(a,t) = c(a,t) ∧ ⋀_{j ∈ J(a)} x_j(a,t)

All entries must be 1 for confirmed success. Any 0 means failure; without a 0, any U leaves the conclusion U. One complete successful route is enough across alternatives. Failure of all listed routes rejects only those routes, not every possible design.

Logical property two: when a maximum is valid

Within a fixed route and scenario, enumerate every necessary condition, including interfaces, supply, and architectural implementability. If each becomes true at t_a,j and remains true:

T(a) = max_j t_a,j

This is a conditional logical property, not evidence of forecast validity. Nonpersistent availability, unknown coexistence, or omitted integration constraints invalidate a simple maximum as a feasibility judgment.

Logical property three: choose a route before joint timing

For a finite, nonempty set of routes with common targets, finite dates, and the persistence conditions above:

max_j min_a t_a,j ≤ min_a max_j t_a,j

The left side chooses a different route for each target and can describe a nonexistent product. The right side chooses one complete route. Different node sets must first be mapped to common product goals while retaining route-specific constraints.

T1 / T2 / T3: diffusion of build capability

First complete build

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

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.

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.

Sustained parity: one design throughout the window

∃a ∀u ∈ [t, t + W]: Z_eq,L(a,u;ω) = 1

L denotes the parity layer, ω the scenario, and W the duration. A design must meet the conditions throughout the window. This is not equivalent to finding a different design at every instant. Allowed upgrade sequences require predefined transitions, costs, and downtime.

Probabilities require a joint model

F_T(t) = Pr(T_eq ≤ t | E_src(t0), H)
t_p = inf{t: F_T(t) ≥ p}

E_src(t0) is evidence available at the cutoff; H denotes the model and assumptions. Distinguish uncertainty in historical evidence from future randomness. Without a fitted and tested joint probability model, retain conditional scenarios or intervals instead of publishing falsely precise probabilities.

Test the bottleneck claim

Distinguish the last historical attainment, present constraints, and future scenario bottlenecks. Relax or advance a constraint within the model and check whether joint timing changes. Tied bottlenecks may require joint intervention. Sensitivity is not an established causal effect or return on investment.

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.

Means and dispersion are descriptive

Only when every necessary dimension has an equally qualified point date, compute these statistics over the k entries in the required set R:

μ_R = (Σ_{d ∈ R} y_d) / k
σ_R = √[(Σ_{d ∈ R} (y_d − μ_R)²) / k]

These do not measure difficulty or dependency strength. A common shift of all dates leaves dispersion unchanged; truncation or assigning dates to N distorts the result. The statistics are undefined at k = 0. U, N, and one-sided bounds must not enter full point statistics.

What remains to be tested

The usefulness of six-perspective organization and dependency constraints must be tested separately. Independent coding, historical backtesting, a systematic originality review, and generalizable probability calibration remain pending.

Two validation tracks

Organization: compare six perspectives with functional classification using matched information and time budgets; assess omissions, agreement, and research cost.
Prediction: with the same nodes, test whether dependencies, compatibility, and ecosystem constraints improve joint timing while preserving prediction coverage.

Freeze sampling, targets, primary outcomes, route inclusion, failure handling, and budgets before collection or unblinding. Exploratory trials are not blind tests. Separate samples by time and technology family, and involve at least two genuinely independent human analysts. AI self-checks do not replace independent coding.

Use meaningful baselines such as persistence, simple trends, and selected components, adding established methods such as TFDEA where applicable. Separately remove dimension labels, compatibility, and ecosystem constraints. Removing labels may leave numerical forecasts unchanged; test organizational usefulness rather than invent a numerical gain.

Report error, coverage, and failures

For probabilistic forecasts with confirmed 0 / 1 outcomes within the observation horizon, the Brier score is:

BS = (Σ_i (p_i − o_i)²) / n

Scenario windows are not probabilities eligible for this score, and one score alone does not establish calibration. Compute MAE only on a shared qualified, observable subset and report its coverage against the full sample. Do not replace right-censored attainment dates with the observation endpoint or label missing outcomes as failures. Report interval width with coverage, and include U rates, cost, and calibration.

Narrow claims if six perspectives add no organizational benefit, dependencies beat only weak baselines, or improvements merely raise unknown rates and cost. Correct formulas, citations, and presentation do not establish validity.

Minimum audit record

Every conclusion should trace to the task boundary, capability nodes, sources, dating qualifications, architecture, construction conditions, forecast assumptions, version, and dissent records.

Sources and version

This page is updated from Evo Research’s A Six-Dimension Protocol for Historical Capability Dating and Dependency-Constrained Technology Parity, working paper v0.1 (2026-10-12). The paper builds on the methodological protocol v0.4 (2026-09-24). Paper and protocol versions are separate; this website update does not constitute protocol v0.5.

This is an adapted public theory account, not the full working paper, a formally posted preprint, or a peer-reviewed article. This research has no preprint identifier or DOI at present, and independent empirical validation remains pending. Product cases, synthetic worked examples, raw evidence packages, and templates are not published.

The literature provides context for functional modeling, dependencies, technology forecasting, and validation; it does not imply endorsement. These are entry points, not a claim to exhaustive originality research or full-text examination of every source.

Dating capabilities.Tracing dependencies.