The Cases and Storyboard lane is the public doorway into the Laboratory Campus case-study material. It connects the local LabTalk / DotTalk++ systems storyboard deck, reviewed career/source-memory stories, database-history lessons, and proof-backed classroom labs.
The campus exists because database systems are not only commands and formats. They are stories about records, people, operations, mistakes, evidence, recovery, and learning.
Source Deck
The current source teaching artifact is the LabTalk / DotTalk++ Systems Storyboard Deck, maintained as a private/local source artifact rather than a public download.
The hosted site summarizes the deck instead of bundling the large PPTX into the public website source. The page can use compressed slide-panel exports as a shallow visual index, while the full deck remains a local/source artifact that can feed classroom material, SelfDoc catalog work, generated manuals, and reviewed website summaries.
Storyboard Panels
These panels are reduced exports from the local storyboard deck. They are meant to show the shape of the teaching sequence without turning the page into the full presentation.
| Overview | Foundations |
|---|---|
 |  |
| Core thesis and artifact boundary. | Business records, reports, and connected-computing foundations. |
| Consequences | Relationships |
|---|---|
 |  |
| Institutional scale, pay, audit, and consequences of error. | Owner-member structures and operational relationships before SQL dominance. |
| xBase Platform | Local Application Work |
|---|---|
 |  |
| Tables, indexes, screens, reports, and accessible application building. | Receivables, scheduling, market fit, and local software lessons. |
| Enterprise Data | DotTalk++ and AI Future |
|---|---|
 |  |
| Documents, transactions, inventory, shipping, and industrial process data. | Why transparent, inspectable database systems still matter in AI-era learning. |
What It Covers
The storyboard currently connects these case families:
| Case Family | Learning Role |
|---|---|
| Punch cards, records, and batch processing | Shows why layout, order, correction, and validation mattered before interactive screens. |
| COBOL and business reports | Shows records, fields, reports, and repeatable institutional workflows. |
| JUMPS and mainframe-scale consequences | Shows that database errors can affect real people, pay, status, and audit trails. |
| CODASYL and owner-member relationships | Shows operational relationships before relational SQL became dominant. |
| xBase, dBASE, Clipper, FoxPro, and Visual FoxPro | Shows accessible application building from tables, indexes, screens, and reports. |
| Earthkids to CAREPAX | Shows practical local application work, market fit, receivables, scheduling, and lessons learned. |
| Document imaging, ERP, auto-ID, and process data | Shows transactions connecting documents, inventory, shipping, invoicing, and industrial operations. |
| DotTalk++ and the AI-era campus | Shows why transparent, inspectable database systems still matter when AI enters the workflow. |
Live Case: The Pipeline That Audited Its Own Maintainers (2026-08-10)
The newest case comes from inside the macro-system itself, and it is the first one proven the same day it happened.
The AI Portal's Open Rulings page is a small ETL run executed per request: extract the ruling sheets (canonical markdown), transform by parsing rows and deriving counts, load by rendering the view. Its contract is one sentence on the page: nothing here is hand-entered. On 2026-08-10 its reconciliation check fired against its own maintainers -- the sheet's hand-kept footer declared 20 open rulings; the derived parse measured 18. One number was asserted, one was measured, and they had drifted exactly the way hand-kept totals always do. The owner retired the footer the same evening; the derived figure owns the count now, and the drift incident stays visible on the page as story rather than being erased.
Two lessons the campus takes from this case:
- Measurement over assertion. A pipeline that has never disagreed with its maintainers has checks that have never been tested. Ours disagreed, was right, and the correction became doctrine.
- Demonstrated negation. The campus teaches concepts partly by runnably exhibiting their absence -- the deliberate sibling of learning by failure (failure finds the boundary by accident; a built exhibit meets it by design). A batch, file-based system is an honest classroom for modern ETL precisely because its gaps can be demonstrated: change a table outside the pipeline and watch nothing react (that absence is why change-data-capture exists), run two steps out of order and watch the failure (that absence is why orchestrators exist). The principles are shown where we have them; the motivations are shown where we do not.
Proof-Aware Case Pattern
Campus cases should not be loose anecdotes. They should move through the same proof-aware path as other Laboratory Campus material:
source memory -> reviewed case note -> dataset or simulation -> command/UI demo -> proof artifact -> lesson
That separation matters. Some cases can be tied to live runtime proof. Some are reviewed history. Some are source memory. Some need simulation because the original software, hardware, or data cannot be published.
Where To Go Next
- Database Evolution Path - detailed public sequence from punch cards and COBOL through cloud computing and AI.
- Lesson Platform - how cases become student and career lessons.
- Career Lessons - lessons learned while building and recovering data systems.
- Runtime Evidence Gallery - reviewed screenshots and proof artifacts.
- Suggest a Lesson - structured intake for case ideas, datasets, and lessons.
Current Status
This page is active Laboratory Campus alpha material. It gives context to the technical work while separating reviewed fact, local source memory, simulation, runtime evidence, and planned classroom material.