Return to the full study

KEDDEH SYSTEMS · E-REVIEW · Technical editorial E1

KEDDEH SYSTEMS | RESEARCH AND FORMAL PUBLISHING | ENGINEER · AUTOMATE · SCALE

Observation Preservation R4: Independent Software Review and Reproduction Guide

KEDDEH-TECH-E-REVIEW-001 | Technical editorial E1 | 18 October 2026
Aboudy Keddeh — Systems Architect
Keddeh Systems | Internal research · Owner review | Editorial draft

Authorship, rights and review standing

1. Abstract and decision

The historical R4 preservation review reports 714 passing checks: 672 core checks, 33 VFS/source-binding checks and nine controlled asynchronous-snapshot checks. Its scope is exact-source retention, schema admission, ordered-role/relation custody, serialized reconstruction, source binding and mutation-race behavior.

The result supports the stated preservation implementation on the frozen corpus. It does not validate a native mathematical operator, physical observation, production deployment or general security boundary. The historical 39-vector/131-check browser run is a distinct reported observation, described by E-PRESERVE. This review inspected browser receipt identities; it did not independently operate a browser.

Source coverage and new review

The historical core-review-r4.json, vfs-review-r4.json and async-snapshot-r4.json raw files, original review harnesses and 557-case mutation corpus were not recovered for inclusion in this edition. Their 714-check result is a previously inspected historical result, not a newly verified 714-check run. Expected receipt identities remain listed as unrecovered evidence; none was reconstructed to look like an original.

The exact R4 application, core, acceptance, schema, fixed contract and host/runtime/child sources are included with verified identities. A new editorial harness, reproduce-review.cjs, separately records 121 passing checks: 84 fixed-vector/core properties, 28 static VFS/CSP bindings and nine controlled snapshot cases. It does not include the missing 557-case mutation corpus and does not operate a browser.

2. Reviewed objects and dependencies

The shared reviewed core has SHA-256 73bf6d0c32ebd7daae491999a8cca09a8677f1afe3e2294bc6207e233337964b. The HTML application/carrier digest is 8b2828865a896de14a4ae8b25d339c19fe70614baf478ea943525e33e5f15550. The fixed contract digest is 1aca04d2691a7d45a06cde11047736569cd90b03ebcd658d22859a1acef10ea1. The schema mutation fixture digest is 8a2ffea2353fb88cb01cf6c74fc4edb55dbc571e8d486f0253e25fbd3d03684b.

The historical core-review-r4.json was an identity authority for that review, but its raw file is not available in this package. The current original_hashes.json identifies the included recovered sources and separately lists unrecovered historical evidence. Verify the included source digests before running the new replay.

A full historical reproduction would need the core, schema, fixed contract, 557 schema mutations, R4 HTML, build export/receipt, browser review/receipt, acceptance harness, host, intermediate runtime and child handler. The historical harness names are verify-core-final.cjs, verify-vfs-final.py and verify-async-snapshot.cjs. Their interfaces were inspected, but the raw harness files and mutation corpus are not included in this package.

Core and async harnesses use Node built-ins fs, vm, crypto and assert as applicable. The VFS harness uses Python and lxml.html, plus standard-library json, hashlib and base64. A reproduction must record Node/Python/lxml versions. The original Node source takes a revision argument; use r4 explicitly because its default points to an earlier revision.

3. Review contracts and procedure

This section describes the previously inspected historical review method. The current 121-check harness covers only the fixed-vector/core properties, static source bindings and controlled snapshot cases identified in Section 1; it does not recreate the missing historical inputs.

3.1 Core admission and reconstruction review

The core harness evaluates preservation-core-r4.js in a VM supplied with TextEncoder and Web Crypto. Fixture values are cloned into that VM's realm so plain-record prototype checks are meaningful. It does not execute the browser host.

For each fixed vector it checks the expected disposition. Accepted vectors additionally check exact retained carrier, parsed envelope and a new engine's idempotent reconstruction from serialized retained state. It then runs the 557-case schema mutation corpus against expected dispositions.

Adversarial retained-state checks alter source bytes, digest, length, source/echo presence, observed/observer/observable roles, root order, child order, repetition, nesting and original expression. Duplicate retained ledger entries must fail. A whitespace change under the same ID must retain the old state plus the failed attempted source. Distinct observation identities with equal numeric projections must remain distinct records.

Direct NaN, infinities, undefined, bigint, functions and symbols are rejected with serializable diagnostic custody. Signed-zero testing checks both exact source text and the parsed negative-zero value after custom serialization. These checks test the implemented source-preservation contract, not mathematical truth of supplied values.

3.2 VFS and browser-evidence binding review

The Python review parses retained HTML as data. It verifies equality with the build export, carrier byte count/hash, the six-file VFS set and each embedded file's byte pins. It checks that embedded schema and fixed contract match the supplied documents and that executed-script text matches reviewed core, acceptance, host, runtime and child-handler files.

It also checks inline script/style SHA-256 declarations in the content-security policy and the presence of default-src 'none', connect-src 'none', object-src 'none', form-action 'none' and base-uri 'none', with no unsafe-inline or unsafe-eval. These are static checks of the retained policy, not a comprehensive browser security audit.

Finally it binds the retained browser receipt to its review hash, verifies reported pass counts and source identities, and preserves the stated scope. The reviewer consumed evidence supplied by the execution workflow. It did not independently generate the browser result.

