Bridge Phase Continuity Runtime

Component replays synthetic

This component replays a synthetic record of a paused background job and checks the rules for safely resuming it, opening no live bridge and touching no private memory. bridge_phase_continuity_runtime is a public component that replays a small synthetic record of a paused background job and checks that the rules for safely resuming it hold. It reads fixture files on disk. It opens no live bridge, calls no provider, reads no operator screen state, and touches no private memory.

Run produces five

A run produces five plain result records for packet, heartbeat, pressure, resume, and completion, each carrying status fields, counts, and error codes but no copied body, live packet, or secret. A run produces five plain result records: one for the continuation packet, one for the heartbeat, one for resource pressure, one for the resume decision, and one for the completion transition. Each record carries status fields, counts, and error codes. None of them carries a copied body, a live packet, or a secret.

Component answers whether

The component answers whether a disk-first pause-and-resume handoff can be validated against fixed rules from public fixtures, where a pass means the fixture held, not that a real job is alive. The component answers one bounded question. Can a disk-first pause-and-resume handoff be represented by public fixture inputs, validated against a fixed set of rules, and kept below any live-bridge or launch-scope decision? A pass means the fixture held those rules. It does not mean a real job is alive.

Purpose

How loose resume stories overreach

Detached work is easy to describe and hard to trust, and conflating a liveness ping with resume permission, or a resume with finished work, is how bridge systems overreach. Detached background work is easy to describe and hard to trust. A running agent says it paused, left a note, and can resume. A loose version of that story lets a "still alive" ping stand in for permission to resume, or lets a successful resume stand in for finished work. Those are different claims, and conflating them is how bridge systems overreach.

Fixed continuity rules a cold reader can run

It makes the difference checkable with fixed rules a reader can run against fixtures: a paused job leaves a packet, double resume is refused, and only completion claims finished work. This component makes the difference checkable. It exists so a cold reader can run the continuity rules against fixture files instead of trusting a story about hidden agents. The rules are fixed. A paused job must leave a real continuation packet. Resuming the same job twice is refused. A heartbeat is liveness evidence and never resume authority. A stale heartbeat cannot pass itself off as proof of health. Only a proper completion record may claim the work finished.

How it works

run reads the fixture and six synthetic inputs

The run entry point resolves the session fixture and manifests, then reads six synthetic transport inputs, streaming the heartbeat so a malformed line becomes a finding, not an ingested body. The entry point is run. It takes an input directory and an output directory. It reads the session fixture observe_apply_session_fixture.json, pulls the fixture-manifest and source-module-manifest references out of it, and resolves both. From the manifest it reads six synthetic transport inputs through _read_synthetic_transport_inputs: detached_job.json, continuation_packet.json, heartbeat_rows.jsonl, resource_pressure.json, worker_skip_receipt.json, and private_state_forbidden_terms.json. The heartbeat file is JSON Lines, streamed by _read_required_jsonl, so a malformed line becomes a finding and never a reason to ingest a whole live heartbeat body.

The positive job's sign-off conditions

_validate_synthetic_transport_contract accepts the one positive job only when it yielded to disk with an unconsumed packet, a fresh heartbeat, and agreeing phase and continuity references across job, packet, and heartbeat. The core check is _validate_synthetic_transport_contract. It reads the job, packet, heartbeat, pressure, and worker-skip rows, then evaluates one positive job against a floor of negative perturbations. The positive job (synthetic_detached_job_001) passes only when its state is yielded_to_disk, its transport label is the accepted synthetic-transport label, its continuation packet targets the same job id, the packet's claim reference matches the job's, the packet is not yet consumed, at least one fresh heartbeat is present, and the phase id and continuity reference agree across job, packet, and heartbeat. Freshness is concrete. _heartbeat_is_fresh requires status alive and an age at or under 60 seconds. _heartbeat_is_stale treats status stale, or an age over 300 seconds, as stale.

Every declared bad case must be rejected

The same function turns each declared bad case into a specific error code, and a pass requires the fixture both to accept the good job and to observe the whole refusal floor. The same function checks that each declared bad case is actually rejected. A missing packet, a packet missing required fields, an already-consumed packet, a heartbeat that claims resume authority, a stale heartbeat that claims live health, a blocked resource-pressure decision, an invalid worker-skip record, and a private-class fixture that leaks bodies each turn into a specific error code. When a perturbation is present and correctly rejected, the run records the matching code. When the fixture fails to carry a perturbation, the run records a finding and blocks. A pass therefore means the fixture both accepted the one good job and observed the whole refusal floor. The declared cases live in the EXPECTED_NEGATIVE_CASES constant.

_validate_fixture_contract matches ids and digests

