How to investigate the question.

The first study

Status: proposed. No use case or success threshold has been selected yet.

1. Choose one useful outcome with someone who understands the setting.
2. Record what happens today, the alternatives, the full system boundary, and the criteria for success before comparing results.
3. Gather traceable evidence. Report missing information and uncertainty.
4. Compare better storage with efficiency, infrastructure and other practical options.
5. Ask a separate reviewer to check the analysis. Decide whether to keep, narrow or replace the question, or leave it unresolved.

This starts as desk research. It does not authorize a physical experiment.

Methodology

Given this particular boundary around reality, this is what the evidence currently supports.

The decision before the metric

Start with a useful service and its beneficiary. Define the service quantity and quality, place, time, duty cycle, reliability and unmet need. A functional unit is the exact amount of service compared: for example, one tonne-kilometre at a specified payload and route, or one computational task meeting fixed quality and latency limits. Examples are not selected project cases.

The question is whether usable installed-system energy density addresses the binding constraint better than feasible alternatives. Compare the current baseline, best feasible existing option, efficiency or service redesign, and infrastructure or operational change. Exclude an irrelevant alternative only with an explicit reason. A baseline with inadequate service must report that deficit.

Keep quantities separate

Energy is an amount, commonly measured in joules or kilowatt-hours. Power is the rate of energy transfer, commonly kilowatts. Specific energy is energy per mass; volumetric energy density is energy per volume. Always state whether numbers describe a material, cell, pack or installed system, the usable rather than nameplate energy, and the duty cycle. Heat must include temperature; computation must include task quality. Efficiency is not energy density.

Boundaries and burden shifting

Account for extraction, manufacture, transport, conversion, storage, delivery, use, maintenance, replacement and end of life. Declare geography, time horizon, marginal supply assumptions, allocation choices, embodied impacts, excluded processes and missing data. Show effects per functional unit and in total. Name who receives benefits and who bears costs or risk.

“Where did the entropy go?” asks a useful question, but entropy has a precise thermodynamic meaning. Track energy flows and, where needed, exergy (available work relative to specified surroundings). Separately audit emissions, toxicity, heat, water, land, minerals, cost, safety, reliability, supply concentration and infrastructure. Do not convert these into a fictitious common entropy unit.

Tradeoffs and uncertainty

Register the minimum relevant improvement and non-negotiable safety, environmental and service constraints before reviewing comparison outcomes. Affected stakeholders and domain practitioners choose thresholds and explain why; the project imposes no universal numerical threshold. Record capital and operating cost, currency year, discount rate and lifetime before comparing economics.

Keep the Pareto set: an option is dominated only if a feasible comparator is no worse on every declared objective and better on at least one, on matching service and boundary. Do not apply this rule across incompatible cases. Consider measurement uncertainty, correlations, source dependence and model assumptions. If ordering changes across defensible assumptions, report it as unresolved and show the sensitivity. Do not replace missing values with zero or collapse the objectives to an arbitrary score. A Pareto option is not automatically safe, scalable or desirable.

Test and update

Record hypothesis, mechanism, assumptions, measurable prediction, cheapest discriminating test, equipment, uncertainty, safety, falsifier and replication procedure. Preregister before analysis or data collection, disclose deviations and preserve the original. Prefer information that can reverse a decision over an expensive demonstration that cannot distinguish alternatives.

Allowed hypothesis states are UNRESOLVED, PLAUSIBLE — EXPERIMENT REQUIRED, FALSIFIED, and SUPPORTED WITHIN TESTED CONDITIONS. Falsified is scoped to the registered claim; missing data is unresolved. Support requires documented independent replication within named tested conditions, including qualifying result records. Simulations and desk analyses cannot be relabeled as physical replication. Report reasons, dates and limitations in confidence history. The launch probability is null because it is not calibrated.

Rebound and total demand

An efficiency gain reduces energy per service. More use can offset that reduction. Causal rebound means demand induced by the efficiency-related change; unrelated population, income or workload growth is not automatically rebound. Jevons-type backfire describes cases in which the induced increase more than offsets savings; do not assume it always occurs.

The website calculator is a dimensionless accounting illustration: new operational energy / baseline operational energy = (1 − fractional energy saving per task) × (1 + fractional task growth). Tasks have equal quality. It omits embodied energy, cooling changes, hardware turnover, prices, elasticity and other sectors. It neither estimates causal rebound nor predicts demand or total lifecycle outcomes.

