The visible world: crystals, computation and earned value

Status: proposed research appendix, 20 September 2026. Work Order: WO-2026-006. This document specifies future contracts and acceptance work. It does not resume the paused database implementation, report a DEV-25 inventory, announce a token, or establish regulatory approval. External rules were checked on 20 September 2026; deployment decisions require renewed checks.

1. Visibility is a database property

RURAL should make the world inspectable before making it spectacular. Every logical object has an identity, every relationship has a type, and every displayed claim can lead back to its evidence. Geometry is a projection of these contracts. Moving a shape does not silently transfer ownership, grant authority, merge branches, or settle a payment.

The useful interpretation of “nothing invisible” is complete addressability within an authorized, declared observation boundary. It cannot mean unlimited collection, universal access, or drawing every event simultaneously. A peer cannot inspect another person's private database merely because a relationship exists. Where existence itself is confidential, even a redacted silhouette is forbidden.

An empty SQL table remains an object with columns, constraints and zero rows. A graph edge is an object even when its endpoint is missing, pending or deliberately represented by an authorized opaque handle. Empty, null, deleted, unloaded, unsupported, unavailable and unauthorized are separate states. A broken edge is not silently removed to improve the picture.

Proposed minimum identity is a store identity plus object identity. A revision binds its type version, content reference, originating command, world and causal parents. An observation additionally binds source identity, observation interval, tool version and completeness. Paths and human names are aliases; renaming does not have to destroy identity. Hard links, copies and identical content are different relationships. Content equality alone must not merge two people's objects or publish a guessable private-content fingerprint.

The geometry contract maps object kinds to stable visual roles: crystals for repositories, chambers for namespaces, bounded volumes for functions, ports for parameters and results, typed conduits for relationships, and a distinct cap for governance. Color never carries the sole meaning. A searchable table and keyboard traversal expose the same objects. Layout coordinates and level-of-detail clusters are disposable views; identity, evidence and permissions are durable data.

2. A crystal has several histories

A crystal manifest should identify its repository, registered roots, ownership, code observations, governance stream, data branch, session lineage and runtime capabilities. Its shape describes this composition rather than simply extruding a directory tree.

Code may name a Git commit and a separately captured dirty overlay. Governance has its own revision chain, effective dates, authorship and adoption receipts. Runtime state names live processes and resources; a historical workspace must not restart them merely because it is opened. Derived indexes name all input revisions. This permits governance revision G18 to govern code C42 without pretending Git itself provides independent histories for files in one commit.

Materializing G18 into governance files inside a Git checkout is an explicit reconciliation operation. It can make that checkout dirty. The system records the desired revision, actual file hashes, pending changes and conflicts; it cannot claim an atomic commit spanning RURAL, Git and the filesystem.

Cross-crystal governance should use publish, propose and adopt edges. A source crystal can publish a signed policy revision; a recipient records which revision it adopts and its local restrictions. Adoption never implicitly copies secrets or execution rights. Cycles, contradictory caps and revoked publishers produce visible conflicts. A session fork captures context but must recheck current authority before any effect.

Thousands of proposed changes may coexist, but conflicting writes to one authoritative head still need arbitration. The picture should distinguish queued proposals, stale proposals, accepted revisions and active executors. A growing branch tree must expose retained bytes, leases and expiry, not suggest infinite free worlds.

3. Pipes make motion accountable

A pipe is more than a glowing line. Its definition names source and destination ports, data contract, authorization, transformation version, ordering scope, delivery semantics, capacity, retention and failure policy. Observations name a time window, source sequence, accepted bytes or records, retries, duplicate suppression, loss and projection positions.

Event time, ingestion time and committed sequence remain distinct. A late analytics correction is linked to the fact it supersedes; it does not rewrite the historical receipt. An empty pipe, paused pipe, unavailable peer and zero measured traffic have different meanings. Offline geometry displays the last authorized observation and its age, never a fabricated live connection.

Every durably admitted command should have an addressable outcome or recoverable unknown outcome. Complete logging of every packet arriving during an attack is not a credible promise: pre-admission traffic needs bounded counters, sampled evidence and explicit coverage-gap records. Audit capacity has its own admission reserve. If a required audit record cannot be made, the associated protected effect must not proceed.

