Experimental technical branch · v0
Research continuity,
tested offline.
A small Python prototype asks whether explicit events can preserve research status, negative findings and corrections across a handoff. Its cases are synthetic. The checks concern software behavior; they do not establish source truth or improved collaboration.
Milestone v0 · September 30, 2026
36 test methods passed. Ten regression scenarios are checked at 24 checkpoints with 57 assertions per representation. The event ledger, a carefully maintained status file and a carefully maintained handoff summary each pass 10 of 10 scenarios. All receive the same source histories, identifiers, timestamps, corrections and uncertainty.
This equality matters: plain records can preserve these distinctions. The ledger adds automatic validation, deterministic replay and review marking for declared dependencies. It also adds schemas, timestamp rules, correction rules and implementation complexity. Human time, maintenance error rates and model performance were not measured.
Read the captured check output and checkpoint comparison. This milestone records executed local software checks, not a production or integration claim.
Separate claims and actions
Observations, interpretations, decisions, executions and verifications have different event kinds. Drafted does not mean submitted; accepted does not mean paid; duplicate standing does not settle technical validity. A closed case does not establish available submission slots. A plan does not record execution.
Carry corrections forward
Append-only correction events retain the old claim, cite a replacement and mark every declared transitive dependent for review. A later correction to the replacement cannot silently restore an old packet. A stale observation or failed read retains its history and does not claim current status.
Keep negatives and answers
Negative findings retain sufficient grounds and an explicit reopening condition. Reconsideration requires fresh, materially changed premises; repeated values and unrelated changes do not qualify. Repeating an answered request preserves the recorded response unless its declared premises materially change. Missing or stale evidence prompts review.
Reproduce the checks
Download and unzip the source package. On Python 3.10 or later on a POSIX host, run python3 -B run_checks.py. No dependencies, network access, private reports or model calls are needed. Use --out my-new-checks to inspect generated logs, baseline records and compact status, negative and unresolved-action views.
Visible limits and a simpler alternative.
Actor labels are unauthenticated claims: a model-authored “human” label does not verify identity or approval. Hashes identify canonical content, not truth. Application append-only behavior is not tamper-proof storage; a filesystem writer can rewrite and reseal a log or remove its suffix. Declared dependencies cannot reveal omitted premises.
The prototype assumes comparable UTC timestamps and author-declared observation windows. It supports one small local log per case set, limited to 1,000 events and 2 MB. Correction retractions and cross-case dependencies are unsupported. It does not extract claims from private reports, establish authority or execute external actions.
Simple status files and handoffs remain appropriate when cases are few, a maintainer can review updates and dependencies are shallow. Whether automatic replay and review marking justify the added structure needs evaluation in a real workflow. “We don’t know what better means” remains an open question; these local checks do not settle the wider inquiry.
No independent review, adoption, partnership or new reuse rights are claimed. Future milestone updates should identify executed checks, changed assumptions and remaining limits, preserving this result rather than presenting progress as a guarantee.
Continue the inquiry.
Return to the research overview, read the founding essay, or develop a question with the reflection worksheet. This technical branch is one contribution to HayosoAi, with its own scope.