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

# Observation Preservation R4: Source Admission and Ordered Record Retention

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

## Authorship, rights and editorial standing

Architecture and research direction: Aboudy Keddeh. Technical drafting, source inspection, synthesis and reproduction tooling: dot, powered by OpenAI. This is a new editorial edition; source-author acceptance, external peer review and release approval are not recorded. Original code and receipts remain unchanged.

© 2026 Aboudy Keddeh. Publisher: Keddeh Systems. Licence profile: KEDDEH-RESERVED-1.0. All rights reserved. No licence is granted by this document. Separate written permission governs reuse, redistribution and implementation, subject to applicable law. Third-party material retains its own rights. Copyright, code, patent and trademark permissions are separate.

## 1. Abstract and purpose

Observation Preservation R4 preserves an admitted observation's exact source text, SHA-256/UTF-8 byte identity and corresponding parsed envelope. It retains source order, repeated relations, explicit roles, missingness and separately reported projections through reconstruction. It does not evaluate a native relational operator or certify a physical measurement.

The retained 17 October 2026 browser receipt records 39 fixed vectors and 131 passing checks. A distinct review records 714 checks across core, VFS-binding and asynchronous snapshot suites. Those counts describe different methods; they are not one 845-check certification.

### Source coverage and new replay

The R4 HTML and its core, acceptance, schema, contract and host/runtime/child scripts were recovered from the published asset package. The carrier and registered script hashes match the previously inspected identities. The dated live-v219 review/receipt files are not included because their original raw files were not recovered for this package; their historical results remain attributed to the prior source review. This limitation is recorded in original_hashes.json.

A new isolated Node v24.19.0 replay on 18 October 2026 independently ran the exact recovered core and acceptance harness: 39 vectors, 131 checks, 131 passed, zero failed. The separate reproduction-result.json is new command-line evidence, not a recreation of the historical browser receipt.

## 2. Data model and dependencies

The source package contains the R4 core, acceptance harness, host, intermediate runtime, child handler, HTML carrier, envelope schema and fixed-vector contract. Historical browser receipt identities are documented separately; their raw files are not included. The pure entry point is `createObservationPreserver(schema)`. It returns a frozen object exposing preserve, restore and serialize. Callers supply the packaged observation-envelope.schema.json; the factory does not retrieve a schema itself.

The pure core needs JavaScript, TextEncoder and Web Crypto SHA-256. Node v24.19.0 supplies these for the retained isolated execution environment. Browser hosting additionally requires DOM APIs, sandboxed iframe srcdoc, postMessage, Blob/Object URLs, crypto.randomUUID and performance timing. A command-line replay cannot replace browser execution evidence.

A carrier has sourceText (string), sourceBytes (nonnegative safe integer) and sourceSHA256 (64 lowercase hexadecimal characters). UTF-8 length and digest are checked before JSON parsing. Malformed UTF-16 is rejected where String.isWellFormed is supported. Exact text remains retained when parsing changes a token's representation.

The envelope has fixed schema keddeh.source-ordered-observation-envelope.v1 and scope SOURCE_PRESERVATION_ONLY. Required fields are observationId, originDesignation, source, roles, context, orderedRelations and projection. The origin is exactly the string .1; it is never coerced to decimal 0.1, numeral 1 or a coordinate tuple.

Source revision, observed/observer/observable roles and spatial/temporal/instance-or-moment context slots are supplied or explicitly unspecified. A supplied slot has nonempty sourceText and optional value. An unspecified slot has a reason. Missingness does not mean numeric zero or nonexistence.

Supplied orderedRelations retains an originalExpression and nonempty roots. Each node has sourceLabel, sourceText and an ordered children array. Repetition and nesting are meaningful. Projection is either a reported finite conventional-numeric-token with unit/reference/method/resolution/uncertainty slots, unavailable, or unspecified. The latter states require reasons. A projection token is not a native origin or operative state.

## 3. API and lifecycle

### 3.1 preserve(carrier, prior = [])

The method captures the incoming carrier and prior records immediately, before any awaited digest. It then checks source identity, JSON and schema and reconstructs the prior state. Entry snapshots prevent later caller mutations from changing the admitted operation.

A new observation ID returns PRESERVED with sourceRecord, envelope, extended retainedRecords and no failedAttempts. The same ID and source digest returns IDEMPOTENT without appending a duplicate. The same ID with different exact source bytes returns CONFLICTING_OBSERVATION_ID, retaining the old state and the attempted conflicting record in failure custody. Whitespace-only changes count as different source bytes.

Rejections distinguish REJECTED_NONFINITE, REJECTED_SCHEMA, REJECTED_SOURCE_IDENTITY, REJECTED_JSON and REJECTED_RETAINED_RECORD. A rejected carrier retains successfully revalidated prior records where possible and records the failed attempt. Invalid previous state does not silently become valid. Nonfinite/unsupported outer values can fail before source-identity checks; valid byte identity precedes JSON/schema admission.

The returned record contains disposition, sourceRecord, envelope, retainedRecords and failedAttempts. It is caller-managed in-memory state. No file, database or durable store is written by preserve.

### 3.2 restore(prior)

Restore snapshots its input before asynchronous work. It accepts an array of wrapped retained records or source carriers and revalidates each source. A wrapped record must include an envelope exactly matching the parsed source according to opExact. The comparison preserves object-key sequence, array ordering and signed-zero distinctions.

Repeated retained IDs are rejected, whether duplicate or conflicting. Success returns entries and an IDs Map. Failure returns REJECTED_RETAINED_RECORD and a cause, including PARSED_ECHO_MISMATCH, DUPLICATE_RETAINED_ID or CONFLICTING_RETAINED_ID as applicable. The Map is an in-memory reconstruction index, not a JSON receipt.