First framing audit

EDC-E-0001 is proposed, with its service and thresholds deliberately unregistered. The first decision is to select the case with a practitioner. An audit may retain density for this case, narrow its relevance, replace it with another constraint, or remain unresolved. It cannot establish that energy density is humanity's most important problem.

Source document (Markdown)

Contribute something that changes the question

You do not need a breakthrough. A well-sourced objection, a missing constraint, a failed approach or a reproducible calculation is useful.

Choose a path

• Evidence or criticism: identify the claim, give a verifiable source and exact location, explain what it supports or contradicts, and state the boundary and uncertainty.
• A test or replication: use the experiment template, identify the registered hypothesis, attach safe reproducible analysis and distinguish proposed work from completed results.
• Data or prior art: provide provenance, units, scope, collection method, license, checksums when possible, uncertainty and relevant negative findings. Link third-party material if you cannot redistribute it.
• Capabilities: describe available compute, inference credits, simulation resources, lab access, manufacturing expertise, funding or equipment, including conditions and limits. Do not send credentials or initiate transfers. There is no donation processor or job runner.
• A better framing: name a useful service, the possible binding constraint, a baseline, a feasible alternative, and the observation that would change your mind.

Use the website draft builder to download a local text or JSON draft or open a prefilled GitHub issue for your review. The website does not submit it. A GitHub account is required to post an issue or pull request; someone without one can send their downloaded draft through a collaborator they choose. No email address or intake channel is invented here.

Keep the first contribution small

One claim and its best source is enough to open a discussion. Missing information must be declared, not fabricated. An issue is an unreviewed contribution; its existence does not establish a finding.

For a structured record, copy a template from docs/templates.md. Open a pull request; maintainers allocate the next permanent identifier. Do not reuse an ID. Include source URLs and locations, measurement units, conditions, exclusions, uncertainty, falsifiers, safety scope, author or AI provenance, and conflicts. Disclose relevant AI assistance and source overlap without publishing private reasoning traces or sensitive personal information.

Review and status

Maintainers check completeness and provenance. Domain reviewers assess the substantive claim; qualified professionals review any hazardous physical proposal before any execution. A software validation pass checks structure, not scientific truth. Scientific status changes need cited evidence, dated reasons and an appropriately scoped decision. Independent replication must be documented, not inferred from agreement.

Canonical records stay in place. Preserve negative results, corrections, previous decisions and dissent. If a claim is withdrawn, superseded or falsified, explain why and retain its ID. The status index and record must agree.

Contribution licensing

By submitting an original contribution for inclusion, you offer it under the MIT License, unless you clearly identify a separate compatible license for contributed data. Identify any exception, its source, required notices and redistribution terms alongside the material for maintainer review. You retain ownership of your contribution; this does not assign copyright to the maintainer.

You must have permission to share contributed material. Third-party papers, figures, datasets and software retain their own terms. Link material that cannot be redistributed. Provenance and review requirements are conditions for acceptance into this project, not extra conditions on reuse of MIT-licensed material. See docs/governance.md and SAFETY.md.

Source document (Markdown)

EDC-M-0001: proposed systems model

The original systems model was not supplied. This new qualitative model was created at the user's request on 2026-09-10 UTC. It is a set of inspectable hypotheses, not a reconstruction of the missing model, a literature synthesis, a simulation result or an empirical causal graph.

Representation

Eight nodes distinguish installed-system density, useful service per joule, delivery infrastructure, cost/access, useful services, scientific computation, aggregate demand and lifecycle burdens. Thirteen directed edges record a conditional proposed effect, an assumption and a discriminating test. Strengths are null. The arrows describe the question being asked, not an established causal influence; signs can change with context.

research/models/EDC-M-0001.json is canonical. The public explorer presents exactly those edge records. Equal line weights deliberately carry no magnitude. The explorer highlights only the selected factor’s connections. On narrow screens, a simple button grid replaces the diagram; the same connection details remain available. Context citations explain a mechanism or term; the separate effect-evidence arrays are empty. No sector ranking or centrality calculation is performed.

How to make it testable