_validate_fixture_contract matches the envelope ids and recomputes each source-module SHA-256 so drift becomes BRIDGE_CONTINUITY_SOURCE_DIGEST_MISMATCH, then requires can_continue, closed_with_receipts, and a rollback that refuses writes after failure. _validate_fixture_contract checks the session envelope. The fixture's organ_id and its pattern_id (observe_runtime_apply_session) must match, the manifest ids must match, and the fixture's source-module references must equal the manifest's. For each listed source module it recomputes a SHA-256 digest and compares it to the recorded one, so a drifted copied body becomes BRIDGE_CONTINUITY_SOURCE_DIGEST_MISMATCH rather than silent trust. It then requires the status packet to report can_continue, the finalizer status to be closed_with_receipts, and the rollback case to refuse writes after a validation failure.

Forbidden-class scan and the tracked-write gate

Between the checks, run scans every path and strips excerpts through _safe_scan to report counts without text, then gates writes so a tracked path without the env flag reports tracked_receipt_writes_blocked. Between those two checks, run scans every input path with scan_paths against the forbidden-class policy and strips matched excerpts through _safe_scan, so the scan reports counts and status without carrying the offending text. Only then does it build the five result records and write them. Writes pass through a gate: when the target is a tracked path and MICROCOSM_TRACKED_RECEIPT_WRITES=1 is absent, the run reports tracked_receipt_writes_blocked instead of refreshing tracked evidence. run returns the completion-transition record.

flowchart TD Read["run reads fixture and six synthetic inputs"] --> Transport["_validate_synthetic_transport_contract"] Transport --> Good{"One valid job? yielded to disk, packet unconsumed, fresh heartbeat, phase and continuity agree"} Good -->|"yes"| Floor["Every declared bad case rejected as an error code"] Good -->|"no"| Block["Finding: valid job invalid"] Floor --> Fixture["_validate_fixture_contract ids, SHA-256 digests, continue/finalizer/rollback"] Fixture --> Scan["scan_paths and _safe_scan counts only, no excerpts"] Scan --> Gate{"Tracked path without MICROCOSM_TRACKED_RECEIPT_WRITES=1?"} Gate -->|"yes"| Skip["tracked_receipt_writes_blocked"] Gate -->|"no"| Write["Five result records written"]

Negative cases

Source-declared refusal floor mapped to codes

The refusal floor is source-declared in EXPECTED_NEGATIVE_CASES and validated against fixture contents, with each named case mapping to the error codes the run must observe. The refusal floor is source-declared in EXPECTED_NEGATIVE_CASES and validated against fixture contents. Each named case maps to the error codes the run must observe:

• missing_packet_duplicate_resume_and_resource_block: MISSING_CONTINUATION_PACKET, RESOURCE_PRESSURE_DISPATCH_BLOCKED, CONTINUATION_PACKET_ALREADY_CONSUMED
• continuation_packet_missing_required_fields: MISSING_CONTINUATION_PACKET_FIELDS
• heartbeat_claims_resume_authority: HEARTBEAT_NOT_RESUME_AUTHORITY
• bridge_packet_private_hud_body: BRIDGE_PACKET_PRIVATE_HUD_BODY
• stale_heartbeat_overclaims_liveness: STALE_HEARTBEAT_LIVENESS_CLAIM
• resume_success_overclaims_work_landed: RESUME_PASS_OVERCLAIMS_WORK_LANDED
• apply_validation_failure_rolls_back_observe_promotion: OBSERVE_APPLY_VALIDATION_FAILED

Prior Art Grounding

Durable-execution shapes without running them

The runtime borrows fixture-level shapes from Temporal, Airflow, Kubernetes leases, and W3C PROV without running any: a resumable handoff, a liveness lease that is not permission, and an inspectable provenance record. The runtime borrows shapes from durable execution and provenance work without running any of it. Temporal keeps workflow state resumable across process failure; Apache Airflow DAGs separate task ordering and retry policy from task internals; Kubernetes lease-based leader election treats a heartbeat as liveness evidence and not as work completion; and W3C PROV records how an output was produced. This component keeps only the fixture-level shape of those ideas: a resumable handoff, a liveness lease that is not permission, and a provenance record a reader can inspect.

Validation Result record Path

Run focused tests

Run the focused tests and the corpus check from the repository root without mutating durable records or generated projections. Run the focused tests and the corpus check from the repository root without mutating durable records or generated projections:

./repo-pytest --host-pressure-policy=warn tests/test_bridge_phase_continuity_runtime.py -q --basetemp=/tmp/microcosm_bridge_phase_continuity_runtime_pytest
./repo-python scripts/build_doctrine_projection.py --check-paper-module-corpus

To exercise the component directly against its fixture:

microcosm bridge-phase-continuity-runtime run --input fixtures/second_wave/bridge_phase_continuity_runtime/input --out /tmp/microcosm-bridge-continuity

What a passing run confirms

A pass confirms the fixture accepted the one good job, rejected every declared bad case, kept the non-public-state scan clean, and held the source-module digests. A pass means the fixture accepted the one good job, rejected every declared bad case, kept the non-public-state scan clean, and held the source-module digests.