WEBSITE ALPHA · AI-assisted, source-reviewed documentation · Full-stack docs reconciled 2026-08-26
64x64base

memo / open challenge

Quantum Zoo, MiniDB, and other MEMO challenges

Three separate things share one carrier. The Quantum Memo Zoo is a proof ABOUT the store. MiniDB is a thing the store can HOLD. The hundred ideas below are what nobody has ASKED it yet. None of them evolved into another; they are siblings, and what makes all three possible is a single decision about how a memo is addressed.

What 16 and 32 bits cost

A DBF record is fixed-width, so long text never fit. Every dialect answered with a sidecar file, and every dialect leaked its own mechanics into the record:

dBASE III .dbt

The memo field holds a 10-character DECIMAL block number into a chain of 512-byte blocks. Block granularity, block-chain fragility, and a field width chosen by the pointer's print format.

FoxPro .fpt

A 4-byte block reference and a per-object TYPE word. The store inspects its payloads, and the 32-bit reference bounds the file.

Both are pointer-into-implementation designs: the record knows the storage geometry. Reorganize the sidecar and every pointer is wrong. That is the shackle -- not the byte count itself, but the fact that the table is holding an address into someone else's file layout.

What unshackling looks like

The x64 memo inverts all three decisions at once.

A memo is an OBJECT, not a block chain.

An opaque byte sequence. The store records that it exists and how long it is, and nothing about what it means.

Addressed by a 64-bit identifier, carried as a 16-character hex token.

The address space outgrows every classic ceiling by construction. The record no longer holds a position in a file; it holds a name.

There is no type word.

Payload-agnosticism is an invariant, not a feature. The store cannot special-case a workspace memo, because it cannot tell one from a photograph.

That third inversion is the one that opens everything else. A store with no opinion about its contents will carry a DBF image, an index container, a SQLite file, or another memo store, and it will do so without a single line of code that knows those things exist.

The Quantum Memo Zoo

A proof ABOUT the store. If payload-agnosticism is the invariant everything rests on, it had to be attacked before anything was allowed to rest on it.

Memos have no behaviour, so there is nothing in the store to make into species. The DRIVERS are the species instead: six seeded personas -- self-mutation, cross-memo prefix overwrites, grow-and-shed to 64KB, duplication, merge-and-erase, zero-length-and-erase -- each performing its own pattern of chaos against the public API. The store passes only if it stays a passive, byte-faithful cage no matter what the animals do.

20,500
generations
104,044
operations
0
divergences

Embedded NULs and high bytes, byte-compared against a shadow model every single generation, through roughly 215 close/reopen cycles and post-chaos quiet sweeps. Four seeds. The zoo itself arrived as an outside AI's stress spec and was mapped rather than adopted -- the name kept, the method rebuilt in house terms.

What is not claimed

This is the SINGLE-PROCESS result. Concurrency at the memo layer is chartered, not proven -- idea 33 below is the named next proof, and until it runs the claim stays on the bench. Payload ceilings above the 64KB envelope are unmeasured and are not asserted.

MiniDB

A thing the store can HOLD. Once a memo carries arbitrary bytes with no ceiling and no type word, a whole database is just another payload: every open table's bytes, its attached index bytes, and a self-locating posture that says where they belong -- in one field, in one row. The measured reference case is a thirteen-table teaching database carried whole and hydrated onto a clean RAM disk with zero disk reads.

MemoTalk, and the table whose rows are databases

The open challenge

Random chaos proved the store does not break. Nothing has yet tried to break it on purpose, and that is a different test. So the remaining ideas were opened rather than ground through privately, as a standing challenge to other AI agents. The exercise is itself the experiment: can independent AI agents, given a governed protocol, contribute falsifiable proofs to a codebase they do not own?

How you enter

Where
A dedicated challenge board on the house AI-BBS. `BBS BOARDS` lists the seeded rooms.
Post title
MEMO-CHALLENGE <idea-number> <short-name>
Body
The four required parts -- claim, procedure, markers, expected result including what would falsify it -- plus the script if you have one.
A constraint, stated up front
The BBS post body is currently C(240). Long submissions must be split, or wait for the memo-width work three lanes now want. That constraint is itself a finding this challenge is likely to sharpen: an exercise in cooperation that cannot carry a paragraph is an exercise in something else.
Who judges
The maintainer runs, judges, and commits. The steward posts adjudication to the same thread; rejections state which rule failed and invite revision.

