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.
That second walker has since grown a full join family, grouping, subqueries and DML -- the entry below. This entry claims only what it says: that the two walkers, asked the same question over the same declared graph, agree.
Evidence: REGRESSION RUN CASCADE_ENV (both walkers in one run);
SQLSEL_SELECT_V1 (the oracle harness); the Schemas page for the
graph itself.
A relational SELECT, refereed by SQLite
Runtime-proven; the join family runs on every REGRESSION ALL. SQLsel is
not a SELECT-shaped wrapper around navigational reads -- it is a typed,
set-oriented statement surface, and its answers are checked against an in-run
SQLite oracle over identical data rather than against expectations written by
the same hand that wrote the query. What executes on every default suite: the
statement surface itself (projection, expression columns, WHERE, ORDER BY,
LIMIT, COUNT(*)), INNER JOIN with aliases and qualified fields,
LEFT JOIN, and RIGHT / FULL / CROSS JOIN -- fourteen oracle-compared row
multisets in the join-family spec alone, alongside an adversarial inner-join
spec that pins the access path at exactly two CDX seeks, two nested-loop scans
and zero hybrid.
Four further surfaces are proven and run explicitly rather than on every pass,
each pending mutation proof, independent review and soak: GROUP BY /
HAVING with COUNT / SUM / AVG / MIN / MAX over single-table and
joined sources; uncorrelated and correlated scalar, IN, NOT IN, EXISTS
and NOT EXISTS subqueries, including double-NOT EXISTS relational division;
SELECT DISTINCT with UNION, UNION ALL, INTERSECT and EXCEPT; and typed
INSERT, UPDATE and DELETE over the house table buffer with WAL-backed
rollback and commit.
Three things the oracle discipline buys that self-written assertions do not.
Joins run through CDX seek and through scan fallback, and both paths are
compared against the same SQLite answer -- so an index that quietly changes the
result set is a red line rather than a faster wrong answer. Outer joins are
checked under SQL's own three-valued logic, with unmatched rows mapped
explicitly to a marker before comparison, which is what makes produced absence
distinguishable from a genuine DBF blank. And the committed-truth boundary is
asserted while a native table buffer is dirty: TUPLE previews the uncommitted
current row, SQLSEL reads committed table truth, and the two are compared
against the oracle across preview, rollback and commit.
Not claimed, and refused in code rather than caveated in prose: cross-table atomic commit. A SQLsel transaction deliberately refuses a second target table, because x64base has no cross-table commit protocol.
Evidence: REGRESSION RUN SQLSEL_SELECT_V1 / SQLSEL_INNER_JOIN /
SQLSEL_LEFT_JOIN / SQLSEL_JOIN_FAMILY / SQLSEL_JOIN_EDGES /
SQLSEL_BUFFER_VIS / EVALDIFF (all default-suite);
SQLSEL_ADVANCED_JOIN / SQLSEL_AGGREGATES / SQLSEL_SUBQUERIES /
SQLSEL_SET_OPS / SQLSEL_DML / SQLSEL_WORKSPACE (explicit-run); the
SQLsel reference and the
SQL conformance page.
NULL is a stored fact, not an empty cell
Runtime-proven -- and the spec is known to be capable of failing. A
VFP-flavor table created with nullable fields carries a real _NullFlags
bitmap: a null is a bit, not a blank. The engine writes one (REPLACE ... WITH NULL, and the dotted .NULL. spelling), reads it back after a close and
reopen, clears it, filters on it through ISNULL() in a FOR predicate, and
refuses the write both on a field that was never declared nullable and while
TABLE BUFFER is on. The discriminating arm is the one that separates null from
empty: the fixture deliberately places a row whose field is blank but not null
ahead of the nulled row, so a build that answers ISNULL from emptiness lands
on the wrong record and reads the wrong value.
The reason this entry can be trusted is that the spec has been red. Its first
run scored 17 of 21, with exactly four arms failing, and the four were one
defect: a value write stored the value and re-committed the null bit, so
REPLACE VNAME WITH "restored" left a cell that ? displayed as restored
while LIST displayed .NULL. -- and it survived a close and reopen. The four
arms were deliberately not retuned after the fix; the markers that went red are
the markers that ship.
Not claimed, stated rather than implied: null ordering. The lane opens
NOINDEX throughout, and what a CDX / CNX / LMDB backend makes of a null key is
unclaimed by it. Nor is ISNULL claimed over a joined or TupleRow source. One
debt stays open and is recorded rather than smoothed: that 17-of-21 was taken by
the DotScript runner, so the bracketed regression path -- the grader
REGRESSION ALL actually reports through -- has only ever seen this spec green.
Evidence: REGRESSION RUN NULLASSERT -- 21 graded markers (5 guards, 16 arms),
promoted to the default suite 2026-09-05 and verified in-suite the same day.
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).
Many workspaces at once, each owning its environment
Runtime-proven. A workspace is not a synonym for "the session". Several can be open at once, as siblings or nested; the same physical table can be open in two of them at different positions; and closing one leaves the others standing. The sibling case is the discriminator, not the nested one -- an implementation that merely spared the root would pass a parent/child test and fail this.
Three things that were process-global became workspace-scoped, each with a spec
that goes red if the partition is removed. The close sweep is scoped to a
workspace's own membership group rather than running 0..MAX_AREA. The relation
store is partitioned, so REL CLEAR ALL issued inside one workspace leaves
another's relation still driving its child. And the three path slots DBF,
INDEXES and LMDB are stamped on the workspace and restored by WORKSPACE SWITCH -- that last one with its founding defect on the record: with two
systems open, a table in one resolved its LMDB container under the other,
because the slots were global and SWITCH moved membership without moving them.
WORKSPACE OPEN now lands in the workspace you are standing in, rather than
deriving a name from the resolved directory leaf and walking out of it.
Workspace identity is durable in both directions. Destroy a workspace, create it
again under the same name, and the new one must carry a greater id -- an
assertion that reads fields of the WORKSPACES catalog table rather than the
console, and that fails if retirement never actually reached the catalog. The
catalog is an ordinary x64 table: the map is drawn in the same ink as the
territory.
Evidence: REGRESSION RUN WSMULTI (siblings, nesting, one file in two
workspaces) / WORKSPACE_SCOPE (scoped close) / RELSCOPE2 (partitioned
relation store) / WSENV (path slots owned by the workspace) / OPENJOIN /
WSLADDER (durable identity) / MWXSHAKE (multi-workspace meets the
memo-resident mini-database) -- all default-suite; the
Workspaces reference.
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.