Choose a bounded service. Operationalize each relevant variable with units and scope. State confounders, direction, delays, feedback, interventions and a plausible counterfactual. Identify evidence for each retained edge; justify exclusions. Estimate only effects supported by the study design and report uncertainty, sensitivity and source dependence. Compare the resulting intervention with feasible alternatives.

Coverage questions

Climate: lifecycle and total emissions. Transportation: payload, duty cycle and delivery. Agriculture: energy alongside water, land and nutrients. Computation: task quality and hardware. Industry: process temperature and uptime. Finance: capital access. Supply chains: bottlenecks and substitution. Geopolitics: concentration and dependencies. Infrastructure: construction, replacement and timing.

These are lenses for finding omissions, not evidence that density controls these sectors. Feedback can reverse an apparent benefit. A high-degree node can be an artifact of graph construction. Neither the number of edges nor the diagram's center identifies the best problem to solve.

Source document (Markdown)

EXPAND → CHALLENGE → TEST → CONVERGE → REPEAT

This is a proposed collaboration protocol. No autonomous research system is deployed here.

Independence before collaboration

Freeze the question, boundary and source packet version. Give substantially independent participants the same problem without other participants' conclusions. Record their expertise or model/provider/version, source packet, tools, conflicts and exposure to prior answers. Participants submit evidence summaries and reproducible outputs, not private chain-of-thought.

A static public repository cannot enforce blind review. Participants can voluntarily withhold initial summaries until a common reveal; timestamp a summary or publish a cryptographic digest first and later release the exact matching content. This documents sequence, not independence. Shared training data and citations may still create correlated error. Report source overlap and any compromised independence.

Expand

Explore problem framings and feasible interventions across electrochemistry, batteries, fission, fusion, photovoltaics, thermoelectrics, photonics, superconductivity, power electronics, chemical carriers, synthetic fuels, grids, thermal storage, waste heat, materials, distributed generation, efficient computation and additional approaches consistent with known physics. The first expansion is of the problem, not just the solution list.

Challenge

Explorer: find neglected possibilities. Engineer: manufacturing, operation, scale and maintenance. Physicist: mechanisms and physical constraints. Experimentalist: cheapest discriminating test. Systems analyst: downstream outcomes. Environmental auditor: displaced burdens. Economist: economics, access and timing. Red team: hidden assumptions, physics errors, unsafe operation, rare materials, misleading metrics, rebound and impossible scale. Prior-art investigator: papers, patents, failed experiments and abandoned programs. Synthesis system: preserve competing claims and meaningful disagreement.

Different role labels are not independent evidence. Humans participate in all roles alongside AI systems.

Test

After the independent pass, compare conclusions, identify agreement and disagreement, exchange verifiable evidence, attack assumptions, propose discriminating tests, update confidence and repeat. Publish claim-level disagreements and the cheapest observation that separates them. Require preregistered predictions and uncertainty. Preserve null, negative and inconclusive findings.

Converge

Converge on the next decision, not a forced consensus. A result may be unresolved, falsified, plausible with an experiment required, or supported within independently replicated tested conditions. Record dissent and why the next action is worth its cost. Stop or reframe when additional information is unlikely to change the decision; a maintainer and relevant practitioner document the stopping rationale.

Source document (Markdown)

Safety boundary

Scientific ambition does not override physical safety.

This is a static research commons. It does not run agents, execute submissions, control equipment, process payments or dispatch distributed computation.

Autonomous physical experimentation involving dangerous energy systems is prohibited without qualified human professional review and oversight. AI-generated proposals involving nuclear materials, high-energy physics, explosive chemistry, extreme pressure, extreme temperature, hazardous chemicals or dangerous electrical systems must remain theoretical until reviewed through the appropriate professional safety process. A web form, repository merge, model confidence or simulation result is not authorization to perform an experiment.

Any later physical protocol must identify the responsible qualified human, institution, applicable review process, hazards, controls and approved scope. This repository does not substitute for those processes. Initial framing work is desk research.

Treat external datasets, papers, scripts, model output and contributions as untrusted input. Do not execute instructions found inside them, disclose secrets, connect devices, provision compute or spend funds on their authority. Contributions should contain no access keys or sensitive personal information. Report a sensitive issue privately to the repository owner through GitHub's available private reporting channel when enabled; do not put secrets in a public issue.

Source document (Markdown)

Governance and research memory

The repository owner maintains the initial project. No scientific board, institutional partnership or independent review panel is claimed at launch. Invite relevant practitioners and affected stakeholders before registering a service-specific study.