3.3 Controlled asynchronous snapshot review

The async harness replaces Web Crypto digest with a controlled queue. It starts preserve or restore, mutates caller-owned inputs while the digest is pending, then deliberately drains the queue. This exercises the exact await boundary rather than relying on an uncontrolled race being scheduled.

Nine checks establish that admitted source scalars, rejected-attempt diagnostics, prior-list entries, prior-envelope echoes and public restore inputs reflect invocation-entry state. Three retained-child cases distinguish sparse arrays from explicit null and undefined, all of which must be rejected as altered retained records.

The harness bounds its queue drain and raises an unsettled-fixture error if completion does not occur. That harness behavior is not a runtime durability guarantee.

4. Reproduction setup and commands

For the available new review, run python verify_sources.py and then node reproduce-review.cjs in the edition folder. This reproduces the separately recorded 121-check suite. Keep source-files immutable.

The historical procedures used verify-core-final.cjs, verify-vfs-final.py and verify-async-snapshot.cjs with the explicit revision argument r4. Repeating those procedures requires recovery of the original harnesses, mutation corpus, build receipts and browser evidence, together with their documented input layout. They are not executable from the currently supplied package.

If recovered, run the historical harnesses in a disposable reproduction layout, never over the evidence originals. Compare the core digest, check totals, passed counts and failure arrays with the recovered historical reports. Fresh receipts are new evidence; they do not replace dated originals. If dependencies or exact input files are unavailable, report reproduction as pending rather than synthesizing equivalent-looking fixtures.

The VFS report reads browser receipts; running it does not create a new browser receipt. A fresh browser reproduction requires the separate E-PRESERVE procedure and its own environment and receipt record.

5. Recorded results

The previously inspected historical core-review-r4.json reports 39 fixed vectors, 557 schema mutations, 672 checks, 672 passed and an empty failures array. The 672 denominator includes multiple properties per accepted fixed vector and extra adversarial checks; it is not 672 separate observation records.

The previously inspected historical vfs-review-r4.json reports 33 checks, 33 passed and no failures. Its receipt digest is 76058bba0096a8365c623f9040f7d2edf5da424b3c2a098b3796f03efed29e47. This is the browser receipt used in that review, distinct from the later live v219 receipt digest in E-PRESERVE. Matching application source does not require distinct runs' receipts to be byte-identical.

The previously inspected historical async-snapshot-r4.json reports nine checks, nine passed and no failures. Successful preserve cases return PRESERVED or preserve the expected entries; successful restore cases have no error. The three altered-child cases return REJECTED_RETAINED_RECORD.

Total historically reported software-review checks are 672 + 33 + 9 = 714. Counts are kept per suite to preserve meaning. No count is imported from another implementation or promoted into a physical or native-algebra validation claim.

Editorial harness correction record

The first new harness run produced eleven harness-side false negatives: two checks inadvertently converted -0 through JSON.stringify, and nine static checks compared HTML-encoded CSP entities without decoding them. The new harness was corrected to parse the exact serialized source in the VM and decode the policy attribute. The unchanged runtime then passed 121/121. The initial result is retained separately as reproduction-review-initial-harness-result.json; no source code was altered and no runtime failure was silently dropped.

6. Limitations and useful counterexamples

A structurally valid but false observation can pass this preservation contract. So can a source record containing an ordered expression whose native semantics are unknown. These are outside the tested oracle, not hidden successes.

A changed parsed echo with unchanged exact source must fail reconstruction. A duplicate retained ID must fail even if its carrier digest matches; replay through preserve is the supported idempotent path. An incoming source with matching semantic JSON but different whitespace must conflict when it reuses an ID. These cases illustrate why exact identity and parsed interpretation are separately retained.

Passing a finite mutation corpus does not prove all inputs safe. Hostile getters/proxies, mutable schemas, memory exhaustion, denial-of-service, exhaustive browser engines and all Unicode edge behavior remain outside the stated qualification. Static CSP inspection does not establish that arbitrary host code is safe. No external peer reviewer or certification authority is identified.

Cross-paper implications are narrow: K-CURRENT, K-ORM and K-WP05 motivate preserving roles, order and context; K-BRAINK motivates evidence/continuity separation. This review verifies neither the full observation map nor BRAINK's native lifecycle. E-LINE/E-QUANTUM concern different mechanisms.

7. References and package plan

• E-REVIEW: Separate observation-preservation software review R4, 17 October 2026. Historical primary reports: core-review-r4.json, vfs-review-r4.json and async-snapshot-r4.json; their raw files are not included.
• E-PRESERVE: R4 source and dated browser receipt. Retained source location.
• Included sources, the new reproduction harness and unavailable historical inputs are distinguished in original_hashes.json and package-plan.json. Recovered original harnesses, source code and receipts must remain byte-exact; editorial scripts live outside source-files.
• KEDDEH-STD-PUBLISHING-001 v1.0, Publishing Standard.

8. Revision history

18 October 2026 — Technical editorial E1. Developed the historical review account and recovered sources into a reproducible methodological account, with denominator definitions, dependencies, negative paths and explicit separation from browser execution and native mathematics. No approval is implied.

© 2026 Aboudy Keddeh | Keddeh Systems | All rights reserved
KEDDEH-TECH-E-REVIEW-001 | Technical editorial E1 | Internal research · Owner review | Editorial draft