The renderer consumes batched change cursors and aggregated windows; it never sits in the commit path. A dense pipe can display a counted bundle that expands into authorized receipts. The observer must not recursively generate rewarded observations of itself. Internal bookkeeping is classified as non-rewardable, and aggregation records identify which detail has expired or was never captured.

4. Understand code in layers, with uncertainty attached

“Any language” is a coverage architecture, not an immediate completeness claim. Begin with language-independent inventory, then add independently versioned language packs. Every source interval should be classifiable as indexed, pending, unsupported, excluded or failed. Unknown syntax remains visible.

Tree-sitter's official description concerns incremental syntax trees, including handling syntax errors. LSP defines call-hierarchy requests and capability negotiation. Both are useful references for boundary design; neither establishes universal program understanding. RURAL's dependency-free engine would not silently incorporate their runtimes. Optional external adapters would be an explicitly different deployment profile. Tree-sitter introduction, LSP 3.17 call-hierarchy specification.

A semantic fact should contain its source revision and range, language-pack digest, configuration digest, predicate, candidate targets, evidence class and unresolved reason. “Resolved under configuration X” is stronger than a model confidence score. Macro expansion, dynamic imports, reflection, generated code, runtime dispatch, embedded languages and foreign-function calls receive explicit boundaries. A shared symbol name is not sufficient evidence of a call.

The indexing pipeline captures a stable file revision, identifies language regions, parses within budgets, emits typed facts, validates references, then atomically publishes an index generation. Consumers can inspect an old complete generation while the next builds. Dependency invalidation follows affected facts; a configuration change can require broader re-indexing than a text edit. Truncated or cancelled work is never published as complete.

A graphify-like tool should return evidence-backed subgraphs. A dctx-like tool should assemble purpose-bound context packets containing source spans, typed summaries, exclusions and expansion handles. Model-generated summaries remain derived suggestions. They cannot promote repository text into host instructions. Evaluation should measure retrieval usefulness and missed dependencies against curated tasks, not merely token reduction or graph density.

5. Zig tools without ambient authority

The extension surface should expose typed requests over immutable snapshot handles, bounded result buffers and proposed changes. It should not expose allocator internals, live tree pointers, raw journal access or the ability to retain a publication lock.

Each package manifest names its identity, publisher, source/artifact digests, protocol version, supported languages, requested capabilities, memory and work limits, determinism class and output schemas. Installation, enablement and permission grants are separate records. Signatures establish provenance, not correctness. Pin versions per analysis job; support revocation, rollback and reproducible test fixtures.

Use three execution classes:

1. Reviewed built-ins: original Zig code compiled with the database, under the same trust and verification boundary as the engine.

2. Isolated Zig workers: separate processes receiving only granted handles and copied messages. They have no database directory, credentials or network access by default. Each operating-system sandbox must be implemented and escape-tested; where sufficient isolation is unavailable, untrusted workers remain disabled. A separate process alone is not a sandbox.

3. Effect workers: explicitly granted filesystem, network or governance operations, executed through a broker that rechecks current authority, preconditions and budgets and records the resulting effect.

Pure workers produce facts; mutation-capable workers produce proposals checked by the core. Crash, timeout, malformed output, excessive allocation and cancellation must preserve the current database generation. Deterministic work can record inputs and outputs for replay. Clock, randomness, remote responses and model inference must be recorded as external observations rather than smuggled into a deterministic transaction.

Zig's language reference explicitly distinguishes illegal behavior and runtime-safety modes. Using Zig is therefore not a substitute for isolation or capability enforcement. An arbitrary native plugin in the engine process belongs to the engine's trusted computing base. Zig 0.16.0 language reference.

6. The DEV-25 observatory: a future read-only game

The first game should let a person answer: what exists, what governs it, what depends on it, what is changing, what is uncertain, and what could safely be reclaimed? Its first version must perform no cleanup, repository writes, builds, hooks, network enrichment or automatic service starts. No DEV-25 scan was performed for this appendix.

