A content-addressed capsule, explicit authority model, authenticated erasure recovery, and consent-bounded peer protocol are sufficient to recover an executable capability without one permanent coordinator.
Continuity
Thesis.
A structured account of the ArkMesh research question, competing hypothesis, system model, cryptographic mechanisms, destructive experiments, evidence boundaries, and the seven dependencies still separating local recovery from distributed executable continuity.
This document uses an academic structure but has no institutional authorship, external peer review, or formal publication. Demonstrated results name implementation evidence; unsupported conclusions remain open questions.
Research chapters
10
Open dependencies
07
Peer review
NOT YET
Abstract
Verifiable offline preservation and recovery of executable AI capabilities
ArkMesh investigates whether an AI capability that an operator may lawfully possess can remain obtainable, authentic, reconstructible, and eventually executable after the original publisher, host, wide-area network, or signing key becomes unavailable. The present prototype establishes a local cryptographic and erasure-recovery baseline. It does not yet establish distributed continuity.
Primary research question
Can a fresh device recover and verify a complete authorized AI capability from consenting independent peers after every original infrastructure dependency has been removed?
Ordinary backups or existing distribution systems provide equivalent continuity with lower complexity, or ArkMesh cannot preserve authenticity, consent, and executability under realistic failures.
Loss of publisher, complete objects, shards, network access, keys, peers, and compatible hardware.
Recovery success, exact-byte verification, authorization outcome, time, overhead, and executable health.
Ordinary backup, shared folder, content distribution, and local model runner where each is applicable.
Any poisoned, unauthorized, incomplete, irreproducible, or silently overclaimed recovery counts as failure.
Deletion ceremony + digest and signature verification
Merkle proof and hostile-donor rejection tests
Requires peer, placement, retention, and physical experiments
Requires runtime compatibility and offline health evidence
Open wiki index
System overview
What happens to a lawfully held AI capability when the internet, original publisher, or hosting organization disappears?
ArkMesh treats an AI capability as a dependency closure: model or program assets plus tokenizer data, configuration, runtime requirements, knowledge, licenses, operating instructions, provenance, and recovery evidence. Preserving only weights may preserve bytes while losing the ability to interpret, authorize, or execute them.
The thesis decomposes continuity into four independently falsifiable properties: obtainability, integrity, authority, and executability. The current alpha demonstrates local integrity, authority, repair, donorless reconstruction, and sampled retrievability. It does not yet demonstrate peer distribution or executable recovery.
The target system removes one permanent coordinator but does not remove human governance. Every device owner retains control of identity, storage, bandwidth, trust policy, and execution. Discovery provides reachability information, never consent.
The decisive experiment removes the original publisher, disconnects WAN access, introduces a fresh device, and asks whether independent consenting holders can recover and run one exact authorized capsule. Until that physical experiment is independently reproduced, distributed continuity remains a hypothesis.
The target claim is not that bytes exist somewhere. It is that a new operator can recover the exact authorized capability without silently importing a poisoned object or relying on the failed origin.
Command references
C:\ARKMESH> status
C:\ARKMESH> evidence
C:\ARKMESH> roadmap
Quick start
Build and exercise the Go reference CLI without a model download.
Go 1.22 or newer is required. The reference core uses only the Go standard library. Use generated fixtures or assets whose licenses permit the intended storage, testing, and redistribution; the repository intentionally bundles no model.
A valid reproduction records the exact revision, environment, commands, raw output, and discrepancy. Running the happy path alone is insufficient: the ceremony also requires recovery below threshold to fail without publishing an object.
The quick start establishes a local baseline, not the project thesis. It removes complete local objects but does not exercise peer discovery, encrypted transport, physical failure domains, long-term retention, or inference hardware.
- 01Construct
Pack, sign, protect, and record the initial evidence.
- 02Destroy
Remove the source, complete object, and selected shards.
- 03Recover
Reconstruct into temporary storage from surviving evidence.
- 04Adjudicate
Accept only after integrity, authority, and policy checks pass.
Command references
C:\ARKMESH> go test ./...
C:\ARKMESH> go build ./cmd/arkmesh
C:\ARKMESH> ./scripts/demo-offline-recovery.sh
Capsules and manifests
Content addressing separates human metadata from the bytes that determine identity.
Object paths come only from validated SHA-256 digests. Human names and roles remain metadata, preventing an untrusted manifest from selecting arbitrary filesystem paths. The manifest commits names, roles, sizes, digests, optional chunk roots, ancestry, and a deterministic capsule ID.
Canonical encoding is a security boundary because signatures are meaningful only when every verifier derives the same identity from the same logical manifest. Strict decoders therefore reject duplicate fields, unknown fields, malformed hashes, and ambiguous structures instead of normalizing them silently.
Completeness is partly semantic. A valid capsule can still omit a required driver, undocumented prompt template, hardware assumption, or license condition. ArkMesh verifies declared contents; execution experiments and independent review must test whether the declaration is sufficient.
A signature proves control of one specific private key over one capsule ID. It does not prove legal identity, factual truth, model safety, license compliance, or permission to execute.
Command references
C:\ARKMESH> arkmesh pack
C:\ARKMESH> arkmesh inspect
C:\ARKMESH> arkmesh verify
Chunks, repair, and erasure
Authenticated chunks localize damage; erasure shards reconstruct bytes when no full donor survives.
Merkle proofs bind a chunk's bytes, index, tree size, asset, and signed capsule commitment. This allows a verifier to authenticate one range without reading the entire object and to localize damage against an independently retained tree.
Targeted repair treats donors as hostile. Each candidate chunk is verified before any write, only damaged ranges are replaced, the result is truncated to the signed size, and the complete capsule is verified again.
Streaming Reed Solomon protection uses a systematic GF(2^8) code to trade storage overhead for tolerance of missing shards. Coding restores enough information to reconstruct bytes; it does not establish their identity or authority.
Reconstructed output therefore remains temporary until size, SHA-256 digest, Merkle root, signature, and active local policy agree. Loss beyond parity, forged shards, and inconsistent shard sets must fail without publication.
Erasure coding restores availability, not trust. Reconstructed bytes remain unaccepted until they match the commitments already covered by the signed manifest.
Command references
C:\ARKMESH> arkmesh chunks
C:\ARKMESH> arkmesh erasure
C:\ARKMESH> run demo
Retrievability audits
A sample yields a confidence bound, not an unsupported claim that an entire replica is intact.
Challenges use cryptographic randomness and sample chunks without replacement. After a clean sample, ArkMesh inverts the exact hypergeometric model to report the largest missing fraction still compatible with the observation at a stated confidence level.
The conclusion is deliberately asymmetric: a sampled failure is direct evidence of damage, while clean samples only reduce the range of plausible unseen loss. A sample is never presented as whole-object verification.
Audit history records checks that actually occurred using local timestamps. It cannot prove omitted checks did not occur, that the local clock was honest, or that bytes remained available between observations.
Longitudinal retention requires unpredictable scheduling across independent holders plus time evidence that one operator cannot silently rewrite. That extension remains planned.
Command references
C:\ARKMESH> arkmesh audit sample
C:\ARKMESH> arkmesh audit history
C:\ARKMESH> plan retention
Security boundaries
Authenticity before availability: an available but poisoned capsule is a failure.
The adversary may control peers, transport messages, capsule contents, donor bytes, stale lineage, and local wall-clock claims. Authentication narrows who sent a message; it does not make the peer honest or grant consent to consume resources.
The verifier applies ordered gates: strict parsing, path safety, size and digest integrity, chunk commitments, signature validity, lineage authority, revocation, checkpoint policy, and only then atomic publication. Availability never bypasses authenticity.
Device owners control identity, storage, compute, bandwidth, trust policy, removal, and execution. ArkMesh must never scan, exploit, conceal, install remotely, treat discovery as consent, or execute arbitrary received plugins.
A compromised local operating system remains outside the protection claim. Such an attacker can replace verifier binaries, policy files, checkpoints, or displayed results. Hardware roots and independently administered policy are future research, not implied guarantees.
strict parse → integrity → authority → local policy → publication
A compromised local operating system remains inside the trusted computing boundary and can replace policy or verifier state. ArkMesh does not claim protection from that attacker.
Command references
C:\ARKMESH> security invariants
C:\ARKMESH> threat model
Evidence and benchmarks
Claims are tied to reproducible commands, raw observations, and named limits.
The release ceremony is a destructive controlled experiment: it creates a signed fixture, protects it with four data and two parity shards, deletes the publisher source, complete object, and two shards, then reconstructs and verifies the exact bytes. A three-shard attempt is the negative control and must leave no object.
Benchmarks publish fixture size, environment, commands, storage overhead, and raw observations. The current Apple M5 measurements are a local implementation baseline, not a peer-network comparison or universal performance estimate.
Evidence is versioned with the implementation because protocol claims can regress. A credible result identifies the exact revision and distinguishes cryptographic validity, policy acceptance, recoverability, and executability.
The decisive external-validity test remains undone: independent operators on varied physical devices must compare ArkMesh with ordinary backups, shared folders, and existing distribution tools under the same failure schedule.
Area
What evidence supports
Current method
What it does not support
Changed bytes are rejected
Unit + hostile fixture
Content is safe
An accepted key authorized this edge
Signature + policy tests
Signer legal identity
Four valid shards reconstruct exact bytes
Destructive local ceremony
Distributed survival
Observed samples bound plausible loss
Exact statistical calculation
Future availability
Command references
C:\ARKMESH> evidence
C:\ARKMESH> benchmark
C:\ARKMESH> run demo
Roadmap
Seven dependency-ordered experiments separate verified local recovery from independently reproduced executable continuity.
The roadmap begins from the implemented local core, not from organizational scale. A fresh device must first establish explicit trust and consent; only then can authenticated transfer, failure-domain placement, longitudinal evidence, and execution be evaluated.
Authority distribution and branch reconciliation move later because they become necessary when independent communities remain disconnected long enough to evolve divergent but valid histories. They do not block the first two-node recovery experiment.
The route ends with an integrated physical experiment rather than another protocol feature: remove the publisher, disconnect WAN access, recover on a fresh device, verify authority, run a local health check, and publish raw results against simpler baselines.
Support for different model families is a cross-cutting constraint. Every milestone must remain format-agnostic while refusing artifacts the operator is not legally allowed to possess or redistribute.
- BASEVerified local core
Implemented evidence
- 01Fresh-device trust and consent
Acceptance evidence required
- 02Authenticated resumable peer transfer
Acceptance evidence required
- 03Failure-domain placement and repair
Acceptance evidence required
- 04Longitudinal retention and attested time
Acceptance evidence required
- 05Runtime compatibility and local health
Acceptance evidence required
- 06Partition authority and reconciliation
Acceptance evidence required
- 07Independent continuity experiment
Independent summit
Fresh-device trust and consent
Let a new device create or import identity, accept a scoped invitation, choose a capsule, and approve storage, bandwidth, expiry, and recovery limits.
Done when: A fresh device reaches an explicit ready state without ambient trust, remote installation, hidden defaults, or treating discovery as consent.
plan bootstrap
Authenticated resumable peer transfer
Discover invited peers with bounded metadata disclosure, authenticate them, and resume encrypted chunk and shard transfer under exact authorization.
Done when: Two-node tests reject unauthorized, expired, replayed, over-quota, wrong-capsule, and hostile-donor requests before atomic publication.
plan transfer
Failure-domain placement and repair
Place shards across independent physical risks, expose recovery margin, detect degradation, and request bounded authenticated repair.
Done when: Operators can see correlated-risk concentration, expected recoverability, repair cost, and every write before approving placement or repair.
plan placement
Longitudinal retention and attested time
Turn isolated possession checks into repeated unpredictable observations whose timing cannot be silently rewritten by one local clock.
Done when: Reports distinguish observed checks from missing evidence, bind events to independently verifiable time, and never infer retention across unaudited intervals.
plan retention
Runtime compatibility and local health
Determine whether a recovered capsule is executable on the available hardware and run an allowlisted deterministic health check without cloud authentication.
Done when: ArkMesh reports verified, executable, dormant, or incompatible states without automatic execution or claims of behavioral identity.
plan execution
Partition authority and reconciliation
Distribute scoped authority policy, exchange retained heads after partitions, preserve divergent authorized descendants, and require deliberate reconciliation.
Done when: Independent devices reject policy rollback and silent last-writer-wins replacement while retaining both valid branches and their ancestry.
plan reconciliation
Independent continuity experiment
Remove the publisher, disconnect WAN access, introduce a fresh device, recover from consenting peers, verify the capsule, and run its local health check.
Done when: An outside researcher reproduces the complete physical experiment, publishes raw evidence, and compares ArkMesh against ordinary backups and shared folders.
plan experiment
Command references
C:\ARKMESH> plan bootstrap
C:\ARKMESH> plan transfer
C:\ARKMESH> plan placement
C:\ARKMESH> plan retention
C:\ARKMESH> plan execution
C:\ARKMESH> plan reconciliation
C:\ARKMESH> plan experiment
FAQ and limits
ArkMesh is preservation infrastructure, not a cloud-model clone, autonomous replicator, or consciousness claim.
ArkMesh does not bundle a model, grant access to proprietary weights, or convert a hosted API into a preservable system. It can package only files an operator may lawfully possess. Model-agnostic format support is not rights-agnostic acquisition.
The prototype does not currently discover peers, transfer over a network, schedule placement, attest time independently, or run inference. It cannot survive without sufficient reconstructible data, compatible hardware, energy, and operators who continue to consent.
Cryptographic provenance does not establish truth, safety, legal identity, license compliance, or behavioral continuity. A recovered model may be authentic and still be harmful, obsolete, incompatible, or inappropriate to execute.
If ordinary backups or existing distribution systems perform equally well under the same experiment with lower cost and risk, the simpler method wins. The research program is designed to permit that conclusion.
Open-weight, research, local, and owner-authorized frontier systems with obtainable files.
Provider access, redistribution rights, legal identity, model safety, compatible hardware, or permission to execute.
Command references
C:\ARKMESH> status
C:\ARKMESH> roadmap
C:\ARKMESH> github
Research lineage
ArkMesh combines established primitives but does not inherit their guarantees automatically. Each adaptation requires its own threat model and experiment.
- [1]
Reed, I. S. and Solomon, G. (1960). “Polynomial Codes over Certain Finite Fields.” SIAM Journal.
- [2]
Merkle, R. C. (1988). “A Digital Signature Based on a Conventional Encryption Function.” CRYPTO.
- [3]
Juels, A. and Kaliski, B. S. (2007). “PORs: Proofs of Retrievability for Large Files.” ACM CCS.
- [4]
ArkMesh protocol, threat model, experiments, and security invariants are maintained with the reference implementation.
Query the system.
ARKMESH CONSOLE v0.1.0-alpha.1
OPEN-SOURCE RESEARCH CHANNEL READY
Type HELP or select a command. No capability is simulated as complete.