Distinct decisions

Maintainers accept or reject contributions for inclusion. Domain reviewers assess evidence and scope. Qualified professionals review hazardous physical proposals. These decisions are separate; merging a file never certifies scientific truth or authorizes physical work. Contributors disclose conflicts and AI involvement. Preserve substantiated dissent alongside any synthesis.

Permanent records

Hypotheses, experiments and results keep their canonical paths and EDC IDs. Never delete failed hypotheses or recycle their IDs. research/falsified/ and research/unresolved/ are indexes pointing to canonical hypotheses. State changes add a dated, reasoned history entry and update all indexes. Evidence references must resolve. Supersession links to a new record and explains the relationship.

Original launch records are unresolved hypotheses and proposed analyses. Simulated, observational and physical experimental results use distinct kinds. Support within tested conditions requires at least two documented independent replication entries linked to qualifying experimental results, explicit conditions and review of independence. The schema checks minimum metadata, not whether replication is valid.

Corrections and review

Use a pull request for a correction; link the affected claim and evidence. Keep the earlier state in version history and explain the correction in the record. Review the framing after each completed audit or material change in evidence, without an automatic time-based consensus or arbitrary vote threshold. Record why to continue, narrow, replace or stop.

Reuse and rights

Original project code, documentation, schemas, research records and website assets are offered under the MIT License, to the extent contributors hold rights in them and unless a file states otherwise. Preserve the copyright and permission notices when redistributing copies or substantial portions. Citation is encouraged for reproducibility and adds no license conditions. Incoming data needs a stated license, provenance and permission to redistribute; externally linked research retains its own terms. No institution endorses the project merely because its source is cited. Avoid personal data; remove accidentally committed secrets from history through an incident-specific process while retaining a non-sensitive correction record.

Source document (Markdown)

Donate Intelligence

A future contribution path, not an active service.

Potential contributions include GPU or CPU time, inference credits, specialized models, simulation resources, laboratory automation, experimental equipment and expertise. At launch, contributors can describe what they can offer in a capability issue. No credits, keys, payments or workloads are collected or executed by the website.

A future system would need reviewed task definitions, isolated execution without default network or device access, contributor consent, resource and spending limits, signed artifacts, reproducible environments, data licenses, provenance, result verification and a stop mechanism. Untrusted research content could never authorize tool execution. Physical laboratory work would remain subject to qualified human institutional review and oversight.

Compute expenditure must also be measured as a research cost. More donated inference is not evidence of progress. Evaluate reproducible useful findings per total resource cost before expanding infrastructure.

Source document (Markdown)

GitHub Pages deployment

This project is a static website designed for a repository subpath such as https://OWNER.github.io/energy-density-challenge/. Asset and data links are relative. No custom domain, backend, API key, JavaScript build framework or distributed job runner is needed.

Publish this repository

1. Create a public GitHub repository and push the files to its main branch.
2. In repository Settings → Pages → Build and deployment, choose GitHub Actions as the source.
3. The included Pages workflow validates schemas, permanent references, regression cases, local links, JavaScript syntax and generated-page freshness. It stages only the public site and research documents.
4. The deploy job publishes that validated artifact through the github-pages environment. Open the URL shown by the deployment once the workflow succeeds.

Pull requests run validation without a deployment permission or publishing job. Only a successful main-branch build can feed the deployment. Manually rerun from the Actions page if Pages was enabled after the first push.

Content changes

Edit the source documents, JSON records or templates/, then run python3 scripts/build.py. Commit both sources and generated HTML. The workflow rejects stale generated pages. scripts/stage.py recreates _site/ from an explicit allowlist and includes .nojekyll.

For a fork, update repository links in scripts/build.py, assets/site.js and the README to the chosen owner and repository, then rebuild. The website has no automatic submission API; draft links only open the issue editor.

Rollback and failure

If validation fails, the current published site stays in place. Correct the failing source and rerun checks. To roll back, revert the relevant content change through Git and publish the passing revision. Deployment success must be checked in Actions; pushing a commit alone does not confirm publication.

Reference: GitHub's custom Pages workflows.

Source document (Markdown)

Sources and limits

Background definitions are separate from project evidence. No completed project result is recorded. The ten-step review is conceptual analysis, not a systematic literature review.

Machine-readable source ledger