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

Laboratory Campus Overview

An alpha campus for planning, collaboration, and proof-aware learning through x64base and DotTalk++.

The Laboratory Campus is the learning-lab and collaboration framing for the x64base / DotTalk++ ecosystem. LabTalk remains the project mark and legacy name; Laboratory Campus is the public-facing name.

It is not just a single app. It is an alpha hybrid of planning material, implemented pieces, in-development labs, datasets, runtime demonstrations, help systems, GUI experiments, and proof artifacts that make computing systems easier to study and easier to collaborate on.

Campus Mission

The campus mission is to let people learn data systems by using, inspecting, and helping to build the same engine, language, documentation, and proof tools that operate the campus.

Everything is data.
Everything can become a lesson.
Everything important should be inspectable.

x64base is the substrate. DotTalk++ is the executable teaching and observation language. HELP, metadata, contracts, SelfDoc, and MDO form the explanatory and verification structure. The Laboratory Campus configures those materials into labs, cases, tools, lessons, and learning paths.

This is an increasingly self-hosting direction, not a claim that every current document and registry already lives in x64base. Portable files and exports remain necessary for bootstrap, review, version control, and recovery.

Learning around live systems in the Laboratory Campus

Cases and Storyboard

The campus case-study material now has a visible entry point: Cases and Storyboard. That page surfaces the LabTalk / DotTalk++ systems storyboard deck, case families, and the proof-aware path from source memory to reviewed case notes, datasets or simulations, runtime/UI demonstrations, proof artifacts, and lessons.

Laboratory Campus

Think of it as a campus:

  • Runtime Systems Lab - DotTalk++ commands, scripts, work areas, tables, records, indexes, and relations.
  • Historical Data Systems Lab - punch cards, COBOL, CODASYL, xBase, SQL, ERP, cloud computing, and AI-era data literacy.
  • Self-Documenting Systems Lab - comments, contracts, HELP, CMDHELP, CMDHELPCHK, metadata, and proof readback.
  • Dataset Library - small inspectable datasets for lessons and repeatable labs.
  • Case Library - engineering and historical cases that connect live demonstrations to real system stories.
  • GUI, pycrud, and Portal Lab - local launchers, CRUD/database literacy tools, dashboards, and front-end experiments that expose the same underlying evidence.

The Python Integration page separates the native pydottalk engine binding from the pydottalk_api prototype bridge and the pycrud teaching application. Together they make a useful campus path from engine inspection to API and GUI experiments, while preserving which behavior is runtime-proven and which remains prototype work.

The first public history path is the Database Evolution Path, which integrates the LabTalk / DotTalk++ storyboard deck as a teaching artifact from punch cards and COBOL through xBase, enterprise data, cloud computing, and AI.

The Education Features page now exposes source-defined teaching surfaces such as IDX timed index/sort labs, student command/function hooks, SORT lab behavior, and pre/post polling hooks.

The Runtime Evidence Gallery records reviewed screenshots from Arctic, the local campus portal, workspace loading, table browsing, tuple output, and GUI/TUI readback for use by the manual and website.

The Lesson Platform now separates student lesson seeds from career lessons learned while building the system. The site is also open to structured input through Suggest a Lesson.

The LMS Communications Lane documents a provider-neutral local queue, CLI, and portal status command. Moodle is recorded only as a future provider candidate: live delivery is disabled, and no endpoint, token, student data, or grade data is configured.

Laboratory Campus evolution spine showing development, reviewed staging, documentation, campus learning, proof, and reviewed publication

Repository Boundary

The Laboratory Campus is a consumer layer, not a replacement authority for the engine.

  • x64base remains the owner of engine/runtime truth, including command semantics, cursor state, relations, indexing, and the Arctic GUI/TUI workbench surfaces.
  • DotTalk++ remains the best runtime/manual identity for the command shell and teaching shell surfaces.
  • LabTalk owns the portal, registries, labs, proofs, assignments, and campus overlays that consume runtime truth.

That means the campus may launch, explain, and sequence runtime behavior, but it should not silently redefine the behavior that belongs to the runtime.

The curated ecosystem relationship map shows this boundary across x64base engine services, DotTalk++, DotScript, SelfDoc/MDO publication, proof artifacts, curriculum, and campus delivery lanes. It explicitly labels active, evolving, alpha, experimental, and reserved work.

Core Pattern

Campus material should follow a proof-aware path:

Laboratory Campus proof-aware learning path

concept -> app -> dataset -> command -> proof -> case -> lesson

This keeps lessons connected to live or reviewed evidence instead of becoming detached prose.

AI Portal — Alpha/Experimental

The AI Portal is the experimental AI-facing entrance to the campus. It is intended to follow typed project and artifact jumps and assemble bounded, proof-aware context for a specific series of tasks.

The lane is Alpha/Experimental. It is not production autonomous memory or an independent authority source. Read-only preparation is the default, and its graph validation, execution controls, recovery, and evaluation gates must pass before any stronger status is claimed.

Current Status

The Laboratory Campus is an active alpha direction. The AI Portal within it is explicitly Alpha/Experimental. The campus is a collaboration area and learning-lab program, not yet a finished packaged distribution.

Academic and Research Direction

The Academic Positioning and Research Agenda frames candidate work across database education, learning sciences, HCI, end-user programming, literate computing, explainable systems, and computing education research. It separates implemented system evidence from educational hypotheses that still require literature review and empirical study.

See the Academic Positioning and Research Agenda, Laboratory Campus SDLC, Database Evolution Path, Education Features, Lesson Platform, LMS Communications Lane, Runtime Evidence Gallery, Non-Profit Guide, and Examples.