Some of the engine's most distinctive behavior is easy to miss because it was proven quietly, in regressions and session transcripts, rather than announced. This page promotes those behaviors to named features -- under one rule: every entry states its evidence tier, and nothing here outranks its proof. Tiers follow the house convention: runtime-proven (a transcript or regression shows it), source-evidenced (the mechanism is confirmed in source; the end-to-end run has not happened), chartered (a designed and registered lane, not yet built).
One engine, three DBF flavors
Runtime-proven. The same runtime opens and works classic x32 DBF, the
x64-family format, and Visual FoxPro tables. The teaching datasets ship in all
three (plus a reference copy), and the INDEX_X32 and INDEX_X64 regressions
exercise flavor-correct behavior on every run. Flavor is a property of the
table, not the build: one executable, three dialects.
Evidence: REGRESSION RUN INDEX_X32 / INDEX_X64; the MCC teaching datasets
(x64, x32, VFP, reference); the DBF flavors and indexes
reference.
An index family, not an index
Runtime-proven, one direction of cross-attachment chartered. The engine
carries INX and CNX (classic-generation), CDX with an LMDB-backed key store
(x64-generation), and publishes the attach / rebuild / order / seek seams as
architecture rather than sealed internals. Cross-generation attachment is
policy, not accident: a CNX can be explicitly attached to an x64 table with an
advisory (proven by the INDEX_X64_CNX regression, including REINDEX
routing and the unchanged CDX default); the mirror direction (CDX on classic
tables) is a chartered lane awaiting its proof.
Evidence: REGRESSION RUN INDEX_X64_CNX; CDX / LMDB indexing;
the Open Index API section of the API reference.
Whole tables -- and their indexes -- in RAM
Runtime-proven. The in-process RAM virtual disk (VDISK) hosts complete
x64 tables and their native CDX indexes with zero files on disk: built,
indexed, and traversed in ordered form entirely in memory, then unmounted. The
MEM regression is the standing proof (create, index, ordered read-back,
teardown -- all in RAM).
That same virtual disk is now a hydration target: a saved workspace can be stood up into RAM on demand -- 24 files and 92 KB of tables and indexes in under a tenth of a second -- and dropped again by unmounting, with the disk originals untouched. The residency claim is cross-checked rather than asserted: the copier's byte count and the RAM disk's own census are compared every run, and they agree exactly.
Evidence: REGRESSION RUN MEM; WORKSPACE_RAM (timed hydration + census
cross-check); VDISK STATUS residency checkpoints in both transcripts.
Two relational consumers over one declared graph
Runtime-proven, on a production-shaped schema. The same declared relation
graph is walked by two independent engines: traditional SET RELATION
navigation (position drives the child cursor) and SQLsel, the house
set-oriented SELECT (the qualifying rows come back as a set). On 2026-08-10
both walkers answered the same question over a 34-table ERP schema with 58
foreign-key relations -- and agreed on the answer, down to the record. SQLsel's
row sets are additionally verified against an in-process SQLite oracle in its
own regression, so the second walker's correctness is anchored to an external
implementation.
Evidence: REGRESSION RUN CASCADE_ENV (both walkers in one run);
SQLSEL_SELECT_V1 (the oracle harness); the Schemas page for the
graph itself.
A workspace that restores a whole working session
Runtime-proven. WORKSPACE SAVE captures open areas, attached indexes,
selected tag orders, aliases, and declared relations into a plain-text
.dtschema snapshot; WORKSPACE LOAD restores all of it. The standing
demonstration restores 43 work areas and 58 relations -- an entire ERP, posed
and ready to relate -- from a single command.
Two later increments turned a schema snapshot into a session snapshot:
- Self-locating postures. A version-3 snapshot records the roots its tables live under, and a restore resolves against those rather than whatever environment happens to be set. The proof deliberately breaks the environment first -- points the engine at the wrong directories -- and the workspace still stands up, because the posture knows where it lives. Version 2 is untouched and still the default; the new lines are additive, and older readers skip them.
- Session state, not just structure. A version-3 save also records where each area's cursor sat and which area was selected. A restore puts them back and then refreshes relations, so child tables re-slave to the restored parent positions. The standing proof drives a sales-order parent to its last record, saves, tears the whole workspace down, reloads, and finds parent and slaved child exactly where they were -- 43 cursors restored, verified by the engine's own position reporter.
Evidence: workspaces/cascade_all.dtschema; REGRESSION RUN CASCADE_ENV
Section 2; WORKSPACE_V3 (self-location from a broken environment);
WORKSPACE_SESSION (cursors, selection, refresh).
GUI-orthogonal by construction
Source-evidenced, enforced as doctrine. Terminal, TUI, and future GUI surfaces are consumers of the same runtime truth: ordering, cursor state, relations, validation, and command execution live in the engine and DotTalk++, never duplicated in UI logic. A front end can be added or removed without the database behaving differently -- which is what makes the parallel GUI/TUI lane a lane rather than a rewrite.
Evidence: the Application UI DSL lane; the workbench front-ends principle on the architecture page.
Modular by structure, not by slogan
Source-evidenced -- verifiable from the build itself. The claim is
checkable in one build log: the engine links as separate libraries with
separate responsibilities -- xbase (tables and work areas), xindex
(indexes), memo (memo storage), xexpr (the expression evaluator),
dottalk_value (the value system), dottalk_tvui (the TUI) -- under the
dottalkpp command host. The execution chain is equally legible: main to
shell, shell to command registry, registry to one cmd_* translation unit per
command, commands to the libraries. Every seam in that sentence is a real
compilation boundary.
Evidence: the CMake target list in any build transcript; the architecture layering; per-command source contracts in the command files.
Payload-agnostic memos, proven by adversary
Runtime-proven. x64 memos are addressed by 64-bit object identifiers and do not inspect what they store -- and that claim is no longer taken on the source's word. A seeded stress harness drives six chaotic operation patterns against the store (self-mutation, cross-memo prefix overwrites, growth and shedding, duplication, merge-and-erase, emptying and erasure), with payloads that deliberately include embedded NUL and high bytes, while an in-memory shadow model byte-compares every stored object after every generation. Four seeds: 20,500 generations, 104,044 operations, roughly 215 close/reopen cycles, zero divergences. Byte fidelity, cross-memo isolation, reopen durability, and payload agnosticism all held. Every run replays exactly from its seed.
The harness came from an unusual place: an external AI (Microsoft Copilot) supplied a whimsical "memo zoo" stress spec, which was mapped rather than adopted -- its creature species became driver personas, because our memos have no behavior and that absence is precisely the claim under test. The zoo proves the cage.
Evidence: src/memo/memo_zoo.cpp (seeded harness, shadow-model oracle);
src/memo/memo_smoke.cpp; src/memo/memo_ref.cpp (64-bit payload-agnostic
MemoRef); the FPT64 memo format reference.
Not claimed: contention. Concurrency at the memo layer is a named, unrun
milestone -- a second process holding the cooperative table lock while the
zoo runs.
Memo fields that survive the round trip
Runtime-proven, with a correction recorded. A memo field on an x64 table can be written, closed, reopened, and read back as text -- and updated again after the reopen. That sounds unremarkable until you know the history: a canary written in May 2026 recorded exactly those two behaviors as broken (a reopened memo read back as its internal reference token, and a subsequent update reported the backend detached). A routine request in August -- add a memo field to a students-shaped table, put a string in it -- re-measured both cases green and retired a three-month-old defect by accident. The canary was not wrong; its subject moved, and the record says so.
The same day's tooling then caught this entry's first draft overclaiming. The demonstration built its table in the RAM virtual disk and reported writing nothing to disk; a residency check measured the memo's sidecar file landing on real disk, because the memo store does its own file I/O and bypasses the virtual filesystem. The table was in RAM; the memo was not. The claim was corrected in place, and RAM coverage for the memo store is now a named prerequisite rather than an assumption.
Evidence: REGRESSION RUN MEMO_RAM_HELLO (write, reopen readback, update
after reopen); the 2026-05-13 canary retained in the script tree with its
status updated rather than deleted.
A database posture that lives inside the database
Runtime-proven; the larger destination stays chartered. WORKSPACE SAVE <name> MEMO serializes the entire open posture -- work areas, attached
indexes, selected tag orders, aliases, and every declared relation -- into a
memo field of a self-creating catalog table, and WORKSPACE LOAD <name> MEMO
restores it from inside that table. The snapshot text is byte-identical in
either carrier (one format, two carriers), so there is no second serializer
to drift. Each catalog row records the author (real member attribution), the
timestamp, and the path roots active at save time -- snapshots are
root-relative, so each one declares its own preconditions -- and history is
append-only, with a re-save superseding rather than overwriting. Every save
is verified: the payload is read back through the token stored in the field
and byte-compared, loudly failing on mismatch.
The standing demonstration restores 43 work areas and 58 relations from a memo and then walks the restored graph both ways -- positional traversal and the house SELECT -- which agree to the record. Workspaces became data: queryable, relatable, attributed, versioned, and verifiable in the same store they describe.
The same afternoon the catalog grew into a table of workspaces: a v2 schema with a unique auto-id, carrier-flavored instance identity stamped into every serialized posture, dimensions measured from the open areas rather than declared, recursion-guard columns, and supersede lineage that doubles as a version chain. Format version 3 landed opt-in beside the proven version 2: a v3 posture is self-locating -- it records its own dbf/index roots and a restore resolves against them, proven by restoring 13 areas from a deliberately mis-set environment. A posture can also hydrate straight into the in-process RAM filesystem, timed rather than adjectived: 24 files and 92 KB stood up in the 71-94 ms range, with the RAM census agreeing with the hydration counter byte for byte, and dismissal (unmount) dropping every RAM file while disk stays untouched. And a v3 save now captures session state: per-area cursor positions and the selected area ride in the payload, so a restore resumes exactly where work stopped -- the standing proof drives a sales-order parent to its last record, saves, tears everything down, reloads, and finds parent and slaved child exactly where they were.
By evening the chartered destination itself landed, first try: a memo-resident mini-database. One save carries the posture and every table's bytes and every attached index's bytes in a binary-safe container -- the whole 13-table teaching database, 94 KB, inside one memo field, byte-compare verified as a unit. Loading it back needs no disk at all: onto a clean RAM disk, 24 files hydrated from the memo in 65 ms with zero disk reads, rows readable and indexes attaching from memo-carried bytes. A whole small database now lives inside a field of another database -- versioned by the catalog's supersede chain, attributed, and verifiable, the design the 2026-07-28 external intake chartered.
The return leg is now proven too. WORKSPACE WRITEBACK closes the
cycle: a workspace living in RAM, hydrated from a memo, writes back out to a
real disk root. Twelve markers, each shown to fail before its green was
accepted -- values and record counts survive the round trip, the memo sidecar
makes the trip, a collision refusal writes nothing, CONFIRM does replace,
the .__wbak backup opens as a full table so the undo of last resort is
recoverable rather than asserted, and WITH INDEXES lands the container bytes
so the mirror works after the destination's BUILDLMDB rebuild. A shortfall
aborts before writing anything at all: the enumeration authority is the
posture -- what the workspace is -- never the session's current attach order,
because the first cut asked the session and silently wrote 15 of 27 files while
reporting success.
Two corrections from this lane are recorded rather than smoothed, because both were the page's own standard failing before it held. An earlier RAM-memo demonstration claimed zero disk writes, and the day's own hydration tooling measured the memo sidecar landing on real disk; the claim was corrected in place. And writeback was briefly published here as proven on both toolchains when one of the two transcripts was a false green -- a run that wrote to one directory and asserted against another, closing green because it never read its own output. That claim was withdrawn, the path resolution was fixed so a relative token names one directory to writer, reader and teardown alike, and the second toolchain was only re-proven on 2026-08-21.
What remains chartered: memo carriage for LMDB, which is outside the RAM filesystem's scope by its own contract.
Evidence: REGRESSION RUN WORKSPACE_MEMO / WORKSPACE_V3 / WORKSPACE_RAM
/ WORKSPACE_SESSION / WORKSPACE_MINIDB / WORKSPACE_WRITEBACK; the
WORKSPACES catalog in the runtime data root; the virtual-workspaces design
package (2026-07-28), now realized at runtime in both directions.
SQLite in the same room, on purpose
Runtime-proven. SQLite is compiled in as a companion carrier and as a
verification instrument: dual-carrier teaching systems keep a sealed SQLite
authority beside their x64base mirrors, the ERP and SQLITE command
families open and query it natively, and the house SELECT checks its answers
against a SQLite oracle. Competing with SQLite and using it as the referee are
the same decision, made deliberately.
Evidence: ERP CHECK scorecards in the Cascade transcripts; the
Schemas dual-carrier contract; SQLSEL_SELECT_V1.
Self-measuring governance
Runtime-proven -- on the project itself. The same measurement discipline the engine applies to data is applied to the project's own governance. The maintainers' rulings page is generated per request from canonical sources ("nothing on this page is hand-entered"), and on 2026-08-10 its derived-versus-declared reconciliation caught its own maintainers: a hand-kept footer said 20 open rulings, the parse measured 18. The footer was retired the same evening and the derived figure owns the count now -- with the incident kept visible as the page's own history rather than erased. A check that has never disagreed with its operators has never been tested; this one disagreed and was right.
Evidence: the retirement sentinel and parser recognition in the source tree
(commit 7a38c7fb8); the Cases and Storyboard
live case; the coined-vocabulary entry for the no-perishable-literals rule.
This page follows the site's proof-language rule: entries are promoted here when their evidence exists, and their wording is demoted the day their evidence tier says so. If a capability you expected is missing, it is either listed at a lower tier above, or its proof has not run yet.