Begin with a synthetic fixture, then a separately authorized inventory of the selected DEV-25 roots. Store output outside those roots. Filesystem permissions, changing files, symlink escapes, special files and inaccessible volumes are part of the test, not inconvenient exceptions. A scan receipt reports enumerated entries, skipped subtrees, failures and observation intervals. Directory counts must not imply completeness while traversal is unfinished.

Cache names do not establish disposability. A generated directory can be a runtime dependency; a Docker image can be shared; a merged worktree can contain uncommitted files. A later cleanup executor needs an ownership proof, dependency check, active-use check, precondition revalidation, quarantine where feasible and a deletion receipt. “Git branch merged” alone is insufficient.

Performance targets are unmeasured acceptance proposals: on a declared 16 GB reference machine, a synthetic 100,000-object/500,000-edge world should keep interactive selection below 100 ms p95 after warm-up, using a view budget of 2,500 expanded objects and 10,000 edges. Set initial ceilings of 2 GiB total CPU resident memory for the observatory and its workers, and 256 MiB geometry buffers. Provide a 2D alternative. Benchmark cold inventory separately from warm incremental updates. Publish elapsed time, peak memory, read bytes, skipped bytes and CPU time; do not turn repository-specific observations into a universal Zig speedup claim.

Render only a bounded neighborhood or cluster frontier. Every cluster records its membership query and observation position, so expanding it means fetching more evidence rather than inventing geometry. Cancellation, restart and limited-disk scenarios must preserve progress receipts without modifying source repositories.

7. Measurements are not automatically money

One undifferentiated “currency” would make the system easy to game and impossible to account for. Proposed typed layers are:

“Ten connections” proves neither ten people nor useful collaboration. Active time can be automated, traffic can be looped, agents can manufacture tasks, and colluding peers can validate each other. Raw local telemetry is self-reported evidence, not remotely verified work. Reward verified outcomes where possible, cap issuers and periods, exclude self-generated bookkeeping, detect reciprocal farming, and provide disputes and reversible pending awards.

An award binds a unique measurement, rule revision, beneficiary and decision. Replaying the same evidence cannot mint twice. A correction appends compensating entries; it does not erase a settled history. Rules changed tomorrow do not silently reprice yesterday's accepted awards. Pending, available, reserved, paid, reversed and disputed balances are separate states.

Money and transferable credits require asset-scoped conservation. For each journal transaction and asset, postings balance to zero; issuance and destruction use explicit issuer accounts. Use checked integer minor units or specified fixed decimals, never binary floating-point amounts. Conversions are separate priced transactions with rounding and residual accounts. A hundred usage points cannot be added to one euro.

External payouts need an outbox and reconciliation state machine. Local authorization, signed submission, network acceptance, confirmation and contract-defined settlement are different positions. A timeout leaves an unknown outcome to reconcile, not permission to pay again. Claims on future profits require a funded legal obligation and an approved distribution decision; a database cannot manufacture distributable profit or corporate ownership by incrementing a field.

The proposed first economy is private, non-transferable recognition plus resource metering. Payouts, tradable assets and ownership remain separately gated features. Accounting for obligations does not authorize collecting every human interaction indefinitely.

8. AO and Bittensor: specific ideas, different responsibilities

Current AO-Core/HyperBEAM documentation describes hashpaths, state commitments, HTTP-document representations and composable computational devices. HyperBEAM is an Erlang/BEAM implementation and supports additional build profiles. This is inspiration for addressable computation and explicit evidence, not a dependency-free Zig component to embed. Official HyperBEAM repository.

Proposed fit: an optional remote execution or public anchoring adapter, with a local receipt naming the exact AO process/device, input commitment, evaluator and observed result. Keep local durability, remote computation and external settlement distinct. Never claim that a signature or immutable message log alone proves correct execution, privacy, availability or deletion. Public permanent storage is a poor default for private notes and personal metadata. AO access must remain optional for a local database to function.

Bittensor separates miner work, validator evaluations and stake-influenced reward allocation. Its documentation describes Yuma's consensus clipping and the distribution of emissions; those are network incentive mechanisms, not validation that any arbitrary answer is objectively correct. Current documentation includes changing parameters and preview snapshots, so this proposal imports no token-price, emission-rate or return assumption. Yuma consensus, emissions documentation.

