PhiLab Workbench · Decision Logic · Interactive Prototype
This subpage is not a mood board for the PRD. It is an interactive V1 of the core logic: constraints, hypotheses, evidence, gate decisions, and pivots are running together as one research workbench.
The page follows the PRD on purpose: compiler logic and research state first, benchmark sweeps second, gate consequences third. That keeps the project close to DG-1 instead of drifting into elegant dashboards without scientific consequences.
Constraint compiler, hypothesis scoreboard, gate dashboard, pivot logic, and two executable browser benchmarks. In addition, a real QuTiP trajectory run is now linked below as an exportable backend bundle.
Self-dual AA specs are blocked explicitly. Monitoring without a physical window is not softened into vague optimism. If kill criteria trigger, a pivot path appears immediately instead of narrative drift.
This page translates hypotheses, theoretical constraints, evidence records, and decision gates into an interactive interface. For students it is a practical introduction to kill criteria and pivots. For researchers it is a prototype research-OS layer: specs are compiled, risk structure is made explicit, and benchmark sweeps are tied directly to gate states instead of remaining presentation slides.
The workbench follows the PRD directly: theoretical constraints block invalid specs, hypotheses are scored through evidence records, and decision gates translate results into concrete research branches. This is the minimum viable form of a serious research OS.
The scoreboard and constraint inspector expose the same state from two angles: what is active, what is blocked, where formal damage already exists, and where genuine room to explore still survives.
Status transitions only happen through evidence records, kill criteria, and formal pivot choices.
TC-1 and TC-2 remain visible as active priors. When a spec is compiled, the exact blocking rule is highlighted immediately.
Choose a preset, modify the regime, or intentionally provoke a failure case. The workbench checks the allowed search space first and only then executes the benchmark. That makes the PRD logic tangible instead of decorative.
Each run shows transparently why a spec was accepted or blocked.
No benchmark active yet.
The focus point shows how a local metric immediately turns into a gate-relevant decision.
Depending on the mode, the page renders the core observables against lambda or gamma.
The gapped mode renders cut profiles, while the monitoring mode switches to explicit trajectory fans.
DG-1 and DG-2 are presented here as operational switches. That makes the core PRD demand visible: the project should move through explicit research branches, not elegant narratives alone.
The browser workbench intentionally stays lightweight. At the same time, the current Python reference runs from the separate philab-workbench project are embedded here as complete bundles. That keeps it explicit which results belong to the browser simulation and which exist as external artifacts with manifest, summary, raw data, and report. Newly added are a small Quimb ED run and a compact Quimb scaling scan for the same gapped sensor path, both with a currently clear negative result.
exp_aa_gapped_quimb_001 · small ED check for H1-gappedExact reference run with quimb_exactdiag on an 8-site proxy chain. The current result is unambiguous: KC-1 is triggered because the minimum edge-support metric, 0.345, sits well below the support threshold.
exp_aa_gapped_quimb_scaling_001 · small scaling scan for H1-gappedMulti-size run with quimb_exactdiag across 8 to 12 sites. The result stays hard negative here as well: KC-1 remains active, and edge support stays at only 0.115 even for the largest tested size.
exp_monitoring_qutip_001 · reduced Z3 monitoring window2-site toy model, 12 QuTiP trajectories, backend qutip_mcsolve. The current export should be read as weakened: the reduced model does not yet open a robust pre-Zeno window, but it is deliberately not treated as a hard falsification of the full monitoring path.
The two earlier Python bundles remain visible on purpose. They mark the first reproducible baseline for the gapped sensor path and for the monitoring-window search before heavier backends are switched on. Together with the two Quimb runs, they now form a clearer progression of reference paths.
The same bundle logic now appears directly inside the interactive session report whenever one of these presets is active.
qutip_mcsolve from a real Python run, not a browser mockup.gamma_c_target = 0.0 weakens H3 in the toy model, but it does not replace a larger interacting study.The small Quimb ED run is the hardest local reality check for H1-gapped. Already at 8 sites, edge support falls clearly below the support threshold. This is not a soft warning but an early no-go in the small proxy model.
The scaling run answers the next fair question: was the 8-site result just an artifact? The current 8-to-12-site scan says no. Edge support remains weak even at the largest tested size.
The QuTiP path answers a different question. It does not test H1-gapped but the monitoring branch H3. The language remains intentionally more careful there: weakened rather than hard kill, because the reduced toy model does not replace the larger interacting study.
A theoretical constraint is not an intuition marker but a formal limit on the search space. In the workbench it blocks specifications that contradict the known state of the research program.
Because the project should not get trapped in elegant intermediate stories. The gates force numerical and analytical results to become explicit go / no-go decisions.
The workbench shows how research logic becomes operational: hypothesis, kill criterion, benchmark, evidence, and pivot appear here as concrete interface states rather than vague project language.
@software{lanz2026philab-page-en,
author = {Lanz, Marc},
title = {PhiLab Workbench},
year = {2026},
url = {https://phi.lanz.es/phi_workbench-en.html},
repository = {https://github.com/Devdorado/philab-workbench}
}