Simulation-gated validation ladder for HRM neural weight-to-phase mapping.
This repository explores whether selected neural-network weight matrices can be mapped into HRM-style photonic transfer-function candidates using deterministic simulation, abstract phase/coupler parameterization, perturbation testing, and synthetic calibration gates.
This is a simulation-only planning toolkit. It helps reviewers inspect which model layers are mappable in the abstract HRM simulation path, which layers stay classical, which errors dominate, and which hardware evidence is still missing.
Start here:
- Quickstart:
docs/QUICKSTART.md - Reviewer guide:
docs/REVIEWER_GUIDE.md - Static dashboard:
dashboard/index.html - Decision report:
reports/future-work/hrm-neural-mapping/model-to-hrm-decision-report.json - Artifact hashes:
reports/future-work/hrm-neural-mapping/ARTIFACTS.sha256
Release line:
v0.1.0is the stable simulation-only planning framework release.v0.2.0-alpha.1added the first planning toolkit snapshot.v0.2.0-alpha.2focuses on review and usability hardening.v0.2.0-alpha.3prepares the solo-complete partner/reviewer package.
Claim boundary: this repository does not claim hardware validation, foundry calibration, measured transfer matrices, production inference readiness, real hardware latency, real hardware energy efficiency, physical accuracy, quantum advantage, hardware-native intelligence, or power-free computation.
This is a small, dependency-free research harness for one specific question:
Can selected neural-network weight matrices be translated into HRM-style photonic transfer-function candidates and evaluated along explicit evidence stages?
The current pipeline covers:
- deterministic test weight matrix generation
- compact SVD reconstruction
- passive singular-value normalization
- abstract real-valued mesh approximation
- rectangular neural layer simulation via orthogonal completion and rectangular singular-value transfer cores
- complex-valued unitary-factor simulation with phase-aware error metrics
- abstract phase/coupler parameter records
- deterministic perturbation simulation
- synthetic/oracle calibration simulation
- evidence gates for foundry models, measured transfer matrices, and hardware benchmarks
- generated JSON reports and SHA-256 artifact hashes
This repository does not claim:
- hardware-native intelligence
- autonomous cognition
- quantum consciousness
- power-free computation
- quantum advantage
- foundry calibration
- measured hardware validation
- measured transfer matrices
- production inference readiness
- an end-to-end hardware benchmark
- a hardware readiness improvement for another project
The current evidence is limited to simulation and synthetic calibration.
| Stage | Status | Evidence Level | Meaning |
|---|---|---|---|
| 0 | complete | theoretical_extension | Future-work specification and claim boundaries exist. |
| 1 | complete | numerical_simulation | A deterministic SVD mapping demo reconstructs the normalized target. |
| 2 | complete | abstract_mesh_simulation | Abstract phase/coupler parameterization exists for the square demo case, with supplemental rectangular and complex/unitary support. |
| 3 | complete | uncalibrated_perturbation_simulation | Deterministic perturbation models report error deltas. |
| 4 | complete | synthetic_calibration_simulation | Simulation-only calibration uses a synthetic/oracle target. |
| 5 | blocked | foundry_calibration_gate | Requires foundry-calibrated device models or S-parameters. |
| 6 | blocked | measured_transfer_matrix_gate | Requires measured HRM transfer-matrix artifacts with provenance. |
| 7 | blocked | hardware_benchmark_gate | Requires an end-to-end measured hardware inference benchmark package. |
Blocked gates are successful schema outcomes. They identify missing evidence; they are not completed hardware milestones.
Requirements:
- Python 3.10 or newer
jqsha256sum
Install the local package:
python3 -m pip install -e .Run the full validation check:
make checkEquivalent manual commands:
python3 scripts/run_hrm_neural_mapping_demo.py
python3 scripts/run_hrm_neural_validation_ladder.py
python3 -m unittest discover -s tests -v
jq empty docs/future-work/evidence-ledger.json
jq empty reports/future-work/hrm-neural-mapping/validation-ladder-summary.json
sha256sum -c reports/future-work/hrm-neural-mapping/ARTIFACTS.sha256
python3 scripts/check_artifact_hash_coverage.py
python3 scripts/check_no_local_paths.py
python3 scripts/check_claim_boundary.py
git diff --checkReviewer-oriented CLI commands:
python3 scripts/hrmwtp.py --help
python3 scripts/hrmwtp.py summary
python3 scripts/hrmwtp.py decision
python3 scripts/hrmwtp.py portfolio
python3 scripts/hrmwtp.py model-card low_rank_adapter_demo
python3 scripts/hrmwtp.py list-reports
python3 scripts/hrmwtp.py doctorEach CLI command prints a short simulation-only disclaimer.
The generated ladder is intentionally split into early simulation stages and late evidence gates.
Stages 0-4 are reproducible local simulation/future-work artifacts. Stages 5-7 remain blocked until external evidence is supplied:
- Stage 5 requires foundry-calibrated device models or equivalent S-parameters.
- Stage 6 requires measured HRM transfer matrices with provenance.
- Stage 7 requires measured end-to-end hardware benchmark evidence.
The summary-level claim flags remain false:
hardwareValidated=false
foundryCalibrated=false
measuredTransferMatrixAvailable=false
productionInferenceReady=false
Generated reports are written to:
reports/future-work/hrm-neural-mapping/
Key files:
stage-0-specification.jsonstage-1-svd-demo.jsonstage-2-mesh-constrained.jsoncalibration-plan.jsoncomplex-unitary-mesh-support.jsonerror-budget-report.jsonerror-budget-analysis.mdhardware-design-space-sweep.jsonhardware-design-space-analysis.jsonhardware-design-space-pareto.mdhardware-requirements-envelope.jsonhardware-requirements-analysis.jsonhardware-scenario-estimates.jsonhardware-scenario-analysis.jsonlayer-stack-inference-demo.jsonlayer-stack-error-analysis.jsonmatrix-family-benchmark.jsonmatrix-family-analysis.jsonmodel-export-adapter-demo.jsonmodel-export-adapter-validation.jsonmodel-portfolio-benchmark.jsonmodel-portfolio-ranking.jsonmodel-portfolio-decision-summary.mdmodel-portfolio-explainer.mdmodel-cards/partner-readiness-report.jsonpartner-readiness-report.mdexternal-review-checklist.jsonreproducibility-capsule.jsonreproducibility-capsule.mdsolo-completion-audit.jsonsolo-completion-audit.mdv0.2.0-alpha3-readiness.jsonv0.2.0-alpha3-readiness.mdmodel-to-hrm-decision-report.jsonmodel-to-hrm-decision-report.mdmodel-weight-import-demo.jsonmodel-weight-eligibility-analysis.jsonmodel-suitability-profile.jsonmodel-suitability-analysis.jsonrectangular-matrix-support.jsonrelease-readiness-v0.1.0.jsonrelease-readiness-v0.1.0.mdreview-pack-summary.jsonreview-pack.mdreview-pack-metrics.csvreview-pack-stage-table.mdreview-pack-limitations.mdscaling-benchmark.jsonscaling-analysis.jsonstage-3-perturbation-model.jsonstage-3-perturbation-sweep.jsonstage-3-sweep-analysis.jsonstage-4-simulated-calibration.jsonstage-4-calibration-sweep.jsonstage-4-calibration-analysis.jsonstage-5-foundry-calibration-gate.jsonstage-6-measured-transfer-matrix-gate.jsonstage-7-hardware-benchmark-gate.jsontransfer-matrix-assimilation-plan.jsontransfer-matrix-ingestion-sandbox.jsonv0.1.0-rc1-readiness.jsonv0.1.0-rc1-readiness.mdvalidation-ladder-summary.jsonARTIFACTS.sha256
The evidence ledger is written to:
docs/future-work/evidence-ledger.json
Schema documentation for future hardware evidence gates:
docs/future-work/foundry-calibrated-device-model-schema.mddocs/future-work/measured-transfer-matrix-fixture-schema.mddocs/future-work/hardware-benchmark-acceptance-schema.mddocs/future-work/model-weight-manifest-schema.mddocs/future-work/model-export-adapter-protocol.mddocs/future-work/transfer-matrix-assimilation-protocol.mddocs/ROADMAP-v0.2.mddocs/QUICKSTART.mddocs/REVIEWER_GUIDE.mddocs/PARTNER_READINESS.mddocs/LAB_DATA_REQUEST.mddocs/FOUNDRY_DATA_REQUEST.mddocs/HARDWARE_EVIDENCE_CHECKLIST.mddocs/EXTERNAL_REVIEW_CHECKLIST.mddocs/REPRODUCIBILITY.md
The static dashboard is written to:
dashboard/index.html
Stage 2 is complete only as an abstract mesh simulation.
It implements deterministic quantized Givens rotations and abstract phase/coupler setting records for the current small square demo matrix, supplemental rectangular-matrix simulation, and supplemental complex/unitary factor simulation. It does not implement a real HRM layout, a foundry-calibrated photonic mesh, a measured transfer matrix, or a production phase synthesis pipeline.
Current Stage 2 scope:
- small deterministic square main demo matrix
- rectangular supplemental cases for 6x4, 4x6, and rank-deficient 5x3 matrices
- complex/unitary supplemental cases for 2x2 and 4x4 complex matrices
- main demo remains a real-valued orthogonal approximation
- no Clements or Reck physical interferometer layout
- no foundry layout synthesis
- no physical phase synthesis
- no physical coupler synthesis
Important Stage 2 flags:
abstractPhaseParameterizationImplemented=true
abstractCouplerParameterizationImplemented=true
physicalPhaseSynthesisImplemented=false
physicalCouplerSynthesisImplemented=false
foundryLayoutSynthesisImplemented=false
realChipMesh=false
hardwareValidated=false
The supplemental report complex-unitary-mesh-support.json extends the
simulation-only mapping path to complex-valued matrices and unitary-factor
handling.
The representation is:
complex W
-> complex QR unitary factorization
-> abstract phase-quantized unitary factor
-> residual factor reconstruction
-> relative, phase-aware, and amplitude-aware error metrics
This is not a full complex SVD pipeline and not a physical phase-synthesis implementation. It does not define a Clements/Reck physical interferometer layout, a foundry layout, a measured transfer matrix, or a production inference path.
The report includes a 2x2 unitary-like case, a deterministic 4x4 complex case, and a phase-dominant 4x4 case. All hardware evidence flags remain false.
The supplemental reports matrix-family-benchmark.json and
matrix-family-analysis.json compare the current abstract mapping paths across
small deterministic matrix families.
The benchmark covers:
- identity 4x4
- diagonal dynamic-range 4x4
- low-rank 6x4
- rank-deficient 5x3
- ill-conditioned 4x4
- sparse-like 6x6
- dense seeded 4x4
- rectangular tall 8x4
- rectangular wide 4x8
- complex phase-dominant 4x4
- unitary-like 4x4
Square real cases use the abstract real-valued mesh path, rectangular cases use orthogonal completion and rectangular singular-value transfer cores, and complex cases use complex QR unitary-factor handling. The analysis report summarizes best/worst cases, maximum error delta, average mesh-constrained error, and rankings by reconstruction error and condition-sensitivity proxy.
This remains a small deterministic simulation benchmark. It is not a sampled training distribution, not a large-model benchmark, not a physical layout, not a measured transfer matrix, and not a hardware benchmark.
The supplemental reports layer-stack-inference-demo.json and
layer-stack-error-analysis.json compose mapped linear layers into tiny
deterministic toy inference paths.
The primary model is:
input dimension 4
-> Linear 4x6 mapped through the abstract HRM simulation path
-> classical ReLU outside the optical mesh
-> Linear 6x3 mapped through the abstract HRM simulation path
-> output dimension 3
The report also includes a rectangular projection chain:
4 -> 8 -> classical ReLU -> 4
Only linear layers are mapped through the abstract HRM transfer simulation. Bias additions remain classical outside the optical mesh. ReLU remains a classical activation outside the optical mesh. No optical nonlinearity, full neural-network acceleration, production inference readiness, timing, energy, measured transfer matrix, or hardware validation is claimed.
The analysis report identifies the worst layer by relative error, summarizes cumulative error trends, and records activation-boundary notes for the toy models.
The supplemental reports model-weight-import-demo.json and
model-weight-eligibility-analysis.json validate a deterministic JSON manifest
for external model-weight artifacts.
The fixture model is:
tiny_mlp_manifest_4_6_3
-> rectangular_linear 6x4 with bias and classical ReLU after the layer
-> rectangular_linear 3x6 with bias
The importer checks required manifest fields, ISO export date, repository- relative artifact references, SHA-256 hashes, dtype metadata, and layer shapes. It rejects absolute paths, local path fragments, missing fields, and wrong hashes. PyTorch is not a required dependency; a future exporter can generate this manifest format externally.
Mapping eligibility is schema-driven:
linear,rectangular_linear, and supportedcomplex_linearlayers are eligible for abstract simulation mapping.convolution,attention_softmax, andembeddingare ineligible and not implemented.- bias additions, activations, normalization, and other non-linear operations remain classical outside the optical mesh.
This is an import and eligibility layer only. It does not execute a PyTorch model, does not accelerate a full model, does not implement optical nonlinearities, and does not claim hardware validation.
The supplemental reports model-suitability-profile.json and
model-suitability-analysis.json turn the model-weight manifest into a
simulation-only planning profile.
The profiler classifies manifest components as:
- optically mappable linear, rectangular-linear, or complex-linear candidates
- classical bias, activation, or normalization components outside the optical mesh
- unsupported convolution, attention-softmax, embedding, or other components
For the deterministic tiny MLP fixture, the report counts two mappable rectangular linear weights, two classical bias components, and one classical ReLU boundary. The suitability score is a heuristic simulation-only planning score. It is not hardware validated, not a production-readiness metric, and not evidence that the model runs on a real photonic device.
The supplemental reports scaling-benchmark.json and scaling-analysis.json
test how the simulation-only mapping behaves as matrix sizes and layer shapes
grow within a CI-light deterministic suite.
The suite includes:
- square 4x4, 8x8, and 16x16 real matrices
- rectangular tall 8x4 and 16x8 matrices
- rectangular wide 4x8 and 8x16 matrices
- low-rank 16x8 and rank-deficient 12x6 matrices
- dense seeded 16x16 matrix
- phase-dominant complex 8x8 matrix
The analysis reports best/worst cases, average and maximum mesh-constrained
error, error by shape family, and error by matrix size. estimatedOperationScale
is a deterministic size proxy only. It is not a runtime measurement and not a
hardware performance claim.
The scaling reports do not claim hardware latency, hardware throughput, hardware energy efficiency, accelerator performance, foundry calibration, measured transfer matrices, or production inference readiness.
Post-v0.1.0 work extends the simulation-only framework into a more usable planning toolkit without changing hardware evidence status.
The model-portfolio artifacts are:
model-portfolio-benchmark.jsonmodel-portfolio-ranking.jsonmodel-portfolio-decision-summary.md
They compare tiny_mlp, projection_chain, low_rank_adapter_demo,
sparse_linear_demo, and transformer_block_manifest_only fixtures. The
ranking is a simulation-only planning label, not hardware evidence.
The optional export-adapter artifacts are:
model-export-adapter-demo.jsonmodel-export-adapter-validation.jsondocs/future-work/model-export-adapter-protocol.md
They define how an external framework exporter can write the existing manifest format. PyTorch remains optional and is not a required dependency.
The design-space explorer artifacts are:
hardware-design-space-sweep.jsonhardware-design-space-analysis.jsonhardware-design-space-pareto.md
They sweep phase bits, insertion loss, phase noise, and calibration interval proxies. Latency and energy fields are deterministic planning proxies only.
The transfer-matrix ingestion sandbox artifact is:
transfer-matrix-ingestion-sandbox.json
It uses a synthetic test-only fixture to exercise ingestion, normalization, and target-vs-observed comparison logic. It is not measured transfer-matrix evidence and it keeps Stage 6 blocked.
The CLI and dashboard artifacts are:
hrmwtp checkhrmwtp regeneratehrmwtp summaryhrmwtp decisionhrmwtp portfoliohrmwtp model-card <model-id>hrmwtp list-reportshrmwtp doctordashboard/index.html
The dashboard is static HTML summarizing generated simulation reports. It is not hardware evidence.
The partner/reviewer readiness artifacts are:
docs/PARTNER_READINESS.mddocs/LAB_DATA_REQUEST.mddocs/FOUNDRY_DATA_REQUEST.mddocs/HARDWARE_EVIDENCE_CHECKLIST.mddocs/EXTERNAL_REVIEW_CHECKLIST.mddocs/REPRODUCIBILITY.mdpartner-readiness-report.jsonexternal-review-checklist.jsonreproducibility-capsule.jsonsolo-completion-audit.jsonv0.2.0-alpha3-readiness.json
These artifacts make the project easier to review and discuss with partners. They do not add partner evidence, lab results, foundry data, measured transfer matrices, or hardware benchmark results.
Post-alpha.12 planning reports turn the simulation-only framework into a decision aid without changing hardware readiness.
The parametric scenario reports are:
hardware-scenario-estimates.jsonhardware-scenario-analysis.json
They compare deterministic assumed scenarios such as optical-core-only, readout-inclusive, full electro-optical control stack, lossy mesh, and calibration-heavy operation. The latency and energy values are labeled as parametric estimates, not measured hardware performance.
The requirements reports are:
hardware-requirements-envelope.jsonhardware-requirements-analysis.json
They derive simulation-derived requirement envelopes for target output-relative error thresholds. These envelopes are planning constraints only. They are not real hardware specifications and they do not change Stage 5, Stage 6, or Stage 7.
The error-budget artifacts are:
error-budget-report.jsonerror-budget-analysis.md
They combine baseline mapping, rectangular mapping, complex/unitary approximation, perturbation, calibration residual, layer-stack, and scaling terms into additive, RSS, and conservative-max simulation envelopes. They are not hardware accuracy evidence.
The calibration planning artifacts are:
calibration-plan.jsontransfer-matrix-assimilation-plan.jsondocs/future-work/transfer-matrix-assimilation-protocol.md
They define how a future lab package should measure, hash, validate, and assimilate a measured HRM transfer matrix. They include no measured matrix and keep Stage 6 blocked.
The decision-report artifacts are:
model-to-hrm-decision-report.jsonmodel-to-hrm-decision-report.md
They combine suitability, mapping error, parametric scenarios, requirements, error budget, and missing hardware evidence into one simulation-only decision report. The report starts with: "This is a simulation-only decision report. It is not hardware evidence."
The RC-readiness artifacts are:
v0.1.0-rc1-readiness.jsonv0.1.0-rc1-readiness.mddocs/ROADMAP-v0.2.md
They summarize included capabilities, simulation-only scope, decision-report capabilities, blocked hardware gates, verification commands, known limitations, and recommended v0.2 work.
The review pack collects the existing simulation-only reports into concise review artifacts:
review-pack-summary.jsonreview-pack.mdreview-pack-metrics.csvreview-pack-stage-table.mdreview-pack-limitations.md
The Markdown report states: "This is a simulation-only review pack. It is not hardware evidence."
The review pack summarizes stage status, supplemental report coverage, key reconstruction and error metrics, perturbation sensitivity, synthetic calibration improvement, blocked hardware gates, limitations, and a reviewer checklist. It does not add new physics, does not change any report metric, and does not unblock Stage 5, Stage 6, or Stage 7.
The release-candidate readiness artifacts are:
release-readiness-v0.1.0.jsonrelease-readiness-v0.1.0.md
They audit documentation, report indexing, artifact hashes, local-path hygiene, claim-boundary enforcement, and the blocked state of Stage 5, Stage 6, and Stage 7. They are stabilization artifacts only. They do not add a simulation capability, do not provide foundry or measured evidence, and do not claim hardware validation.
The make check target runs the release-readiness guard set:
- report generation
- unit tests
- JSON validation
- SHA-256 hash validation
- generated-report hash coverage
- local-path hygiene
- claim-boundary guard
- whitespace check
The supplemental report rectangular-matrix-support.json extends the
simulation-only mapping path from square toy matrices to rectangular neural
layer shapes.
The main Stage 2 demo remains small square, and supplemental rectangular support exists for 6x4, 4x6, and rank-deficient 5x3 cases.
The representation is:
W in R^(m x n)
-> compact SVD
-> full left/right orthogonal completion
-> rectangular Sigma transfer core
-> abstract square left/right mesh approximations
This is a numerical simulation convention. It uses padding through orthogonal completion and a zero-padded rectangular singular-value core. It is not a physical HRM layout, not a Clements/Reck interferometer layout, not a measured transfer matrix, and not a production phase synthesis pipeline.
There is still no physical complex/unitary mesh layout, still no Clements/Reck physical interferometer layout, still no foundry layout synthesis, and still no hardware validation.
The report includes tall, wide, and rank-deficient deterministic cases and keeps all hardware evidence flags false.
Stage 4 is synthetic/oracle calibration. It improves a simulated estimate against a target that is available inside the simulation.
Important Stage 4 flags:
calibrationUsesMeasuredData=false
calibrationUsesSyntheticTarget=true
oracleTargetAvailableInSimulation=true
hardwareCalibrationClaimed=false
measuredTransferMatrixAvailable=false
The supplemental Stage 4 calibration sweep report varies synthetic calibration parameters one at a time, including initial noise, learning rate, calibration iterations, and mesh phase levels. The companion analysis report summarizes best/worst cases, improvement ratios, convergence status, and failure cases. Both reports remain simulation-only and do not claim hardware calibration.
The supplemental Stage 3 sweep report evaluates one perturbation parameter at a time using fixed seeds. It covers phase quantization bits, phase-noise sigma, insertion loss, coupler imbalance, thermal drift proxy, and detector-noise placeholder values.
The sweep is still uncalibrated simulation. It does not change any hardware evidence flags and does not claim physical accuracy.
The companion Stage 3 sweep analysis report summarizes the sweep rows with per-parameter min/max error, max error delta, best/worst rows, sensitivity ranking, monotonicity notes, explicit limitations, and an all-perturbations-off control summary. The one-parameter sweeps keep the fixed baseline perturbation configuration enabled unless the swept parameter overrides one dimension, so zero-valued rows are not global no-perturbation controls.
The blocked stages are the boundary between simulation and hardware evidence.
- Stage 5 is blocked by
no_foundry_calibrated_device_model. - Stage 6 is blocked by
no_measured_hrm_transfer_matrix. - Stage 7 is blocked by
no_end_to_end_hardware_benchmark.
These blockers should remain until the required external artifacts exist.
Stage 5, Stage 6, and Stage 7 schema docs define required fields for future evidence packages. They are not evidence, do not contain foundry or measured data, and do not unblock any hardware gate.
Stage 5 gates validate foundry evidence class, relative artifact references, hashes, source date format, non-empty provenance, uncertainty, source, and claim-boundary fields.
Stage 6 and Stage 7 gates validate artifact references, hashes, date format, allowed matrix conventions, non-empty provenance fields, and the Stage 7 dependency on a completed Stage 6 measured-transfer-matrix gate.
This future-work track does not improve hardware readiness and does not claim hardware-native intelligence, autonomous cognition, quantum consciousness, power-free computation, quantum advantage, hardware validation, foundry calibration, measured transfer matrices, production inference readiness, or a completed hardware benchmark.
Completed alpha milestones:
v0.1.0-alpha.1: public simulation-gated baseline.v0.1.0-alpha.2: deterministic Stage 3 perturbation sweeps and sensitivity analysis.v0.1.0-alpha.3: deterministic Stage 4 synthetic calibration sweeps and analysis.v0.1.0-alpha.4: Stage 5/6/7 hardware evidence gate hardening.v0.1.0-alpha.5: rectangular matrix support snapshot.v0.1.0-alpha.6: complex/unitary factor simulation snapshot.v0.1.0-alpha.7: matrix-family benchmark suite.v0.1.0-alpha.8: multi-layer toy inference pipeline.v0.1.0-alpha.9: model-weight manifest import and eligibility analysis.v0.1.0-alpha.10: scaling and larger-layer benchmark suite.v0.1.0-alpha.11: simulation-only review pack and reviewer-facing metrics.v0.1.0-alpha.12: release-candidate hardening, report audit, claim-boundary guard, and v0.1.0 readiness reports.
Completed post-alpha.12 main work:
- model suitability profiling added for manifest components, mappable parameter share, classical components, unsupported components, heuristic suitability scoring, and planning recommendations.
- parametric hardware scenario estimates added with every latency and energy value labeled as a parametric estimate only.
- simulation-derived hardware requirement envelopes added for target error thresholds.
- simulation-only error budget added across mapping, perturbation, calibration, layer-stack, and scaling terms.
- calibration plan and transfer-matrix assimilation protocol added without measured transfer-matrix evidence.
- model-to-HRM decision report added for suitability, error, scenario, requirement, and missing-evidence review.
- v0.1.0-rc.1 readiness report and
docs/ROADMAP-v0.2.mdadded for release-candidate review.
Completed v0.2.0-alpha.1 main work:
- model portfolio benchmark and ranking added for five deterministic model fixtures.
- optional model-export adapter protocol added without a hard PyTorch dependency.
- design-space explorer added for phase bits, loss, noise, and calibration interval planning proxies.
- synthetic transfer-matrix ingestion sandbox added while keeping Stage 6 blocked.
hrmwtpCLI added for check, regenerate, summary, decision, and report-list workflows.- static dashboard added at
dashboard/index.html.
Completed v0.2.0-alpha.2 main work:
- CLI commands now print simulation-only disclaimers while preserving JSON stdout for
summaryanddecision. scripts/hrmwtp.pyadded as a repository-local CLI wrapper for reviewer smoke checks.- static dashboard expanded with what-this-is/what-this-is-not sections, report links, stage status, model portfolio summary, hardware gate blockers, and a claim-boundary box.
docs/QUICKSTART.mdanddocs/REVIEWER_GUIDE.mdadded for reproduction and review.
Completed v0.2.0-alpha.3 main work:
- partner readiness pack added for external review and partner discussion.
- lab, foundry, hardware-evidence, external-review, and reproducibility docs added.
- model cards and portfolio explainer added for deterministic model fixtures.
- CLI expanded with
portfolio,model-card, anddoctor. - dashboard expanded with model cards, error budget, scenario, requirements, transfer sandbox, partner readiness, and review checklist sections.
- solo completion audit and v0.2.0-alpha.3 readiness reports added.
Near-term:
- keep CI green for report generation, JSON validation, hashes, tests, local-path hygiene, and claim-boundary checks
- review
v0.2.0-alpha.3artifacts before broadening model fixtures - keep Stage 5, Stage 6, and Stage 7 blocked until real external evidence exists
- keep synthetic transfer-matrix sandbox outputs separate from public measured evidence
Later, only when evidence exists:
- supply real Stage 5 foundry-calibrated model artifacts
- connect Stage 6 to measured transfer-matrix artifacts
- connect Stage 7 to an end-to-end measured hardware benchmark
MIT.