Stage383 extends Stage382 by binding the existing Stage377 through Stage382 verification records to one deterministic recovery session.
It evaluates whether the complete recovery chain satisfies the requirements for formal-acceptance eligibility.
Stage383 does not issue formal acceptance and does not declare pipeline completion.
Stage383 adds the following public verification capabilities:
- A fixed recovery-orchestration contract
- A deterministic recovery-session identifier
- Stage377 through Stage382 input and hash binding
- Fixed-order downstream reverification requirements
- Detection of missing, mixed, skipped, stale, or tampered artifacts
- Formal-acceptance eligibility evaluation
- Separation of eligibility from certificate issuance
- Ten automated Fail-Closed tests
- A GitHub Actions verification workflow
- Public verification evidence under
docs/verification/stage383/
Stage377 dual-timestamp final acceptance | v Stage378 QKD safety metadata reverification | v Stage379 scoped total verification | v Stage380 deterministic offline verification | v Stage381 cross-platform reverification | v Stage382 policy-bound verification | v Stage383 formal-acceptance eligibility decision
The order is fixed.
Stage skipping, out-of-order execution, mixed workflow-run artifacts, and automatic formal-acceptance issuance are prohibited.
The current Stage377 result remains:
decision = rfc3161_verified_opentimestamps_pending verified_proof_count = 1 effective_final_acceptance = false
Therefore, Stage383 currently reports:
decision = upstream_finalization_pending verification_status = verified_pending_upstream recovery_phase = waiting_for_stage377 critical_failure_count = 0
Formal-acceptance boundary:
formal_acceptance_eligible = false formal_acceptance_issued = false formal_acceptance = false pipeline_completed = false public_release_allowed = false
This is an intended Fail-Closed waiting state.
Stage383 does not fabricate Stage377 completion and does not convert the pending OpenTimestamps proof into a verified proof.
Current recovery-session identifier:
stage383-66bce0a526782ef0e49221e70bcc939268f0d04e6e2e86e34aea9aed6caf5505
The identifier is derived from fixed verification inputs and excludes runtime timestamps, random values, usernames, hostnames, and absolute local paths.
The current local Stage383 validation reports:
Python syntax validation = passed Fail-Closed tests = 10 passed Stage383 verifier exit code = 0 critical_failure_count = 0 contract SHA-256 = valid result SHA-256 = valid manifest SHA-256 = valid public source/evidence hashes = identical
The public verification files are located at:
docs/verification/stage383/ ├── stage383_recovery_orchestration_contract.json ├── stage383_recovery_orchestration_contract.sha256 ├── stage383_formal_acceptance_eligibility_result.json ├── stage383_formal_acceptance_eligibility_result.sha256 ├── stage383_recovery_session_manifest.json └── stage383_recovery_session_manifest.sha256
The Stage383 GitHub Actions workflow is:
.github/workflows/stage383-policy-bound-recovery-orchestration.yml
Stage383 distinguishes between:
formal_acceptance_eligible
and:
formal_acceptance_issued
Eligibility does not equal issuance.
Even when every eligibility condition is eventually satisfied, Stage383 requires a separate manual or independently verified issuance transition.
Stage383 itself does not issue the final production certificate.
Stage383 does not replace, modify, or overwrite the established Stage377 through Stage382 verification records.
The complete Stage382 README and all inherited earlier documentation remain preserved below this Stage383 section.
The following directories must remain private and must not be pushed to GitHub:
core/ private_core/ private/ secrets/ keys/ imported/
Stage383 publishes no private key, secret, credential, token, raw QKD key, derived QKD secret, raw timestamp binary, private runner output, or confidential evidence.
Only reviewed public source code, verification metadata, SHA-256 records, results, manifests, and documentation may be published.
This project is licensed under the MIT License.
See the repository-level LICENSE file for the complete license text.
The MIT License does not override confidentiality requirements, publication boundaries, security controls, private-material restrictions, upstream evidence restrictions, or third-party licenses.
日本語：
Stage382 extends Stage381 by binding the unresolved Stage377 dual-timestamp final-acceptance requirements to a fixed, versioned policy profile.
Stage382 preserves Stage377, Stage378, Stage379, Stage380, and Stage381. It does not replace or overwrite their verification records.
Stage382 adds:
- A versioned dual-timestamp final-acceptance policy
- SHA-256 binding of the policy profile
- Stage377 completion-state observation
- Mandatory Stage378 reverification after Stage377 completion
- Mandatory Stage379, Stage380, and Stage381 reverification
- Fail-Closed handling of policy and publication-boundary violations
- A policy-activation manifest binding Stage377 through Stage381
Stage377 dual-timestamp final acceptance
|
v
Stage378 QKD safety metadata rebinding
|
v
Stage379 scoped total verification
|
v
Stage380 deterministic offline verification
|
v
Stage381 cross-platform reverification
|
v
Stage382 policy-bound verification
Stage377 decision:
rfc3161_verified_opentimestamps_pending
Stage377 verified proof count:
1
Stage377 effective final acceptance:
false
Stage378 ready:
false
Stage382 decision:
policy_bound_final_acceptance_pending
Stage382 verification status:
verified_pending_upstream
Critical failure count:
0
This is the intended Fail-Closed waiting state.
Stage382 does not generate a replacement OpenTimestamps proof and does not weaken the requirement for two independently verified timestamp proofs.
Profile:
qsp-dual-timestamp-final-acceptance-v1
Profile version:
1.0.0
Policy SHA-256:
1819dc41cee56da7f7faabdbdc6dab44326054c9197bf5bd6c52286b7e8e9ea5
The policy requires:
- RFC3161 verification
- OpenTimestamps verification
verified_proof_count == 2effective_final_acceptance == true- Stage378 QKD metadata rebinding
- Stage379 scoped reverification
- Stage380 deterministic offline reverification
- Stage381 Ubuntu, Windows, and macOS reverification
- no automatic formal-acceptance upgrade
- no publication of private or secret material
Stage382 remains development-only.
formal_acceptance = false
pipeline_completed = false
public_release_allowed = false
A valid policy-integrity check is not equivalent to production formal acceptance.
The following directories must remain private:
core/
private_core/
private/
secrets/
keys/
imported/
Stage382 does not publish private keys, credentials, authentication tokens, raw QKD secret material, raw timestamp proof binaries, or private-core material.
Public Stage382 evidence is available under:
docs/verification/stage382/
It includes:
- the versioned policy profile
- the policy SHA-256 record
- the upstream-finalization result
- the result SHA-256 record
- the policy-activation manifest
- the manifest SHA-256 record
This repository is licensed under the MIT License.
See the repository-level LICENSE file for the complete license text.
The existing Stage381 documentation and inherited Stage380 foundation remain preserved below. Preserved Stage381 Foundation
The existing Stage381 documentation and inherited Stage380 foundation remain preserved below.
Stage381 extends Stage380 with a cross-platform deterministic reverification and reproducibility gate.
It verifies whether the same fixed verification input produces the same material result on:
- Ubuntu
- Windows
- macOS
Stage381 does not replace, rewrite, or upgrade the Stage380 verification scope. It preserves the Stage380 independent offline verification package and adds a fail-closed cross-platform comparison layer.
Stage381 adds the following public verification components:
- A fixed canonicalization profile
- Deterministic environment-result generation
- Ubuntu, Windows, and macOS verification through GitHub Actions
- Cross-platform comparison of required result fields
- A Stage381 verification-package contract
- SHA-256 binding of the contract and verification records
- A final fail-closed package verifier
- Downloadable GitHub Actions verification artifacts
Stage380 independent offline verification package
|
v
Fixed Stage381 canonicalization rules
|
v
Ubuntu / Windows / macOS execution
|
v
Deterministic environment results
|
v
Cross-platform field comparison
|
v
Stage381 final package verification
Stage381 requires all three configured platforms to be present.
The comparison must confirm:
- the same fixed verification input was used
- the same decision was produced
- the same verification status was produced
- the same package-integrity result was produced
- the same critical-failure count was produced
- the same process exit code was produced
- the same Stage380 result SHA-256 was bound
- the same canonical result SHA-256 was produced
If a required platform result is missing, malformed, inconsistent, or not bound to the required Stage380 input, Stage381 remains fail-closed.
A local machine can validate the Stage381 package structure with:
python3 development/stage381/verify_stage381_cross_platform_package.pyA single local machine verifies only the result available on that machine.
Formal cross-platform verification requires Ubuntu, Windows, and macOS results. The included GitHub Actions workflow provides those environments without requiring the operator to own three separate computers.
The workflow is:
.github/workflows/stage381-cross-platform-reverification.yml
It performs:
- Deterministic verification on Ubuntu
- Deterministic verification on Windows
- Deterministic verification on macOS
- Artifact collection
- Cross-platform comparison
- Stage381 contract validation
- Final package verification
- Verification-package artifact upload
This project is released under the MIT License.
See the LICENSE file included in this repository for the complete license
text.
Stage381 publishes only the files required for deterministic verification and audit.
The following material must remain outside the public repository:
core/private_core/private/secrets/keys/imported/- private keys
- credentials
- unpublished raw evidence
- confidential execution material
Stage381 does not publish attack code, harmful payloads, secret keys, or private-core implementation material.
A fail-closed result does not automatically mean that the verifier malfunctioned.
Before all three operating-system results exist, Stage381 must report that cross-platform reverification is not verified.
Stage381 may report successful cross-platform reproducibility only after all required platform records exist and all required comparison fields match.
The Stage381 implementation and GitHub Actions workflow are present.
Formal Stage381 cross-platform completion requires a successful GitHub Actions execution with matching Ubuntu, Windows, and macOS results.
Until that execution succeeds, cross-platform reverification must remain unverified.
The following Stage380 documentation is retained because Stage381 extends rather than replaces the Stage380 independent offline verification package. Stage380 extends Stage379 by packaging the established verification scope into a deterministic offline verification contract.
Stage380 does not replace or rewrite Stage379. It preserves the Stage379 development snapshot and verifies the package from an independent, offline, fail-closed perspective.
Stage380 adds two core capabilities:
- Independent Verification Package Contract
- Deterministic Offline Core Verifier
The purpose is to make the Stage379 verification package independently reproducible without network access and without changing the established verification scope.
Stage380 is currently development-only.
The current decision is:
development_package_verified_upstream_pending
Current verified state:
- package integrity verified:
true - formal independent verification:
false - formal acceptance:
false - pipeline completed:
false - public release allowed:
false - critical failure count:
0
Formal independent verification remains pending because the upstream formal acceptance conditions are not yet complete.
Stage380 depends on the established Stage377, Stage378, and Stage379 results.
Required formal conditions include:
verified_proof_count == 2effective_final_acceptance == true
qkd_metadata_bound == true- Stage377 result hash valid
- Stage378 hash chain valid
- QKD publication boundary valid
- QKD evidence classification complete
formal_acceptance == truepipeline_completed == truecritical_integrity_valid == true
Until these conditions are satisfied, Stage380 must remain development-only and fail closed against any formal acceptance claim.
The Stage380 contract is:
development/stage380/stage380_independent_verification_package_contract.json
The contract defines:
- source stage
- source snapshot manifest
- required input files
- deterministic offline execution
- package locking
- scope-reduction prohibition
- fail-closed behavior
- development-only state
- formal acceptance prohibition
The contract is fixed by:
development/stage380/stage380_independent_verification_package_contract.sha256
Verification command:
shasum -a 256 -c development/stage380/stage380_independent_verification_package_contract.sha256The Stage380 verifier is:
development/stage380/verify_stage380_independent_package.py
The verifier performs the following checks:
Stage380 contract presence Stage380 contract SHA-256 verification SHA-256 record path verification contract policy validation required input presence checks required input SHA-256 calculation Stage379 snapshot manifest verification Stage379 snapshot artifact hash verification Stage379 snapshot artifact size verification duplicate artifact-path detection Stage377 state observation Stage378 state observation Stage379 state observation Stage379 critical-integrity validation Stage379 development certificate validation formal-acceptance readiness evaluation fail-closed decision generation deterministic result generation
Run the verifier with:
python3 development/stage380/verify_stage380_independent_package.py
Expected current decision:
decision=development_package_verified_upstream_pending package_integrity_verified=true formal_independent_verification=false critical_failure_count=0
Stage380 is designed so that the same input produces the same output.
The result intentionally excludes:
runtime timestamps random values hostnames usernames absolute local paths network-derived values
Deterministic verification can be checked with:
FIRST_HASH=$(shasum -a 256 development/stage380/stage380_independent_verification_result.json | awk '{print
Stage380 must return fail_closed when a critical verification requirement fails.
Examples include:
missing Stage380 contract invalid contract JSON contract SHA-256 mismatch invalid SHA-256 record path missing required input missing Stage379 snapshot manifest Stage379 snapshot artifact missing Stage379 snapshot artifact hash mismatch Stage379 snapshot artifact size mismatch duplicate snapshot artifact path invalid Stage379 critical integrity invalid development certificate type contract policy mismatch scope reduction enabled offline mode disabled package lock disabled
Stage380 does not convert missing, unknown, pending, or invalid evidence into verified evidence.
The deterministic verification result is:
development/stage380/stage380_independent_verification_result.json
It contains:
decision verification status package-integrity status formal-verification status upstream state contract SHA-256 snapshot SHA-256 required-input SHA-256 values verification checks critical failures deterministic result SHA-256
The external result hash record is:
development/stage380/stage380_independent_verification_result.sha256
Verification command:
shasum -a 256 -c development/stage380/stage380_independent_verification_result.sha256
The Stage380 manifest is:
development/stage380/stage380_independent_verification_manifest.json
The manifest records:
development policy verification contract deterministic verifier verification result verification certificate actual SHA-256 values actual file sizes artifact count
The manifest is fixed by:
development/stage380/stage380_independent_verification_manifest.sha256
Verification command:
shasum -a 256 -c development/stage380/stage380_independent_verification_manifest.sha256
The Stage380 development certificate is:
development/stage380/stage380_independent_verification_certificate.json
Certificate type:
development_independent_verification_certificate
The certificate does not claim formal independent verification.
It records that:
deterministic offline package verification completed package integrity was verified formal independent verification remains pending upstream formal acceptance remains incomplete pipeline completion is not claimed
The certificate is fixed by:
development/stage380/stage380_independent_verification_certificate.sha256
Verification command:
shasum -a 256 -c development/stage380/stage380_independent_verification_certificate.sha256
Stage380 preserves and consumes the Stage379 development package.
Primary Stage379 inputs include:
development/stage379/stage379_development_snapshot_manifest.json development/stage379/stage379_development_acceptance_certificate.json development/stage379/stage379_scoped_total_verification_result.json development/stage379/stage379_verification_scope_policy.json
Stage380 does not modify these Stage379 records.
The previous root README is preserved at:
development/stage380/README.stage377-preserved.md
Stage380 preserves the existing Git exclusion rules.
The following directories must remain private and must not be pushed to GitHub:
core/ private_core/ private/ secrets/ keys/ imported/
Stage380 must not publish:
private keys secret seeds access tokens OIDC tokens GitHub tokens raw QKD key material private runner output unrestricted external command input raw confidential evidence
Only reviewed metadata and approved public evidence may be placed under docs/.
The Stage380 verifier requires no network access.
It does not:
contact timestamp authorities contact blockchain nodes contact Sigstore or Rekor download GitHub Actions artifacts fetch external evidence execute user-supplied shell commands generate or expose secret material
Stage380 verifies the locally available package as provided.
development/stage380/ ├── README.stage377-preserved.md ├── stage380_independent_verification_package_contract.json ├── stage380_independent_verification_package_contract.sha256 ├── verify_stage380_independent_package.py ├── stage380_independent_verification_result.json ├── stage380_independent_verification_result.sha256 ├── stage380_independent_verification_manifest.json ├── stage380_independent_verification_manifest.sha256 ├── stage380_independent_verification_certificate.json └── stage380_independent_verification_certificate.sha256
Root development policy:
.stage380-development-policy.json
Recommended verification sequence:
python3 -m json.tool .stage380-development-policy.json >/dev/null
python3 -m json.tool
development/stage380/stage380_independent_verification_package_contract.json \
/dev/null
shasum -a 256 -c
development/stage380/stage380_independent_verification_package_contract.sha256
python3 -m py_compile
development/stage380/verify_stage380_independent_package.py
python3
development/stage380/verify_stage380_independent_package.py
shasum -a 256 -c
development/stage380/stage380_independent_verification_result.sha256
python3 -m json.tool
development/stage380/stage380_independent_verification_manifest.json \
/dev/null
shasum -a 256 -c
development/stage380/stage380_independent_verification_manifest.sha256
python3 -m json.tool
development/stage380/stage380_independent_verification_certificate.json \
/dev/null
shasum -a 256 -c
development/stage380/stage380_independent_verification_certificate.sha256
development_package_verified_upstream_pending
The Stage380 package is internally valid, but upstream formal acceptance conditions remain incomplete.
independent_verification_package_ready
The Stage380 package is internally valid and all required upstream formal acceptance conditions are satisfied.
This decision must not be emitted unless the actual Stage377, Stage378, and Stage379 records satisfy the contract.
fail_closed
One or more critical integrity, policy, hash, file, snapshot, or certificate checks failed.
Stage380 provides the following development-stage properties:
deterministic local verification offline operation package integrity validation artifact hash validation artifact size validation duplicate-path detection upstream-state observation fail-closed decisions scope-lock enforcement scope-reduction prohibition private-boundary preservation no formal claim while upstream is pending
Stage380 does not prove that an external organization or independent third party has executed the verifier.
That requires an actual independent execution environment and independently retained evidence.
Current limitations include:
Stage377 has not yet reached dual verified timestamp acceptance Stage378 QKD metadata binding remains pending Stage379 formal acceptance remains pending Stage380 remains development-only no third-party execution claim is made no production-readiness claim is made no pipeline-completion claim is made
These limitations are intentionally represented rather than hidden.
This project is licensed under the MIT License.
See:
LICENSE
The MIT License applies to the published source code and documentation in this repository. It does not override restrictions, confidentiality requirements, third-party licenses, or security controls applicable to private material or external evidence.