Independent KNOWDYN model · source-available · evidence-gated
Terafab Decision Twin
Model the consequences implied by Terafab-scale claims.
Turn public, declarative assumptions into auditable thermodynamic, economic, infrastructure, governance, and public-policy consequences while keeping unknown values explicit and scenario boundaries visible.
What it does
It turns labeled scenario assumptions into auditable consequences.
The package validates evidence-coded scenario JSON, audits evidence status, preserves unknown-value discipline, computes thermodynamic and decision outputs, evaluates due-diligence gates, and exports reproducible decision material without implying official Terafab validation or private data access.
- 01Validate evidence-coded scenario JSON
Check scenario structure, required fields, time horizons, control actions, and canonical evidence metadata before analysis begins.
- 02Audit evidence status
Normalize labels and keep public, reported, user-provided, scenario, stress-test, confidential, unknown, and derived values distinct.
- 03Preserve unknown-value discipline
Record underdetermined inputs so unknown values do not silently become conclusions or verified project facts.
- 04Compute thermodynamic and decision outputs
Run formal equation modules for power, heat, water, yield, cost, governance, policy, and other coupled scenario consequences.
- 05Evaluate gates and export reproducible decision material
Translate outputs into a due-diligence gate matrix and generate JSON, Markdown, and CSV bundles with assumptions and warnings visible.
Scenario flow
Scenario JSON to decision outputs.
The run path is a plain sequence. Each step keeps inputs, evidence status, unknowns, model calculations, gates, and exports inspectable.
- scenario JSONDeclared scenario inputs and evidence metadata.
- schema validationRequired structure, fields, time horizon, and controls.
- evidence audit and status normalizationEvidence labels are checked and canonicalized.
- unknown-value disciplineUnderdetermined values remain visible.
- model modulesPower, cooling, water, manufacturing, economics, governance, policy, and related equations.
- due-diligence gate matrixGate checks translate computed outputs into review status.
- outputsScalar, vector, matrix, JSON, Markdown, and CSV results.
Scenario catalog
Review the packaged 2026 and 2026-2030 scenario files.
Each card links directly to the declared JSON scenario and summarizes its modeled horizon, purpose, and consequence domains before any run output is interpreted.
Scenario guardrail
Scenarios and stress tests are declared analytical inputs. They are not verified Terafab operating facts, official Terafab data, engineering certification, permitting conclusions, or investment guidance.
Time horizon: 2026 annual model year.
Purpose: Demonstrate evidence-gated baseline calculations using scenario assumptions.
Consequence domains: terafab phase, energy, cooling, water, manufacturing, economics, governance, policy, and control actions.
Time horizon: 2026-2030 quarterly model periods.
Purpose: Explore supportive thermodynamic, economic, governance, and regulatory conditions under which Terafab-scale milestones are more likely to be achieved in 2026-2030.
Consequence domains: terafab phase, energy, cooling, water, manufacturing, economics, governance, policy, and control actions.
Time horizon: 2026-2030 quarterly model periods.
Purpose: Explore near-failure thermodynamic, economic, governance, and regulatory conditions for 2026-2030.
Consequence domains: terafab phase, energy, cooling, water, manufacturing, economics, governance, policy, and control actions.
Time horizon: 2026-2030 quarterly model periods.
Purpose: Demonstrate multi-period scenario propagation and gate behavior.
Consequence domains: terafab phase, energy, cooling, water, manufacturing, economics, governance, policy, and control actions.
Time horizon: 2026 annual model year.
Purpose: Stress-test Terafab-scale boundary conditions without representing them as verified site data.
Consequence domains: terafab phase, energy, cooling, water, manufacturing, economics, governance, policy, and control actions.
Evidence engine
Credibility starts before analysis begins.
Inputs are evidence-coded before analysis begins. Public and declarative assumptions remain distinct from verified facts, and unknown values remain visible rather than being silently filled.
Scenario assumptions, stress-test values, reported claims, user inputs, Bayesian confidence, and confidential inputs must not be promoted into verified project facts.
Unknown values must not be silently defaulted into conclusions unless substitution is explicitly allowed.
| Status | Plain-language meaning | Can drive a scenario? | May support a verified conclusion? | Public-output handling |
|---|---|---|---|---|
verified | A sourced fact already accepted as verified for the public project or model package. | Yes. | Yes, if the cited source and scope directly support the conclusion. | Show the status and source reference; do not extend it beyond the evidence scope. |
reported | A claim from media, analyst, filing summary, or other attributable secondary/public reporting. | Yes, as a reported claim. | No by itself; it can motivate review but is not a verified project fact. | Label as reported, include attribution, and keep separate from verified statements. |
user_provided | A value supplied by the scenario author, operator, reviewer, or user. | Yes, as a user-declared input. | No by itself; user declaration does not verify the underlying fact. | Label as user-provided and avoid implying independent verification. |
scenario_assumption | An ordinary assumption chosen to explore a possible case. | Yes, as a scenario assumption. | No; it supports only scenario-dependent results. | Publish as an assumption with notes so readers can challenge or replace it. |
stress_test_assumption | An intentionally extreme or boundary-pushing value used to test robustness. | Yes, for stress tests. | No; it is not evidence that the extreme condition is real. | Mark prominently as a stress-test value and avoid presenting it as expected operations. |
unknown | A material value is unresolved, missing, null, empty, or not parseable. | Only if an explicit substitution rule or underdetermined scenario treatment is declared. | No; unknowns cannot verify conclusions. | Expose the unknown and any allowed substitution; otherwise leave affected conclusions underdetermined. |
confidential_input | A private input supplied outside the public repository without redistributing the source material. | Yes, if the scenario declares that private input was used. | No in public outputs unless independently admissible public evidence verifies the same claim. | Disclose the status and handling boundary; do not publish restricted or confidential source content. |
derived_output | A model-calculated result produced from inputs and equations. | No as an input claim; it is an output of a scenario run. | No by itself; outputs may inform analysis but do not verify their own inputs. | Publish with the input statuses, assumptions, model version, and caveats that produced it. |
Domains
Five domains, one instrumented frame.
The page is vertical so each domain can be read, compared, and inspected without horizontal slide controls or hidden panels.
Outputs and due-diligence gates
The output registry separates values, trajectories, matrices, and review gates.
Each run moves from scenario JSON through validation, evidence audit, unknown-value discipline, time-axis expansion, formal equation modules, scalar/vector/matrix outputs, a due-diligence gate matrix, and JSON, Markdown, and CSV exports. The results are scenario-dependent analytical estimates, not verified operating facts or official Terafab data.
Named outputs such as energy, average and peak site load, firm capacity margin, heat rejection, water margins, yield, readiness, cost, emissions, governance risk, legitimacy margin, and recommended phase action.
One row per annual, quarterly, or monthly model period, preserving time labels and system-state outputs so trajectories and constraint timing remain inspectable.
Gate, module-output, partner-allocation, and subsystem-state matrices show gate-by-period results and state by period for power, cooling, water, and readiness.
The export bundle supports machine-readable results, narrative decision reports, and tabular review files while keeping assumptions, warnings, and reproducibility context visible.
Scalar records carry a name, kind, value, unit, scenario ID, source status, equation reference, assumptions used, warning flags, and reproducibility hash. Those fields keep numerical results connected to evidence status and the scenario that produced them.
The gate matrix evaluates gate-by-period review posture after the formal equation modules run. It translates computed consequences into due-diligence signals without promoting assumptions, stress tests, or user-provided inputs into verified facts.
| Field | What it explains | How to read it |
|---|---|---|
severity | The analytical importance of a gate condition for the current scenario period. | Higher severity means the modeled constraint deserves stronger review before interpreting the scenario as feasible. |
status | The review posture produced by the gate calculation. | Use it to distinguish proceed, monitor, stress-test, defer, or stop style outcomes; it is not a certification or operating approval. |
margin | The modeled distance between the scenario state and the gate threshold or requirement. | Positive, near-zero, or negative margins help show reserve, tightness, or breach under the declared assumptions. |
message | A human-readable explanation of the gate result. | Read the message with the source status, assumptions, warning flags, and unknown-value notes before drawing conclusions. |
Stakeholder decision surfaces
Four screening surfaces for stakeholder decisions.
The documented stakeholder decision surfaces compress uncertainty, strategic interaction, reduced-order dynamics, and validation-readiness checks into focused views that boards, investors, policymakers, and researchers can challenge.
Gate-failure probability, dominant gate risks, and recommended phase posture.
Cost distribution medians and strategic conflict signals.
Water, wastewater, legitimacy, and public-benefit risk indicators.
Run counts, game profiles, ROM steps, and validation level.
Screening boundary
The surface is a screening artifact. It is not investment advice, official project validation, or a permitting conclusion.
Advanced simulation layer
Layer probabilistic, strategic, and trajectory analysis over the deterministic core.
The advanced layer treats terafab_decision_twin.run_scenario() as the deterministic scenario kernel, then extends it with uncertainty propagation, declared stakeholder games, reduced-order trajectories, stakeholder decision surfaces, and validation-lab checks.
Validated scenario JSON flows through the evidence-gated deterministic model before any advanced module is applied.
Runs declared distributions through the deterministic model to expose pass probabilities, gate-failure risk, and sensitivity ranges.
Analyzes declared actor strategies and payoffs for best responses, pure-strategy Nash equilibria, conflict signals, and coordination warnings.
Uses transparent low-dimensional state equations to explore time-stepped stress in power, heat rejection, water, yield maturity, and policy legitimacy.
Combines Monte Carlo, game, trajectory, and validation outputs into board, investor, policy, and research-facing screening views.
Separates execution, structural, public-range, benchmark, and expert-calibrated validation levels so screening remains distinct from official validation.
Guardrails
- Monte Carlo propagates declared uncertainty only.
- Uncertainty does not turn assumptions into facts.
- Game-theory payoffs are declared assumptions unless independently sourced.
- The model does not claim to know stakeholder preferences.
Validation readiness
Validation is a staged readiness ladder, not a claim of official certainty.
The validation lab currently supports screening through Level 2: runs, structural validation, and public-reference range checks. Level 3 benchmark validation and Level 4 expert or calibrated validation are not claimed without additional curated benchmark cases, official project data, stakeholder data, expert review, or proprietary calibration evidence.
Runs
The model runs and produces finite outputs.
Supported screening level
Structural validation
Required result fields, matrices, gates, and output structures are present.
Supported screening level
Public reference range screening
Outputs are checked against declared public-reference or dimensional ranges.
Supported screening level
Benchmark validation
Requires curated public benchmark cases before benchmark validation can be claimed.
Not claimed
Expert/calibrated validation
Requires official project data, stakeholder data, expert review, or proprietary calibration evidence.
Not claimed
Validation boundary
Validation-lab checks are screening tools and do not replace utility interconnection studies, water-authority records, permitting documents, official project data, expert engineering review, or investment diligence.
Required boundaries
The site builds trust without implying private authority.
This is an independent KNOWDYN analytical model. It is source-available, not open source, and its outputs remain scenario-dependent consequences of declared assumptions, model structure, and available public or user-supplied inputs.
Interpretation boundaries
Use the model to inspect assumption-driven consequences, not to convert scenarios, unknowns, or restricted inputs into official Terafab facts.
- Not verified Terafab operating data.
- Not an official Terafab model.
- Not a Terafab endorsement, authorization, sponsorship, or certification.
- Not investment advice.
- Not a permitting forecast, permitting conclusion, or public-agency finding.
- Not a financing, construction, operation, acquisition, adoption, or official project-status claim.
- Assumptions are not promoted into verified facts.
- Unknowns are not silently converted into conclusions.
- Restricted, confidential, or private sources are not redistributed.
- Source-available, not open source.
Inspect
Inspect the public model before the narrative hardens.
Open the repository, review evidence policy, run included scenarios, and read validation boundaries for board, policy, diligence, or technical review.
GitHub repository
README.md
Evidence Policy reference page
Architecture source Markdown
Stakeholder Decision Surfaces reference page
Validation Lab reference page
CLI source Markdown
Scenarios repository directory
Academic License source Markdown
Commercial License source Markdown
GitHub Pages publishes this PWA under /website/, generated documentation aliases for the reference wiki, evidence policy, validation lab, and stakeholder decision surfaces under /docs/*.html, raw copied Markdown for other docs and license files, and GitHub repository links for README and scenario-directory browsing.