Simulation Evidence and Branch Narrowing¶
For the compact evidence spine, start with What CCT Already Demonstrates. This page is the more detailed simulation and artifact-status ledger.
This page summarizes the public role of CCT's simulation work as a route map from model result to bench-facing question.
The simulation layer stages claims for physical exposure: define estimators, stress-test confounders, identify operating regions, reject weak branches, and write the question that a physical bench must decide.
In the current public architecture, this page sits between the compact evidence spine and the public replication route. CCT supplies the parent finite-observer/controller program; the Open Theorem Roadmap supplies proof targets and verifier obligations; CCT Labs exposes selected claims through public-safe reference artifacts, simulations, protocols, benches, ledgers, and narrowing gates; Tau-X translates surviving or candidate primitives into space-and-motion mission architecture, state/coherence, effective-adjacency, and resource-ledger questions rather than serving as the evidence layer itself. For the runnable package and review route, use Public Replication And Review Surface. For the proof-spine and observer-conditioned status map, use Open Theorem And Observer-Conditioned Roadmap.
Positive Simulation Signals¶
CCT Labs is not waiting for hardware from a blank state. Earlier simulations produced positive candidate regimes that now motivate specific bench questions.
| Signal | Public summary | Claim class | Current burden |
|---|---|---|---|
| High-response analog / horizon-style operating region | A legacy simulation campaign found a high-response, high-coherence operating region, with response gain around 4.9x near about 88% coherence in the reported branch. |
Positive simulation discriminator and bench-target generator. | Sweep around the region; test seeds, noise, detuning, denominator choices, and baseline variants before treating it as a hardware target. |
| Cold Melt structured-drive lattice result | A structured/coherent drive produced mode-selective coherent response and a constant-factor Prog_T uplift over baseline thermal or incoherent dynamics. The conservative public summary is about 3x; older summaries rounded the family as roughly 3-4x depending on run framing. |
Positive simulation discriminator for structured drive. | Compare against phase-shuffled, random-waveform, matched-energy thermal, delayed-feedback, and omitted-energy nulls across held-out tasks. |
These signals identify candidate programmable-physics regimes with enough structure to justify physical exposure, robustness sweeps, null tests, transfer tests, and failure maps.
The next simulation burden is targeted rather than open-ended: sweep around the candidate regions, perturb seeds and detuning, compare matched-energy incumbent routes, run phase-shuffled and random-waveform nulls, evaluate held-out conditions, and map where the effect disappears. That turns hardware exposure into a region test with boundaries instead of a single all-or-nothing run.
The current lead material-control discriminator has narrowed from an earlier phase-transition holdout lineage into a protected route-state material-control lane. The public-safe Gate 1 work treats topology/retention, reset/fatigue, state-proxy readout, orthogonal readouts, environmental/artifact routes, and S1/S2 support accounting as the burden surface. The public status is burden logic and route behavior; protected protocol annexes carry material choices, operating windows, and implementation values.
What Simulations Have Already Done¶
| Lane | Public Result | What It Shows | Replication Surface |
|---|---|---|---|
| Measurement-regime / observer-mode sweep | Simulations and reduced models identify operating regions where record type and scaling become sensitive to observer mode under fixed-source controls. | The observer thesis can become an estimator test, not just ontology. | Publish the source/control assumptions, record-type metrics, bandwidth definition, nulls, and failure modes. |
| Field-control / structured field geometry | Simulation work narrowed the claim from broad controller superiority to a structured-geometry question under matched resources. | The simulation layer did real selection work by making the stronger claim smaller. | Publish the geometry-stability criterion, matched-resource comparison, drift/noise nulls, and narrowing rule. |
| Material-control / structured-vs-thermal benchmark | Simulations identify structured-favorable operating wedges and route-state candidates under energy, thermal, topology, retention, reset, and readout controls. | Structured driving is worth physical exposure when the ledger, thermal/null routes, readout independence, and support costs are declared. | Publish the task class, baseline family, energy/support ledger, closure routes, and protected-protocol status. |
| Timing / metrology lane | Long-horizon timing and effective-adjacency work is held behind null-guarded metrology gates. | Horizon claims are converted into later-stage measurement questions rather than promoted directly. | Publish the null structure, held-out controls, and promotion gates. |
What This Means¶
The current simulation record supports a staged interpretation:
- Model results define what can be claimed inside bounded assumptions.
- Simulations turn selected claims into estimators, operating regions, and branch decisions.
- Bench protocols expose the engineering claims to instruments, materials, ledgers, drift, noise, and replication.
The most important public result is branch narrowing. Some lanes became stronger. Some became smaller. Some moved from anomaly-facing language into metrology and null-control language. Some became gated follow-ons. That is evidence of an evaluation program doing selection work.
What Is Publicly Reported¶
Public summaries expose:
- the lane being tested;
- the claim status;
- the estimator or gauge family;
- the baseline and null controls;
- the operating-region or narrowing outcome;
- the hardware question that remains.
The public layer reports route behavior, claim class, ledgers, baselines, closure paths, and the bench question being staged. Lab protocol records carry build-specific choices, operating windows, calibration recipes, and implementation notebooks.
Initial Public Replication Package¶
The public-safe replication package at cct-public-replication/ exposes the parts of the simulation/evaluation stack that make route behavior checkable:
- repaired theorem/verifier behavior for BT3/BT5 command attribution and scalar OP4/BT4 declared envelopes;
- BT6 basin/path-measure and OP2 observation-to-control route surfaces, including finite-sample interval diagnostics;
- Vector OP4 multi-resource tradeoff diagnostics;
- Reference Stack schemas and manifest validation;
- hidden-energy sensitivity and observer-mode capsules;
- branch-narrowing capsules for measurement-band, field-control, material-control, timing, environmental-handle, and effective-adjacency object-family questions;
- Tau-X payload, mission-architecture, and resource-ledger templates plus filled public-safe generic examples;
- synthetic CSV examples and public-safe commands for first reruns.
This package is evidence of rerunnable method and branch-narrowing machinery. Its current examples are synthetic, schema-level, or analysis-facing artifacts rather than bench data.
Hardware Exposure Route¶
Hardware exposure is part of the staged program. Public-safe artifacts prepare that layer by fixing the claim grammar before a result is interpreted:
- synthetic capsule or route table establishes the public-safe method behavior;
- public-safe preregistration excerpt defines the claim, nulls, incumbent, denominator, and decision labels;
- specialist review checks the method, domain assumptions, and protected-boundary policy;
- protected protocol records carry final bench values, layouts, recipes, and tolerances;
- counted runs expose the selected regime to real instruments, materials, drift, noise, energy ledgers, and controls;
- bench reports and independent reruns determine whether the claim promotes, narrows, defers, or retires.
This route keeps hardware active while preventing synthetic artifacts from carrying a stronger evidence label than they have earned.
Artifact and Replication Status¶
This section answers a narrower review question: which simulation claims are currently reviewable as public artifacts, which are project-reported milestones, and what remains pending before stronger evidence labels are warranted.
| Result / lane | Claim level | Protocol status | Data status | Code status | Independent replication | Current public claim |
|---|---|---|---|---|---|---|
| High-response analog / horizon-style simulation | Positive simulation discriminator / bench-target generator | Public summary; full protocol package pending publication decision. | Project-reported run result, including the 4.9x / 88% branch summary; public release package pending. |
Project code path exists internally; public release package pending. | Independent replication follows public release and counted exposure. | Supports prediction workflow, operating-region selection, and simulation-to-protocol discipline; hardware exposure and independent replication carry the next promotion layer. |
| Cold Melt structured-drive simulation | Positive simulation discriminator / bench-target generator | Public summary; robustness package pending. | Project-reported run family with about 3x conservative Prog_T uplift over baseline thermal or incoherent dynamics. |
Project code path exists internally; public robustness/null package pending. | Not yet independently replicated. | Supports the structured-drive hardware question under matched thermal, phase-shuffled, random-waveform, delayed-feedback, and denominator nulls. |
| Cross-domain measurement-scaling fits | Estimator portability / regime mapping | Method described publicly at the concept level. | Mixed source status: some fits use public external datasets, others remain project-reported summaries. | Initial public estimator package exists; source-data package remains lane-dependent. | Independent CCT replication is lane-dependent. | Supports gauge portability and regime-mapping hygiene as lane-specific evidence. |
| Measurement-regime / observer-mode lane | Branch narrowing / bench aid | Public lane summary; bench-specific preregistration exists in lab records. | Public synthetic example exists; bench data package follows the hardware exposure route. | Initial public estimator/template package exists. | Independent hardware replication follows counted bench exposure. | Defines a fixed-source observer-mode bench question and the nulls it must survive. |
| Field-control / structured field-geometry lane | Branch narrowing / bench aid | Public lane summary; bench-specific preregistration exists in lab records. | Public synthetic example exists; bench data package follows the hardware exposure route. | Initial public template package exists. | Independent hardware replication follows counted bench exposure. | Narrows the claim to structured field geometry under matched resources before broader controller claims. |
| Material-control / structured-vs-thermal lane | Branch narrowing / protected bench-target planning | Public lane summary and Gate 1 burden logic exist; protected Gate 2 planning organizes the lead route-state material-control discriminator. | Public synthetic examples and route summaries exist; bench data package follows the hardware exposure route. | Initial public ledger/null package exists. | Independent hardware replication follows counted bench exposure. | Narrows the hardware question to structured-vs-thermal task control, route-state topology, retention/reset, readout independence, and full ledger controls. |
| Timing / metrology lane | Later-gated metrology branch | Public lane summary; promotion gates remain later-stage. | Public exemplar package follows the null-gated metrology route. | Generic null/uncertainty helper exists; lane-specific template pending. | Independent replication follows a promoted metrology exposure package. | Converts long-horizon claims into null-guarded metrology questions rather than current evidence claims. |
| Theorem/verifier route surfaces | Public method artifact / proof-review bridge | Public-safe theorem/verifier rows and review notes exist for repaired BT3/BT5 attribution, scalar OP4/BT4 declared envelopes, BT6 route checks, OP2 randomized holdout, finite-sample intervals, Vector OP4, BT7b proof-review artifacts, scalar multiwell anti-uniqueness / OP0a, QFT-data specificity-filter scaffold / OP0b, and regime-local RFH metrology envelope / OP1. | Synthetic cases and formal-scaffold artifacts. | Public verifier/estimator scripts exist for the current route surfaces. | Formal/specialist review is tracked by claim class. | Makes theorem-roadmap obligations, specificity filters, and metrology envelopes inspectable through route behavior. |
| Tau-X architecture / resource-ledger examples | Mission-architecture translation / branch narrowing | Public-safe templates and filled generic examples exist. | Synthetic examples only. | Manifest validation and template examples exist. | Aerospace/systems review remains pending before architecture influence. | Shows how CCT/Labs primitives translate into mission variables, state/coherence burdens, effective-adjacency questions, and resource ledgers while keeping Tau-X claims gated. |
Status terms:
- Public summary: enough information to understand the claim, lane, nulls, and current status.
- Initial public package: rerunnable code/templates or synthetic examples are available, while bench data and implementation details live in lab records.
- Public release package pending: the project has a named result or lane whose public rerun protocol/data/code package is still being assembled.
- Independent replication: an outside group reruns the relevant analysis or hardware test without relying on project-only artifacts.
This ledger deliberately separates simulation milestone, public rerun package, hardware exposure, and independent replication. A result can be useful before all four exist, but its evidence label must stay tied to the highest stage it has actually reached.
How To Evaluate The Simulation Layer¶
A useful review should ask:
- Did the simulation make a claim more executable?
- Did it declare the estimator and baseline?
- Did it identify confounders and failure modes?
- Did it narrow or gate a branch rather than only add positive language?
- Did it produce a concrete hardware-facing question?
That is the standard. In CCT, simulations are the translation layer between ontology, formal claims, and physical exposure.