Virtual Fiber Internet Proof

Objective

Test the narrow prerequisite beneath Virtual Fiber: whether an Internet-originated object completes faster when a phone reconstructs one coded generation from both a paced ordinary HTTPS stream and valid display-to-camera repair symbols.

This contract does not authorize a claim that ordinary phone cameras equal fiber, that every application becomes faster, or that shared upstream bottlenecks can be multiplied.

Primary comparison

Run the same deterministic session object under two conditions:

1. Direct baseline — paced systematic symbols over HTTPS only.
2. Hybrid camera — the same paced HTTPS stream plus repair symbols requested by a desktop gateway and physically observed by the phone camera.

Use the same phone, relay deployment, payload dimensions, direct pacing, browser version, and session protocol version. Run the direct baseline before the hybrid condition unless the receipt records a counterbalanced order.

Required positive observations

A candidate VERIFIED_MECHANISM run requires all of the following:

• both conditions reconstruct the same relay SHA-256;
• the hybrid condition incorporates at least one innovative optical symbol;
• hybrid completion time is lower than direct-only completion time;
• optical loss does not freeze or corrupt the direct lane;
• direct and optical symbol counts are reported separately;
• invalid, duplicated, wrong-session, and CRC-failed frames do not increase generation rank;
• direct pacing and optical carrier rate are disclosed;
• and all raw receipts and environment notes are preserved.

Independent-backhaul subtest

For the strongest Internet aggregation demonstration:

• the phone uses cellular service with Wi-Fi disabled;
• the desktop emitter uses Ethernet or a non-tethered broadband connection;
• the two salted path fingerprints differ;
• and the receipt records that the routes were independently available during the test.

Matching fingerprints do not invalidate the optical transport test. They invalidate only the claim that the run demonstrated distinct public egress paths.

Metrics

Report separately:

• payload_bytes;
• direct_interval_ms;
• carrier_frames_per_second;
• baseline_completion_ms;
• hybrid_completion_ms;
• speedup_ratio;
• uplift_percent;
• baseline_direct_innovative_symbols;
• hybrid_direct_innovative_symbols;
• hybrid_optical_innovative_symbols;
• valid_direct_frames_observed;
• valid_optical_frames_observed;
• crc_or_session_rejections;
• direct_path_fingerprint;
• optical_path_fingerprint;
• distinct_public_egress_observed;
• payload_sha256_match;
• camera_decode_cpu_or_energy_notes;
• and optical_occlusion_recovery.

Do not collapse these into one performance score.

Required repetitions

A first public founder-local proof may be reviewed from one complete recorded pair. Any general speed claim requires at least ten paired runs under a pinned environment, with median, dispersion, failures, and all row-level receipts retained.

Invalid-run conditions

A run is invalid when:

• direct and hybrid conditions use different payloads or protocol versions;
• the digital loopback mode is represented as physical optical evidence;
• the phone receives optical repair frames through an ordinary fetch rather than its camera;
• the relay SHA-256 is absent or mismatched;
• the direct baseline pacing differs without disclosure;
• optical symbols are counted from rendered frames rather than innovative decoded rank;
• raw path addresses are published;
• a shared public egress is described as independent backhaul;
• or the result omits failures, interruptions, or manual intervention.

Falsification and reduction criteria

Reduce or reject the commodity-device product claim when:

• the camera cannot contribute stable innovative rank outside a contrived alignment;
• optical decoding overhead removes the completion benefit;
• the hybrid condition is not faster under matched pacing;
• accepted frames frequently reconstruct incorrect bytes;
• optical occlusion causes head-of-line blocking;
• or existing radio bonding provides the same target value with materially lower complexity.

A negative run remains part of the public experiment ledger.

Receipt review

A downloaded app receipt begins at AWAITING_HUMAN_REVIEW. Promotion requires:

• the exact Glyphd Labs commit and deployment;
• the JSON receipt;
• a screen recording showing both devices and the completed comparison;
• phone, desktop, browser, display, camera, carrier rate, and connectivity details;
• invalid-condition checks;
• and explicit limitations.