Proposed fit: eventually benchmark useful indexing or retrieval work in a narrowly defined market. A task needs reproducible inputs, held-out evaluation, independent challenge, bounded cost and explicit privacy consent. A subnet must not receive private source code merely because it can provide inference. First demonstrate local utility and adversarial scoring. Reward quality verified under a task contract, not popularity, raw connections or token holdings masquerading as semantic truth.

9. Distribution and legal boundaries that shape the architecture

This is product research, not legal advice or approval. Classification depends on actual rights, money flows, custody, marketing, jurisdiction and deployment. Keep a machine-readable feature matrix by platform and territory; do not hide dormant financial features behind a private activation switch.

Apple. App Review Guidelines 3.1.5 prohibit cryptocurrency rewards for completing tasks, limit mining to off-device processing, and impose conditions on wallets, exchanges and crypto-securities. Section 2.5.2 restricts downloaded executable functionality; 2.3.1 prohibits hidden features. Sections 1.2 and 5.1 require relevant social-content and privacy controls. Thus crypto-for-engagement and arbitrary downloadable Zig tools are material iOS design risks. Non-cash points are a proposed starting boundary, not guaranteed approval; digital purchases still need an applicable payment route. Apple App Review Guidelines.

EU alternative distribution is region-specific and still requires applicable terms, eligibility and notarization. It is not blanket EEA eligibility, unrestricted native execution or an exemption from financial and privacy law. Apple regional distribution documentation, notarization submission.

EU assets and rewards. MiCA Article 2(4)(a) excludes financial instruments from its own scope; that does not exempt them from securities law. Article 4(3) also warns that crypto-assets exchanged for personal data or other benefits are not necessarily offered “for free.” Calling an engagement token free cannot decide its treatment. MiCA, Articles 2–4.

ESMA's qualification guidance discusses ownership, dividend and corporate voting rights when assessing share-like securities, while distinguishing purely technical protocol governance. RURAL must classify the actual instrument before offering ownership or dividends; renaming those rights “points” changes nothing by itself. ESMA final report, Annex III, paragraphs 18–22.

Croatia. Hanfa states that the MiCA transition ended on 1 July 2026 and describes authorization/passporting or applicable notification routes for providers. A new Croatian service cannot rely on an expired VASP transition. Obtain activity-specific classification before custody, exchange or transfer services, and distinguish Hanfa/HNB competences for the chosen instrument. This appendix does not determine tax, employment, corporate-distribution or payment-services treatment. Hanfa's post-transition notice.

Privacy. GDPR requires purpose limitation, minimization and retention discipline; erasure, profiling, security and international-transfer rules can affect the social graph and economy. “Every interaction forever” is not an acceptable default architecture. Keep purposes, legal basis, retention and access policies attached to observations. GDPR, particularly Articles 5, 6, 17, 22, 25, 32, 35 and 44.

EDPB's final blockchain guidance, adopted 7 July 2026, emphasizes design-time assessment, off-chain personal data and effective rights. Encryption does not automatically resolve permanent retention or metadata exposure. Prefer private, deletable stores; separately assess any commitment placed on a public chain. EDPB Guidelines 02/2025, final version. Croatian AZOP describes DPIA requirements for likely high-risk processing; assess the proposed cross-person semantic graph before real deployment. AZOP DPIA guidance.

10. Achievable sequence

First prove the object contract and read-only observatory on synthetic data. Next deliver selected language packs with explicit coverage, isolated workers and evidence-backed context assembly. Then introduce governed local proposals, session forks and cleanup previews. Add private social discovery only after consent, leakage and revocation tests. Test recognition points with adversarial simulations before any redeemable economy. Treat hosted execution, AO/Bittensor integration, transferable rewards and ownership as independent milestones with their own security, operational and jurisdictional acceptance.

The distinctive promise is an understandable world whose explanations survive inspection. Its credibility comes from visible limits, trustworthy receipts and precise boundaries—not from pretending every shape is understood, every interaction is valuable or every token is permissionless money.