### 3.3 serialize(value)

The custom serializer supports finite numbers, strings, booleans, null, dense arrays and plain/null-prototype records. It preserves key enumeration order and emits -0 for negative zero. It rejects nonfinite values, unsupported types, cycles, sparse arrays and non-record objects. It is not a general cross-language canonical-JSON specification.

SourceText remains the lexical authority. JavaScript parsing can round numbers or collapse duplicate JSON keys; exact spelling is retained in the source text, not necessarily reconstructed from parsed values. The schema evaluator implements the subset used here: local refs, oneOf, const and object/array/string/number checks. It is not a general JSON Schema 2020-12 implementation.

### 3.4 Browser execution lifecycle

The host verifies retained VFS files, creates a sandboxed runtime iframe and records a generation/token. READY and INIT exchange a nonce. The intermediate runtime verifies the application's byte count/digest before creating the application iframe. The child admits one INIT, executes checks and returns serialized results. Messages are checked against expected window, null sandbox origin, channel, token and generation.

The host checks receipt schema/collections, hashes receipt text and verifies exact displayed readback before exposing the export link. A 60-second deadline reports failure without claiming a new receipt. These are bounded execution/source-binding controls, not general hostile-code security certification or mathematical validation.

## 4. Setup and reproduction

Preserve source-files unchanged. Run `python verify_sources.py` from this edition folder to check byte custody. The pure replay uses `node reproduce.cjs`: it loads the core, acceptance-r4.js, schema and fixed-vector contract into a VM supplied only with their required computation facilities. Host, iframe, resident-tool and network paths are not evaluated by that harness.

For the retained R4 package the expected pure result is 39 vectors, 131 checks, 131 passed and zero failed. Execution timestamps/timings will differ; compare fixture identities, dispositions, failures and source digest rather than expecting complete receipt bytes to repeat. A newly generated result is a command-line replay, not the dated browser receipt.

The retained observation-preservation-r4.html can support a separate browser reproduction in an appropriately isolated browser. Activate reference execution, export the resulting receipt, and record actual browser version, source identity and new receipt digest. This editorial work does not operate that browser path or establish current live deployment status.

## 5. Results and meaningful failure cases

Main v219 was checked on 17 October 2026 at 14:50:21 UTC. The retained browser review reports 39 fixed vectors, 131 passed, zero failed and matching receipt readback. Its HTML digest is 8b2828865a896de14a4ae8b25d339c19fe70614baf478ea943525e33e5f15550. Its live receipt digest is 77b0b57300a9fd12aefd1e726074cead6f3f59156e67c9e9f1469242a673968b. These identify that dated run, not future responses at its URL.

The R4 core digest is 73bf6d0c32ebd7daae491999a8cca09a8677f1afe3e2294bc6207e233337964b. The exact packaged contract drives the 39 vectors; extra acceptance checks bring the total to 131.

Negative checks alter source bytes/count/hash, parsed observer, children, order, nesting, original expression and retained source/echo presence. Sparse children must be rejected. A newline added to the same observation ID is a retained conflict. Unsupported and nonfinite direct values produce diagnostic custody without admission. Source lexical -0 and the parsed negative-zero value survive the custom serialization path.

Snapshot checks mutate carrier scalars, failed-attempt inputs and prior state after invocation. The retained evidence records preservation of invocation-entry state. E-REVIEW separately uses controlled digest suspension, a 557-case schema mutation corpus and VFS binding checks. Its independent method does not repeat a browser run.

## 6. Limitations and cross-paper relationships

A checksum cannot establish authorship, authority, truth or native semantics. The core cannot determine whether supplied text accurately describes an observation, whether roles are truthful, or whether a relation satisfies the author's algebra. In-memory retention is not durable storage.

K-CURRENT provides present .1 and role interpretation. K-ORM supplies ordered attached relational groups. K-WP05 supplies observer/context modeling. The software preserves these as data without implementing a native numeric operator. K-BRAINK provides continuity/evidence concepts, but this mechanism is not asserted to be BRAINK's native execution engine.

The schema is an editorial preservation contract. Changes require a new version and new checks. Hostile getters/proxies, mutable shared schema objects, resource exhaustion and exhaustive cross-engine behavior are not qualified by the retained suite. No native quantum execution, physical result, three-body solution, speedup or external security audit follows from its pass count.

## 7. References and package contents

- E-PRESERVE: Observation-preservation runtime R4 and retained browser receipt, 17 October 2026. [Dated source location](https://www.keddeh.com/mainsequence/research-assets/observation-preservation-r4.html). Current deployment state has not been rechecked for this edition.
- E-REVIEW: Independent preservation software review R4, 672 core + 33 VFS + nine asynchronous checks. See the companion review edition for reproduction inputs and boundaries.
- Primary included files: preservation-core-r4.js, host.js, runtime.js and child-handler.js. Historical live-v219-review.json and live-v219-receipt.json are listed as unrecovered evidence.
- Supporting files: observation-preservation-r4.html, acceptance-r4.js, observation-envelope.schema.json and execution-contract-r1.json.
- Packaged hashes: original_hashes.json. Reproduction support is separate from unchanged originals.
- KEDDEH-STD-PUBLISHING-001 v1.0, [Publishing Standard](https://docs.google.com/document/d/1Tflo8AeqQyVNLHPnMyti615uILabTJ8KjbXKkGfSkRM/edit).

## 8. Revision history

18 October 2026 — Technical editorial E1. Added API, input/output, lifecycle, setup, reproduction and counterexample guidance to the retained evidence. Source-author acceptance and release approval are unrecorded.

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