Constraint centrality: aluminum

Constraint centrality: aluminum, version 1.0

Classification. Derived: deterministic arithmetic over stored values; every number is reproducible from the stored ids named in the observation's metadata.

Formula. centrality_v1 (src/lib/graph/centrality.ts): starting at the entity, walk the dependency edges outward up to 6 hops, keeping for each downstream entity the largest product of edge weights along any path back to the entity, where an edge's weight is strength / (1 + number of named substitutes). The score is the sum of those best path weights over all downstream entities, rounded to three decimals. Stored once per computation date with geography World. Inputs: the relationships table (custom function constraint_centrality over the dataset built by loadConstraintCentralityDataset).

Engine rendering: The custom function constraint_centrality over the whole component dataset, for each geography and period. A period with any component missing produces no value. Rounded to 3 decimals.

Components.

• No component metrics: the inputs are stored rows outside the observations table, named below and recorded on every row.

Windows and alignment. Recomputed from the stored relationships at every derived pass (weekly, alongside graph.recompute_centrality), dated on the computation day. History is the graph's history: a change in score means edges, strengths or substitutes were curated, and the row's edge count and direct edge ids show which.

Missing data. A period is produced only when every component has a value for it; nothing is interpolated, carried forward or estimated.

Rationale. Constraint Centrality (docs/upgrade/20) asks how many important downstream systems rely on a resource, adjusted for dependency strength and substitute availability; docs/06 section 8 lists downstream dependency centrality among the factors a bottleneck label must cite. The graph already computes exactly this statistic; publishing it per entity gives every commodity a page, a history and provenance.

Limitations. Storage choice: one metric per entity rather than one metric with metadata.entity, because pages, charts and the observation key are (metric, geography, period) and one metric could not hold several entities on the same date or show one entity's history. The score is relative to the curated graph (centrality_v1), so a small graph gives small numbers and adding a chain raises every node on it. Edge strengths and substitutes are curator judgments. The inputs are graph rows, not observations, so the reproducibility harness cannot rebuild the value from observation ids; the entity id and edge ids on the row are the provenance. Requested resources with no node in the curated graph yet, and therefore no metric and no value: lithium, nickel, cobalt, graphite, rare earths, uranium. They are listed so the gap is visible; adding the entities and their dependency edges to src/data/graph is what creates the metrics.

Revision. A new computation date is a new observation; earlier dates are kept. A change in the graph formula is a new graph version and a new methodology version here.