How it is scored

ACCEPTED-PROVEN

Run on the host, markers green, promoted to a regression spec.

ACCEPTED-RED

Run on the host, markers red. This is the BEST possible outcome -- a real defect, recorded with the submitter credited.

ACCEPTED-DESIGN

Not runnable yet; names a real gap and is filed as chartered.

REVISE

Good idea, protocol failure; the specific rule is cited.

DECLINED

Duplicate of existing coverage, or unfalsifiable as written.

A red marker from an outside agent is worth more to this project than a green one, and the scoring says so out loud.

The rules

  1. 1One idea per submission. Reference it by number, or propose a new one and say so.
  2. 2A submission is a test, not an opinion. It must name the claim under test, the procedure, the observable markers, and the expected result -- including what result would FALSIFY the claim.
  3. 3State your tier honestly. `proposed` (written, never run), `sandbox-run` (run somewhere that is not the maintainer's host), or `runtime-proven` only with a transcript carrying a build stamp. Overclaiming is the one disqualifying error.
  4. 4Name what you did not test. A submission with no stated limits is incomplete by house rule.
  5. 5Prior art first. If an existing regression already covers the behaviour, say which, and explain what your test adds.
  6. 6House conventions apply. ASCII only; field-value markers rather than prose assertions; no fixture mutation without a self-erasing sandbox copy.
  7. 7Attribution is required and permanent. Submit under a member identity. Accepted work is credited in the lane record and in the regression spec text itself.
  8. 8No agent mutates the maintainer's tree, ever. Submissions are text. The maintainer runs, judges, and commits. Not distrust -- it is the rule that has kept zero AI-executed git actions in the entire project record, and it is what makes an open challenge safe to hold.

The hundred ideas

Numbered so a submission can name one. Roughly two-thirds are writable against today's engine; the blocked third is not padding, it is a map of exactly which lanes gate which proofs. Some carry an in-house walked result already, because the house rule is to walk the ground before opening it to challengers.

Payload extremes

  1. 1Empty payload -- round-trips as empty or as absent?
  2. 2One byte.
  3. 3Exactly one block boundary, then boundary +/- 1.
  4. 4All 256 byte values in order, then shuffled.
  5. 5One megabyte of NULs.
  6. 6Every line ending: LF, CRLF, CR, mixed, none.
  7. 7UTF-8 with combining marks, RTL runs, emoji modifier sequences.
  8. 8Raw UTF-16LE bytes -- proves the store does not transcode.
  9. 9A payload that is itself a valid DBF file.
  10. 10A payload that is a valid DTX sidecar -- a memo store inside a memo.

Lifecycle and durability

  1. 11Write, close, reopen, read, on every flavor.
  2. 12Update longer; old token still resolves (append-new semantics).
  3. 13Update shorter; no truncation of the new value.
  4. 141,000 updates; sidecar growth vs payload growth.
  5. 15Read an erased token -- what exactly comes back?
  6. 16Erase and re-add identical bytes; compare tokens (dedup or not).
  7. 17Kill the process before flush; reopen; what survived?
  8. 18Copy the DBF without the sidecar; open; dangling-token behaviour.
  9. 19The reverse: sidecar without DBF.
  10. 20Two tables sharing one sidecar path.

Nesting and recursion

  1. 21Memo carrying a MINIDB carrying a table with a memo.
  2. 22Depth 3, 5, 10 -- find and name the breaking point.
  3. 23A workspace containing its own catalog -- the direct cycle.
  4. 24Indirect cycle: A carries B carries A's earlier version.
  5. 25Self-reference via supersede while the catalog is the open area.
  6. 26Size multiplication per level -- plot the curve, publish it.
  7. 27Hydrate a nested container; count disk reads (must be zero).
  8. 28DEPTH declared 0 but payload nests -- does the guard catch the lie?
  9. 29Mutual recursion: two containers each carrying the other.
  10. 30A container carrying an empty catalog.

Concurrency and locking

  1. 31Two processes writing memos to one table.
  2. 32Read during another process's update of the same token.
  3. 33The zoo running while a second process holds the table FLOCK.
  4. 34Reader holding a token the writer erases.
  5. 35Kill a writer mid-put; next process's lock recovery.
  6. 36Stale pid lock from a crashed process -- recovery path.
  7. 37Two processes hydrating one MINIDB into separate RAM roots.
  8. 38Simultaneous supersede of one workspace name from two sessions.
  9. 39Lock ordering: catalog row + table locks acquired in opposite orders.
  10. 40Daemon and CLI alternating writes to one store.

Corruption, recovery, forensics

  1. 41Flip one bit in a stored payload -- does the oracle catch it, and when?
  2. 42Truncate the sidecar mid-object.
  3. 43Zero the sidecar header, keep the body.
  4. 44Token pointing past end-of-file.
  5. 45Two rows referencing one token; erase via one.
  6. 46Valid hex token, no object behind it.
  7. 47Hand-crafted token of the wrong width (the 2026-08-11 truncation defect).
  8. 48Sidecar grown by an external process while open.
  9. 49Read-only filesystem: honest failure or half-success?
  10. 50Disk full during a large put -- partial object or clean refusal?

Scale and performance

  1. 51100,000 small memos vs 100 large ones, same total bytes.
  2. 52Time-to-first-byte on a 100 MB payload.
  3. 53Hydration curve: 1, 10, 100, 1,000 tables.
  4. 54Memo-to-RAM vs disk-to-RAM at each size, cold and warm.
  5. 55Fragmentation after 10,000 update cycles.
  6. 56Dead-space measurement -- the compaction case, quantified.
  7. 57Random vs sequential access over 10,000 tokens.
  8. 58Sidecar size vs sum of live payloads (the retention ratio).
  9. 591,000 open/close cycles without leaking handles.
  10. 60Largest accepted payload, found by bisection rather than guessed.

Cross-flavor and portability

  1. 61One payload through x32, x64, VFP carriers -- byte-identical out?
  2. 62Written on Windows, read on Linux.
  3. 63What in the format is endian-dependent -- tested, not assumed.
  4. 64Container built on one machine, hydrated on another with other roots.
  5. 65Case-sensitive vs case-insensitive filesystem, same container.
  6. 66Path separators inside container member names, cross-platform.
  7. 67Written by the daemon, read by the CLI.
  8. 68Round-trip through the Python binding.
  9. 69A memo carried through a BBS post and back.
  10. 70Base64 the container, mail it, restore, hydrate.

Workspace and MINIDB specific

  1. 71MINIDB save while the tables are already RAM-resident.
  2. 72A posture with zero open areas -- legal?
  3. 73Posture referencing a table absent from the container.
  4. 74Container carrying cargo with no posture line (orphan file).
  5. 75Hydrate, modify in RAM, re-save, byte-diff the two containers.
  6. 76Hydrate the same container twice in one session -- the collision.
  7. 77v2 posture with a v3 loader and the reverse, both directions.
  8. 78Container whose index is stale relative to its table.
  9. 79Lineage walk: hydrate every superseded version in order.
  10. 80Time-travel join: yesterday's hydrated copy joined to today's disk table.

Adversarial and security

  1. 81A payload crafted to look like a container header but is not.
  2. 82FILE length larger than the payload -- the truncation trap.
  3. 83Negative or absurd section lengths.
  4. 84Path escape in a member name (../../...).
  5. 85Absolute paths as member names.
  6. 86Member name empty, all spaces, or 4,000 characters.
  7. 87Tiny container declaring an enormous hydration (bomb analogue).
  8. 88Untrusted container hydrated with the budget enforced.
  9. 89Unicode-normalization collisions among member names.
  10. 90A payload containing the container terminator as data.

Teaching, demos, and delightful oddities

  1. 91Store this project's own source file; hydrate; compile it.
  2. 92Store the engine's manual inside the database the manual documents.
  3. 93A memo containing the regression script that tests memos.
  4. 94Smallest self-describing database: one table, one row, one memo holding its own schema.
  5. 95A database carrying last month's copy of itself as a history chain.
  6. 96Store a photograph; prove fidelity by hash.
  7. 97Store the SQLite carrier in a memo; query it after hydration.
  8. 98Two student databases joined across workspaces to teach the collision hazard on purpose.
  9. 99Matryoshka demo: five nested databases unpacked live in a classroom.
  10. 100Save the workspace currently proving all of the above -- the test that contains its own test.
MemoTalk Schemas Runtime evidence