Red5Sorcery
DAY 073·In development·Not open to contributions

A tool being built in public

Data
Sculptor

Data work you can explain.

For the person who receives a CSV — small enough to open in Excel, or far too large for it — and has to turn it into an answer somebody else can trust.

Free.Fast.Private.Pretty.

Current full backlog — approved Revision BM H-31 Read Full Product Backlog→
Approved WASM-002 scope — focused PRD Read Approved WASM-002 PRD→
Day 062 research paper — RQSM Revision 5 (working paper; successor design not frozen) Read RQSM Scientific Working Paper (PDF)→
Approved specification — freeze evidence Read H-31 Freeze Audit→
Approved specification — freeze decision Read H-31 Freeze Record→
Approved specification — integration decisions Read Integration Log→
QA lineage — adversarial review and reconciliation View QA History→
WASM-002 interface — design prototype Open HTML Prototype→
WASM-002 Help documentation — Scenario 1 Read Help Scenario 1→
WASM-002 implementation — public progress and evidence View WASM-002 Development Log→
Record through Day 073 · Tue 20 October 2026 · Build
Build
CP017 accepted and Git-banked. Added caller-ordered Receipt field-sequence serialization; invalid fields refuse the entire sequence. Not a complete Receipt.
Verification
85/85 native tests PASS; seven focused CP017 tests, Rust formatting and WebAssembly library compilation PASS. Local commit: 339cf12.
Progress
17 accepted checkpoints. Of 402 frozen requirements: 14 PARTIAL, 388 NOT_STARTED, none fully accepted. Days 063–073: 1.55 checkpoints per calendar day (17/11); Days 069–072 remain four zero-checkpoint non-work days.
Evidence
The Development Log records tests, corrections and Git evidence. Independent implementation QA, browser-runtime acceptance and public deployment remain unverified.
Public reach
Day 073 LinkedIn snapshot: 1,745 seven-day impressions, 777 followers, 37 profile viewers (90 days), 0 search appearances (Oct 6–12). Audience metrics are separate from engineering output.
Released
Nothing. Data Sculptor V1 remains in development.

The four promises

What those four words have to mean

They were written down before any code existed, and they are constraints rather than slogans. Each one has to be paid for by something the software actually does.

Free

No licence, no seat, no subscription. And nothing it produces is held hostage: the outputs, the saved steps, and the record of what happened are ordinary files on your own disk, readable without this program and readable after it.

Fast

Not a benchmark against database engines — that race is somebody else's. Fast here means the distance between receiving a file and starting work: no upload, no cluster, no provisioning request, no ticket raised with IT. Open it and go.

Private

Data Sculptor does not send your data off your machine. There is no account, no application server, no automatic upload and no sampling — including to a language model. Nothing here stops working when the network does. Local-first privacy is an architectural property rather than a policy promise.

Pretty

Analytical work ends in something another person has to read and act on. The human-facing payoff is a PRETTY table or report: governed, formatted, legible and ready to send. CSV can remain an interchange format, but the handoff should not be a raw dump that costs an hour of tidying before anyone can look at it.

Underneath, three responsibilities

The Storage Engine

Protects the work. Identity, preservation, chronology, provenance, and being able to see what is actually sitting inside a project months later.

The Help Engine

Protects the analyst. Preventing avoidable failures, telling an invalid instruction apart from a real discovery about the data, keeping the evidence, and explaining what happened.

The PRETTY Engine

Protects the handoff. The last mile, where a correct result has to become a document somebody else can open, read, and trust.

How the work gets written

Same command. Different expression.

One analytical language underneath, with three ways of writing it. Which one you reach for depends on what you already know; the meaning the software acts on is identical either way, and moving between them does not change the result.

DS-Steps

The native form. An analytical procedure written a step at a time, meant to be legible to somebody who has never opened the tool and is only trying to work out what was done.

DS-SQL

For people who already think in SQL. An on-ramp rather than a translation layer — it arrives at exactly the same place by a familiar road.

DS-Pipe

For people who already think in pipelines, in the shell and dplyr tradition. The same destination again, reached the way that tradition reaches things.

DS-VERIFY

Verification, not transformation. DS-VERIFY is a first-class V1 language surface for stating propositions about data and evaluating them deterministically: uniqueness, required values, ranges and domains, set relationships, cardinality, implication, and structural invariants. It observes and reports; it does not filter, transform, repair, or mutate the source.

DS-Steps, DS-SQL and DS-Pipe produce datasets. DS-VERIFY produces truths and evidence — a human-readable table of evaluated propositions, with witnesses or counterexamples when a claim fails and provenance for the run. The semantic direction is decided; the exact grammar is still design work, not published syntax.

There is deliberately no dataframe dialect. Three expressions is a decision about who this is for rather than an attempt to accommodate everyone — and each has to mean exactly the same thing underneath, or the idea is worthless.

This is current design direction, not shipped behaviour, and no syntax is published here: the design notes are still a lineage of editions rather than one specification. This page records a changing design and development process, not a release commitment. The Day 065 beta-first strategy is a proposal; the product is not yet available.

AI and the interface

Documentation is the interface

Data Sculptor is not an AI-powered analytics engine. No LLM sits inside the execution core, interprets your data, or makes an analytical decision on your behalf. AI has one job here and it is a narrow one: helping a person reach a tool that works perfectly well without it.

Data Sculptor is being designed to be understandable by language models as well as by people — not because it needs one to work, but because nobody should have to learn a syntax before they are allowed to describe what they want.

The browser, the command line and a language model are three different ways of reaching the same thing. The documentation is the canonical account of what Data Sculptor can do and exactly what each operation means — so if a screen and the documentation ever disagree, the screen is the thing that is wrong. An operation that has not been documented is, in the sense that matters, not finished.

Human language is not a fourth dialect. A model that has read the documentation can translate an intention into DS-Steps, DS-SQL or DS-Pipe, and then you look at what it wrote before anything runs. What executes is an explicit expression in a governed language, through the same deterministic engine everyone else uses. The LLM is an interface. It is never the analytical authority.

You
What you are trying to work out, in ordinary language
A model, if you want one — skip it entirely and nothing changes
DS-Steps / DS-SQL / DS-Pipe — written down, and yours to read
Data Sculptor
Deterministic execution
A result you can inspect

The middle step is the point. There is no stretch of the process where ordinary language turns into an answer by means nobody can see — the expression is written down, in a language that is documented, and you can read it before you run it or long afterwards.

What an AI model actually sees

Data Sculptor does not send your source data, your rows, or your project files to a language model. A model works from the documentation and from whatever description of the problem you choose to give it.

If that model runs somewhere else, only what you deliberately hand to it leaves your machine. There is no automatic upload, no background sampling, no hidden context channel. The file you are analysing stays where it is.

No AI service is required and none is bundled. Use one if it helps, use a local model if that suits your situation, or use none at all — Data Sculptor works the same way either way.

Private means no implicit data egress. A good deal of AI-enabled analytical software will end up working by quietly shipping some part of your dataset into a model's context. The position here is the opposite one: assistance with the interface must not become a back door around local-first computing.

For a person, documentation explains Data Sculptor. For a model, documentation is what makes it operable. That raises the standard considerably: an operation cannot be described with a loose paragraph about what it roughly does, but needs its inputs, its outputs, its effect on grain, its treatment of missing values, its ordering requirements, its failure cases, and what to do next when it refuses.

The public Help layer now begins with scenario-based documentation: one realistic task, the analyst's action, the governed engine behavior, the visible evidence, and the resulting artifacts. Scenario 1 teaches the normal WASM-002 first-materialization path before later Help documents move into refusals, recovery, and failure handling. The Product Backlog PRD remains authoritative; the scenario is a derived teaching document.

Help documentation — teachable scenario Scenario 1 — First Materialization→

One property, close up

Every cell carries its own history

Provenance is not the whole product, but it is the easiest part of it to show. Each value knows whether it was read from the file, computed from other values, or invented by a person — and the third kind is marked permanently, with the mark travelling into anything derived from it.

Extract — csd_2021.csv Select a cell to read its lineage
Extract with per-cell provenance
Geography Year Population Private dwellings Persons per dwelling

No cell selected. Pick one and it will tell you exactly how it got here.

Sourced — read from the file, untouched Derived — computed or repaired Fabricated — not in the source Hatched — fabrication reached this cell

Why

A cleaned file looks exactly like a clean file

Analysts working with government statistical releases spend most of their time on repair. Broken encodings. Geography names that don't match between years. Headers that begin on row seven. Blanks that mean zero, blanks that mean suppressed, and blanks that mean nobody knows — all three in the same column.

The repair isn't the hard part. The hard part is that it becomes invisible the moment it's finished. Nothing in the saved spreadsheet separates a number that was measured from a number somebody guessed on a Thursday afternoon. The judgment was the valuable thing, and it's the one thing the file doesn't keep.

Repair is only the visible edge of it. Judgment is also deciding what population you actually mean, what a single row is supposed to represent, which records belong together, how a blank should be read, and what the finished table is meant to communicate. All of that is reasoning, and almost none of it survives into the file.

Human analytical judgment is the scarce resource in this work. Most tools treat it as exhaust — something that happens, produces a result, and evaporates. This one is built to treat it as the output.

Underneath that sits a gap. A spreadsheet will let you do anything and record none of it. A programming environment records everything and asks you to become a programmer first. Analysts who need work that is rigorous, repeatable and explainable have been made to choose between the two, and that gap is the reason to build this.

Technology

What it is built on, and why

Three technical choices, each made for a reason an analyst would eventually notice even without knowing the reason existed.

  • Rust Chosen for predictable memory rather than raw speed. Software that promises to open a file bigger than the machine it is running on has to control exactly what it is holding at every moment, and Rust allows that without a garbage collector making the decision on your behalf. It also compiles to one executable with no runtime to install, which matters more to somebody with a locked-down work laptop than any benchmark does. There is a second reason that is harder to measure: when the Rust compiler refuses to build something, it says where the problem is, what it understood, and often what to do instead. That behaviour became the model for how this tool should refuse an operation.
  • A command line It came first because a command line cannot hide an unfinished idea. Every operation had to be named, every argument had to mean something, and there was no interface to paper over vocabulary that had not been thought through. That made the CLI an effective laboratory for getting the first semantics right. Day 040 changed the implementation order for the next architecture: WASM-002 will prove the new shared core under browser constraints first, and a standalone native CLI host can then reuse those same frozen semantics.
  • WebAssembly WebAssembly is now the first proof environment for the next shared Rust core. The practical reason matters more than the technical one: a great many analysts simply cannot install software on the machine they work on. A page that runs locally, with the file never leaving the laptop and no account to create, reaches people an installer never will. Day 038 proved that a bounded browser-to-WASM path can stream and certify the complete 7.25 GB source at hundreds of MiB/s on the baseline laptop. Day 039 then proved that a small standalone Rust/WASM extractor can materialize all 29,014,718 rows in under a minute. On Day 040 we stopped WASM-001b before the planned shared-engine timing experiment because the evidence had already changed the product decision: WASM-002 starts browser-first rather than forcing the old native-first architecture to remain the design centre.

The log

What has actually happened so far

Numbered by project day, including days with no development work. Each entry records what happened; non-work days remain visible and count as zero in calendar-day checkpoint velocity. Detailed engineering evidence is tracked separately in the Development Log.

  1. Day 001Sun 9 AugOrigin

    The Project Comes Back to Life

    An unfinished Rust program from 2024 came back off the shelf. The problems that prompted it in the first place had come out of years of real analytical work, and none of them had gone away in the meantime.

    After hoursAn evening product-definition session extended the day, settling the boundary against existing analytical and BI tools and producing the four-word promise the product still carries.

  2. Day 002Mon 10 AugSetup

    The Development Environment Is Real

    A modest laptop became a working Rust machine — deliberately modest, since the whole premise is that large files should not demand large hardware. The surviving source of the 2024 program was recovered and read.

    After hoursAn evening update recognised a second product growing alongside the software — the documentary record of building it — and gave the companion podcast its name.

  3. Day 003Tue 11 AugMethod

    The Council Becomes a Development Team

    Rather than handing out roles, everyone was asked the same question independently: where are you strongest, and where can you contribute most? The answers turned out to be complementary, and the first roles charter was written from them.

    After hoursNothing filed.

  4. Day 004Wed 12 AugDesign

    The Product Becomes More Specific

    A consolidation day with no code planned, spent examining ideas that had arrived faster than they could be checked. The most durable of them was a much safer rule for joining tables together.

    After hoursNothing filed.

  5. Day 005Thu 13 AugDesign

    The Prototype Gets a Contract

    The day was supposed to start with code and did not, which turned out to be right. It produced the name the product still carries and the principle behind everything since: a prototype is small because its scope is small, not because its standards are low.

    After hoursAn overnight session produced notes on revisit cost and durable intermediate work, the clean-data handoff boundary, polished spreadsheet summary tables as a professional deliverable, and the project-culture principle “Judge the work. Not us.”

  6. Day 006Fri 14 AugSpecification

    The Contract Survives the Edge Cases

    Encoding behaviour that everyone assumed was specified turned out never to have been written down. By the end of the day every open decision in the requirements had been disposed of, one at a time, across sixteen drafts.

    After hoursThree notes written into the early hours: staged command-line and browser orchestration with persistent join indexes, selecting everything as a deliberate act rather than a default starting point, and an open-architecture commercial model.

  7. Day 007Sat 15 AugReview

    The Specification Earns a Green Light

    Permission to start coding arrived, and the day ended anyway. Review had found that the obvious way to parse a CSV file would quietly break the bounded-memory promise — demonstrated with a deliberately broken file built to expose exactly that.

    After hoursThe session that ran into the following morning produced twenty-nine research and design notes — large enough that it is logged separately, as Day 008a below.

  8. Day 008aSun 16 AugResearch

    The After Hours Session That Changed the Project

    A fresh language model was pointed at a deliberately messy office dataset to see what it would notice. Its errors were more instructive than its successes: it deleted duplicate records and filled in missing values without ever being told the rules for either.

    After hoursThis entry is itself an After Hours record; the session belongs to Day 007 above.

  9. Day 008Sun 16 AugDesign

    The Work Learns to Remember

    An ordinary annoyance about filing project archives turned into product design. The question underneath it — how do you make the newest version convenient without destroying the older one that explains it — is the same question the tool has to answer for data.

    After hoursTwenty-one notes running past midnight: care and quality of life treated as architecture rather than polish, then the argument that when execution becomes cheap, human judgement becomes the scarce resource.

  10. Day 009Mon 17 AugBuild

    The Contract Becomes Code

    The first session of new Rust, written one requirement at a time: explain the step, make the change, compile, run the test, look at the evidence together, record what happened. Closed at twenty-two of twenty-two tests passing.

    After hoursAn all-night comparison against Power BI, Tableau, Python, R, KNIME, DuckDB, PostgreSQL and Databricks, alongside a first draft of the product constitution and a working estimate of how many people do this kind of work.

  11. Day 010Tue 18 AugDesign

    The Product Becomes Small Enough to See

    After an all-night research session the product felt smaller than it ever had — not less ambitious, just finally easy to describe. Fifty job advertisements were read as product research to work out what the work actually consists of.

    After hoursTwo late notes: documentation as a first-class interface modelled on the Rust Book, and a distribution policy making the browser edition the public product and the command line a laboratory.

  12. Day 011Wed 19 AugMethod

    The Human Is the Critical Path

    A deliberate decision not to code, on the grounds that implementation deserves a long uninterrupted block rather than the leftovers of a busy day. Research continued, but strictly as groundwork for later prototypes and never as changes to the frozen one.

    After hoursThe diary expected a continuation and none was filed; the next captured session appears after Day 012.

  13. Day 012Thu 20 AugDesign

    The Project Teaches Us How It Wants to Be Built

    Rust's compiler errors became the model for how this tool should refuse to do something: say what was found, why it matters, what the evidence is, and what to try next. Strict about the work, kind to the person doing it.

    After hoursEight notes after closeout, including the two foundations the next prototype is built on — a storage engine that protects the work, and a help engine that protects the person doing it.

  14. Day 013Fri 21 AugBuild

    The Suitcase Learned to Travel

    Encoding and header handling were wired into the real executable — byte-order marks detected, unsupported formats refused rather than mangled, and damaged input reported at an exact byte offset. The two foundations of the next prototype got their names.

    After hoursNineteen notes that made presentation the third named engine — storage protects the work, help protects the analyst, pretty protects the handoff — and formalised the nightly capture ritual itself.

  15. Day 014Sat 22 AugBuild

    Naming and Physical Filenames

    Column identity built properly: Unicode normalisation, deterministic handling of duplicate headers, and a guarantee that any name the source file actually authored survives untouched. Closed clean at fifty-two tests, no warnings.

    After hoursAn independent review of SPSS, its adjudication, and the decision that a data dictionary stays optional and human-authored: the tool supplies measurable facts and never invents meaning.

  16. Day 015Sun 23 AugRecord

    Opening Capture

    Began by bringing the project record current with the previous night's work before starting anything new. A review of SPSS was filed, adjudicated, and explicitly ruled out of scope for the prototype already under contract.

    After hoursNineteen artifacts ending in a decision to stop researching — the containment boundary for AI, exported files rather than internal storage as the public contract, and a first receipt experiment to put in front of a real analyst.

  17. Day 016Mon 24 AugBuild

    The Blank Line That Mattered

    Safe filenames were finished — case collisions, accented characters, names Windows reserves for itself, length ceilings — and wired into the real command. Then a test meant to confirm good behaviour failed: given blank lines ahead of a header, the parser skipped past them and took a later row as the schema. Ordinary for a general CSV parser, and wrong for a tool that promises not to reinterpret a file before the analyst has touched it. Closed at sixty-three tests, no warnings.

    After hoursFive notes on working method rather than product: an accepted specification treated as a development contract, and the interactive test-first rhythm written down as a practice. None of them change the frozen contract.

  18. Day 017Tue 25 AugBuild

    The Command That Finally Wrote a File

    Until today the command that pulls a column out of a file was a name with nothing behind it. It now produces real output, built one boundary at a time: the requested column is checked before anything is created, an existing file — or a half-finished one left behind by an earlier run — is refused rather than written over, values containing commas or quotes are escaped rather than mangled, and the result is only moved into place once it has been written in full. Text that isn't valid UTF-8 no longer gets quietly corrupted either; the file is re-read from its first byte under the older Windows encoding instead of being patched partway through. Closed at eighty-two tests, no warnings.

    After hoursSeven notes filed after closeout: a correction to how encoding gets authorised, queued ahead of the next piece of code; a boundary drawn against DuckDB as a respected reference rather than a roadmap; and the argument that this tool belongs beside one analyst's work instead of growing into a governance platform.

  19. Day 018Wed 26 AugBuild

    When Encoding Became a Decision, Not a Guess

    Yesterday's convenience turned out to be a guess made on somebody else's behalf. Where text wasn't valid UTF-8, the program quietly re-read the file under the older Windows encoding and carried on — helpful, and an act of interpretation the contract says belongs to the analyst rather than the tool. So the planned work was set aside and the automatic fallback taken out instead. Run from a script, the command now stops and says how to name the encoding explicitly. Run from a terminal, it explains what it suspects, why the guess could be wrong, and that the source file will not be altered either way — then asks once, and if authorised restarts from the first byte and keeps that answer for every remaining column in the command rather than asking again. Proving it in a real terminal rather than only in tests is what caught the next defect: the retry was decoding correctly while still reporting the wrong encoding on screen. An editing step earlier in the day had also corrupted accented characters inside the project's own source; that was repaired and the day ended with an integrity check across every source file. Closed at ninety-one tests, no warnings.

    After hoursFifteen notes running into the early hours, four of which change what version one has to include: the project's own record — the recipes, receipts and context that travel with the work — promoted from a convenience to a required capability; a way to earn trust in a downloadable program through published fingerprints and buildable source rather than a purchased certificate; a rule that the interface may author analytical logic but must never own it; and a red line against making anyone learn a private vocabulary for an ordinary idea like “for each customer, total sales”.

  20. Day 019Thu 27 AugBuild

    A Column Cannot Come From Two Different Moments

    Two ways a result could quietly go wrong were closed today. A row is now required to hold exactly as many fields as the header — no more accepting a broken row because the one column being asked for happened to sit early enough in it to be found. And because columns are pulled out one pass at a time, the source file is now checked between passes: same size, same modification time, same number of rows the first pass produced. Where that check sat turned out to matter more than the check itself. It was originally made after the finished file had already been moved into place, which is too late to prevent anything; it now runs before. Long extractions also began reporting what they are doing — which column, how many records so far, how long it has been running. Closed at one hundred tests, no warnings.

    After hoursThree notes sharpening what version one is: charts exist to help the analyst think rather than to present — five static types, nothing interactive — with presentation-grade work left to whatever the data is handed off to; a deliberately bounded set of foundational statistics accepted as core product rather than a later addition, aimed at undergraduate experimental psychology and ordinary office analysis; and a detailed account of exactly which tests are in and which are deliberately left out. None of it changes the frozen contract.

  21. Day 020Fri 28 AugBuild

    A Failed Job Should Say What Survived

    A finished extraction now says what it did — which column, how many records, how long it took, where the file went. The harder half was failure. A job of several columns can fail after some have already been written correctly, so one blunt “failed” would discard what the analyst most needs. Failure is now reported in two parts: the job did not finish, and here is which outputs survived and which never became files. Where none survived, it says so in a word rather than leaving a blank. Closed at one hundred and eight tests, no warnings.

    After hoursNineteen notes, two of which correct the night before: the statistics promised yesterday narrow to descriptive work in version one, with inferential methods deferred; and the project's own record is reframed as an ordinary folder anyone can open rather than a format of its own. Alongside them, an argument for publishing that layout as an open specification, and how a bounded first prototype hands over to a second.

  22. Day 021Sat 29 AugBuild

    Twenty-Nine Million Rows and No Surprises

    The morning finished yesterday's failure reporting, then an acceptance run caught the inspect command refusing an encoding the contract requires — fixed narrowly, failing test first. The afternoon put a real file through: 29,014,718 rows, sixteen columns, 6.75 GiB. One column took four minutes forty unoptimised and forty-five seconds optimised; all sixteen took eighty-one minutes, then thirteen. Every optimised output was byte-for-byte identical to its slower counterpart, and memory never passed four megabytes. Closed at one hundred and eleven tests, no warnings.

    After hoursSeven notes circling one problem: a folder full of analytical artifacts is not the same thing as an analytical project someone else can understand. The largest is an early contract for a single local front door — a map of what the project holds, a health check when it opens, deep fingerprint verification, and a closeout that can be handed to another person. Alongside it: no arbitrary row caps, with sampling made repeatable by recording the seed it used; a guardrail stopping a transpose that would produce more than sixteen thousand columns; a commitment to keep the analytical foundation genuinely free rather than fencing off ordinary work; a study of a browser-based competitor that runs its computation on someone else's machines; and a rule that each command-line prototype must have its browser counterpart built and reviewed before the next one starts. None of it binds the frozen contract.

  23. Day 022Sun 30 AugTesting

    The Test Suite Came Before the Code

    No code changed today, and that was the point. The contract's acceptance list forced a separation between three things: what the program does, what proof was kept that it does it, and what is genuinely broken. Six sections closed; five stayed open, meaning evidence was missing rather than that a fault is known. Then the handoff. A second language model was given the contract and nothing else — no source, no test names, no results — and froze its own test suite before seeing a line of the implementation. Its first attempt at the filename rules was wrong in a plausible way; three worked examples in the contract contradicted it. It found the step it had misread, corrected itself, and reproduced all twenty-eight from the specification alone — the specification catching an independent implementer before it had seen ours. Of ten observations sent back, the one worth returning to is that the contract requires the settled encoding to be recorded somewhere without saying where. Tomorrow the tests meet the code.

    After hoursThree notes, all about where the vocabulary should stop. The steps a person writes stay plain and readable, with the work of making them fast pushed down into the engine rather than up into the syntax. The rule that the interface may assist with analysis but must never own it — written a few nights ago — is restated as a constitutional one. And an argument against drift: finish, test, document and optimise a deliberately finite set of operations over one engine, rather than gradually becoming a general-purpose programming language.

  24. Day 023Mon 31 AugTesting

    The Tests Met the Code

    The frozen suite met the code, and neither had been touched since. Fifty-four checks passed and none failed. Twenty could only be recorded rather than asserted, because what they wanted to look at is not something the contract requires the program to show, and one cannot be run on this operating system at all. The second language model rebuilt the project on its own machine, under the oldest toolchain the project claims to support, and reproduced all one hundred and eleven tests. Then the real file went through it: 7.25 GB, sixteen columns read in about a hundredth of a second, one column of 29,014,718 rows extracted in twenty-five seconds inside two and a half megabytes of memory, four separate counts agreeing. Its output and the Windows output of the same column were byte-for-byte identical — 62,266,366 bytes, one hash. Then it found the thing worth finding. A field that was deliberately left empty can be written out as a blank line, and reading that file back silently discards the row: three records become two, and the program exits reporting success. The contract never settled that case for data rows, so this is a decision before it is a fix. One incident is worth keeping: partway through, the frozen suite appeared to have been lost to a session reset, and the copy filed in the project's own record the day before matched its recorded fingerprint exactly. Nothing was accepted tonight.

    After hoursNine notes and one supplementary measurement, none of it binding the frozen result. The measurement first: all sixteen columns extracted in a single uninterrupted run of six minutes thirty-seven seconds, still inside two and a half megabytes, every output matching its Windows counterpart exactly. The notes cover publishing each prototype from this site as a versioned build with the old ones kept; renaming the human-facing surface to a console and giving it a health check with a durable history; the Council method as the real subject of the book, with this product as its case study; and three on speed, which between them settle that one pass writing many columns at once is the optimisation worth having, that more cores are not, and that a one-time decomposition is the wrong thing to tune when the working loop is what the analyst actually waits on.

  25. Day 024Tue 1 SepSpecification

    Forty Pages Before One Line of Code

    No product code was written, and that was the decision rather than the outcome. Yesterday's blank-row finding was specified before being fixed: an empty single-column value is written as a pair of quotation marks, a blank record is refused rather than guessed at, and a file must survive a round trip still holding the number of rows it started with. Making that precise took ten pages and six rounds of adversarial review — one of which caught the specification's own examples corrupted in the writing, no longer showing the condition they claimed to. An assumption carried for weeks was tested and found wrong: on Windows the operating system does not refuse to rename a file over one that already exists. The program's own check was already doing that work, so nothing was lost. Build state unchanged at one hundred and eleven tests.

    After hoursFourteen notes, mostly about what a project should be able to tell you about itself long afterwards: a flight recorder that explains what happened and makes missing documentation visible as a debt rather than an absence; the deeper explanation an analyst should be able to ask for after a message about encodings; and how a published program names, delivers and proves itself. None of it binds the frozen contract.

  26. Day 025Wed 2 SepBuild

    The Same Bytes on Two Machines

    Yesterday's forty pages became code, and the code was measured on two machines that share nothing. The blank-record defect is closed: an empty single-column value is written as a pair of quotation marks, a blank record is refused, and a file survives a round trip with the rows it started with. Two encoding messages were made plainer, and one acceptance test was corrected rather than the product enlarged to satisfy it. Then the overwrite race was staged on both platforms: a file created underneath the program while it was still writing, refused at the last step, the existing bytes untouched and the half-finished output removed. Neither operating system would have stopped that on its own. A twenty-one byte file with Windows line endings produced the same bytes, and the same fingerprint, on Linux. One hundred and fifty tests on both, and no code changed during the second run.

    After hoursTwelve notes, written in final form rather than sketched, nearly all aimed at the browser version: where a stored value stops being a value and becomes an interpretation; a scope line keeping the first version about data and leaving dashboards to other tools; reading a file that arrives over a network; filtering before anything is written out; and letting other people's extensions in without rebuilding the core. None of it binds the frozen contract.

  27. Day 026Thu 3 SepSpecification

    Zero Lines of Code, One Frozen Boundary

    The plan was a thin browser wrapper around the finished engine. The day produced no code at all, and a frozen contract instead. What is being tested is deliberately narrow: run the same engine in a browser and compare speed, memory, file limits and output bytes against the frozen command-line version — same engine, same meaning, same fixtures, same expected bytes, different runtime. Making that one sentence precise took the whole day. The browser keeps browser concerns, choosing the file, storing it, timing and naming; the engine only accepts bytes and returns bytes, and never calls back into the page, so the interface can be rebuilt later without dragging the computational core along with it. A browser cannot hold the 7.25 GB test file in memory, so the file has to arrive in pieces, and that raised the questions that are cheap now and expensive to retrofit: a piece that splits a line ending, or splits a character, or lands inside a quoted field. The rule now written down is that the size of those pieces is a speed decision and never an answer-changing one — the same file must produce the same bytes whether it arrives whole, in ordinary chunks, or one byte at a time. The engine can also refuse more input until what it has already produced has been taken away. The review came back not frozen several times, each verdict closing the previous findings and then finding the next sentence that was still missing: first the invariance, then the brake, then a complete account of the states the thing can be in, then the discovery that the pipe had been specified without ever describing what travels through it. The browser version will do exactly one job, extracting a single column, so that the comparison stays honest rather than becoming a place to smuggle in new behaviour. The single known-good output kept from the day before was widened to four before any test was written, covering the encodings most likely to diverge, and forty-four byte-level checks against them passed. The last obstacle was mundane: one fingerprint in the table had sixty-three characters where it needed sixty-four. Rather than guess the missing one, the project's own archive was opened, the previous day's frozen record was hashed again, and the lost character was recovered rather than invented. Fifty-one checks across the corrected version, none failing. Build state unchanged at one hundred and fifty tests.

    After hoursEleven notes, written in final form. Most look past the browser prototype to the command-line one after it: an architecture for the part of the program that explains itself, the surface it presents and what it can export, and a revised account of how a message about encodings should be worded when it has to teach as well as report. Alongside those, where analytical data should be allowed to live and who is entitled to see it; a comparison of the environments this project tests in; a note on the public engineering record as its own kind of evidence; and an argument about what fast informal coding does and does not settle. Two more bring a third language model onto the project and give it responsibility for the wording of help messages and public documentation. None of it binds the frozen contract.

  28. Day 027Fri 4 SepSpecification

    The Prototype Got Smaller

    A second day with no code, and again that was the decision rather than the shortfall. The morning went to evidence: the four known-good outputs the browser version will be judged against were checked back against the command-line runs they were copied from — thirty-two checks, all passing, and counted apart from yesterday's fifty-one because the two answer different questions. One archived document had been regenerated before filing; the words were faithful but the bytes no longer matched the fingerprint published when it was made, so the rule is now written down: whatever was hashed is what gets kept. The afternoon then changed the shape of the thing. The plan had been a small browser interface — choose a file, type the same arguments as the command-line version, press run. But the test harness has to drive the engine directly or the tests cannot be automated, and if the proof does not need the interface, the prototype does not either. Out went the command box, the help system and everything else that made it look like a product. What remains is an instrument: it feeds in the agreed workloads, streams the file through the frozen boundary, records time and memory and checks the bytes. One visible thing was kept, because the 7.25 GB file still takes sixteen separate passes and somebody has to watch it — a status line refreshed every ten seconds. Build state unchanged at one hundred and fifty tests.

    After hoursSeven artifacts, six written notes and one working prototype page, all pointed at the surface rather than the engine. The argument running through them is that serious analytical work should require stating what you mean rather than clicking until something happens, and that a typed, explicit command surface becomes more valuable as assistants get better at writing commands, not less. Alongside that: a dark terminal console as the shape of the human-facing surface; a browser shell built from plain markup with no interface framework underneath it; the order in which the next command-line prototype and its browser counterpart should be built; and a reading of what other projects moving in this direction suggest. Design evidence and future input only — none of it reopens the frozen boundary or authorises anything to be built.

  29. Day 028Sat 5 SepSpecification

    Twenty Findings Before the Gate Opened

    A third day without code, and the last one that had to be. The specification for the browser version was finished, cut back, and then taken apart. The cutting came first: the document had grown careful and then noisy, so out went future vocabulary, duplicated acceptance language and terminology this prototype had no use for. The frozen boundary was left untouched and pointed at by name, revision and fingerprint rather than retyped into the larger document, where it could drift. Then the whole thing went out for review with nothing beside it — no code, no candidate, no notes — and came back with twenty findings: five blocking, eight material, seven about clarity. The pattern in them was that each section held up alone and the seams between them did not. None of it required reopening the frozen boundary; it required the unfrozen parts to be made exact — which run, which encoding, which exact bytes of configuration, where the timing starts and stops, and which output the browser is measured against. One revision pass, then a second review of the fix: nineteen closed, one left with a wording residue, none open, no new blockers, and a verdict that the document can govern the build. One condition outlived it: the encoding of the large source file must be evidenced before any formal timing run, which holds the measurements rather than the code. Build state unchanged at one hundred and fifty tests.

    After hoursThirteen notes, all in final form, with superseded drafts left out. They range wider than the prototype: what a minimal repair to a broken query should and should not do; the handful of operations analysts actually reach for in a spreadsheet; the argument that techniques for large data belong inside the engine rather than being asked of the analyst; free, local, in-the-browser positioning; the architecture and memory of the project's own archive, including what it means to seal a copy and what a diary note is for; a formal work order as the way requests enter the project; and, after the first release, a paid convenience business built on the same free core. Design evidence and future input only — none of it amends the cleared document or reopens the frozen boundary.

  30. Day 029Sun 6 SepBuild

    Twenty-Eight Days, Then the First Code

    Twenty-eight days of specification, then the first lines of code — and a slower start than that sounds. The frozen boundary names the exact version of the Rust compiler the browser version must be built with, because that is the one the reviewing language model can reproduce on its own machine. This machine had a newer one, deliberately not used. With the older compiler pinned, the existing engine became a shared library the browser version borrows rather than a second copy of the same code, and the hundred and fifty existing tests still passed. Then the afternoon broke: the working session was interrupted partway through. Nothing was restarted and nothing taken on trust — the project was inventoried, the source hashed, and every file of the last delivered package compared against what was on disk. Twelve files, twelve matching byte for byte, none missing. Work resumed from evidence, not memory. What followed was the first real piece of the frozen boundary: checking the settings, the states a session can be in, the memory budget, and refusing work before allocating rather than after. Twenty-seven new tests, one hundred and seventy-seven passing in total, none failing, no warnings. The next step, streaming a file through that boundary, was reviewed instead of written, and the review found the quickest route would have quietly created a second reader of the same file format. It was not written. This is a checkpoint, not the acceptance run.

    After hoursFive pieces in final form, all about the method rather than the product: where each of the language models is actually strong and how a council around them should be arranged; what one person working this way might mean for how software gets made; typed work orders as the way an assistant is asked to do something at a command line; a research-grounded case for the book about the method; and an article arguing that the optimisation everyone reaches for first is the wrong one. Design evidence and future input only — none of it amends the cleared document or reopens the frozen boundary.

  31. Day 030Mon 7 SepBuild

    Three Checkpoints, Nothing Drifted

    The day began by proving yesterday still existed: fingerprints rechecked, the pinned compiler confirmed, the suite run again — one hundred and seventy-seven passing before a line was written. Then three small steps, each banked before the next. The first was a refactor rather than a rewrite: the behaviour that reads a large file piece by piece moved out of the command-line program into a shared core the browser version borrows, so there is one set of rules rather than two that quietly drift apart. Getting there was noisy: a dash an installer script's shell misread, a candidate reaching across the wrong boundary, a packaging pass carrying the wrong fingerprint. Nothing drifted, because each candidate checks the existing state, backs it up, runs the full suite and restores the last good copy if it fails. The second step changed no behaviour and only attacked the seams: the same file fed whole and one byte at a time, split at every possible position, across line endings, embedded newlines and multi-byte characters. One hundred and eighty-four passing. The third was four bytes wide: the marks that say which encoding a file uses overlap, so the reader now waits rather than guessing early. The first attempt did not compile; the installer restored the previous checkpoint and verified every file. The corrected one passed — one hundred and ninety-one tests, none failing, the browser build green. It stopped one step short of reading raw bytes.

    After hoursEleven pieces in final form, most about what the project would be to somebody else. Several work through delivering the tool under another organisation's name — what stays private, who owns the help text, where the branding stops and the engine begins. Others tidy the working arrangement between the collaborators, including two messages sent between them. Two are metaphors for how a small group of specialists gets hired. One records where the book's material may come from. Design evidence and future input only — none of it amends the cleared document or reopens the frozen boundary.

  32. Day 031Tue 8 SepBuild

    A Port, Not a Rewrite

    Yesterday's three checkpoints became ten. The day opened at one hundred and ninety-one tests and closed at two hundred and thirty-seven, each step accepted on its own before the next began. What went in: a decoder that can look at the next raw byte without committing to it; an exact line for where a malformed file stops being read; a hidden temporary copy removed from the shared output path; the existing naming rules kept as the authority rather than restated; and storage for a file's header whose growth is checked against the memory budget before anything is allocated. That last one carries the browser's stricter promise — a refusal has to happen before the allocation and before the byte is counted as consumed, which was proved at exactly one byte over the limit. The order is now fixed: look, plan, check the budget, reserve, commit, then count the byte. One attempt failed all six of its tests. Rather than patch it, the work rolled back to the last good checkpoint and went to read the parsing library, which showed that its fast reading mode cannot be copied mid-stream while a slower one keeps identical meaning and can. The corrected version passed seven, then the whole suite. The clearest result was an answer to a question asked out loud: this is not the command-line program being rewritten for the browser. It is one engine given a second place to run. The pieces are validated separately and deliberately not yet wired together.

    After hoursEleven pieces in final form. Several concern the archive: backing up a working session as it streams, and why a record able to prove its own integrity earns its keep. The rest look outward — what a spreadsheet assistant's change history implies for the person holding the file; documentation written as the authority a language model reads from; how a free tool's official version and its community copies relate; and the office worker as the audience that matters. Design evidence and future input only — none of it amends the cleared document or reopens the frozen boundary.

  33. Day 032Wed 9 SepBuild

    The Browser Learns the Same Names

    The day opened at two hundred and thirty-seven tests and closed at two hundred and sixty-five, with the browser-target library still building under the pinned compiler. The first job was to finish the live source-byte boundary: look at the next byte without taking it, work out what it will cost, check the budget, reserve the memory, commit the change, and only then count that byte as consumed. Thirteen tests were added around that sequence before the checkpoint was boxed. From there the work moved toward output, but still stopped short of producing any. A small staging area was proved first, then a serializer that writes the canonical CSV fragments without creating a hidden temporary buffer. The next obstacle was only visible by reading the Unicode dependency itself. Its convenient normalisation iterator can quietly grow an internal vector on the heap, which would step outside the browser boundary's rule that capacity is accounted for before allocation. Rather than exempt it, a governed scratch workspace was built from the library's lower-level decomposition and composition primitives and tested against the ordinary implementation as an oracle. That made the next piece possible: the same store-name rules the command-line engine already uses — blanks, duplicates, suffixes, collisions and canonically equivalent Unicode names — reproduced without a second semantics path. The full regression stayed green. Output was deliberately left disconnected, because the selected store name still has to be validated on the live path before a header is allowed to exist. The day closed at that boundary, not past it.

    After hoursSix pieces in final form after closeout. Two sharpen the rule that interfaces should expose strong artifacts rather than hide them, including what an AI-assisted media workflow is allowed to do. One compares a new agent-context project with the Suitcase and records why an ordinary, portable project record remains the stronger continuity model. Another sets down the architecture of DS-VERIFY. The final two turn a recurring implementation instinct into an explicit resource-stewardship mandate: optimise the workflow, account for what the kernel uses, and avoid waste without making resource obsession the product. Research, method and future design evidence only — none of it changes the frozen browser contract.

  34. Day 033Thu 10 SepBuild

    Before the First Output Byte

    The day opened from D3B2A at two hundred and sixty-five passing native tests and closed at two hundred and seventy-eight, with the browser-target library still building under Rust 1.75.0. First, the governed store-name resolver was connected to the live input transaction so the requested Data Sculptor store name is validated at the exact byte where the source header becomes complete. Header growth and the two Unicode-normalisation workspaces are planned together, checked against the logical resource budget, physically reserved only after that check, and committed before the name is resolved. That brought the regression to two hundred and seventy-six. The tempting next move was to emit the first analytical header, but inspecting that boundary exposed a stricter requirement: the capacity for pending output is governed state too, so it has to participate in the same pre-commit budget decision before the header-completing byte is consumed. Rather than weaken the rule, the engine gained governed normalisation across two borrowed UTF-8 fragments and an allocation-free candidate-header resolver that can identify the selected source column before final header commit. Two red runs turned out to be test-fixture mistakes rather than production defects. The corrected suite closed green at two hundred and seventy-eight. D3B2C1 was boxed and independently verified. No analytical output was emitted; the day stopped at the clean seam immediately before it.

    After hoursSeven final-form pieces broadened the record without changing the frozen browser contract: a comparison with current spec-driven development practice; a direct comparison of project-memory tooling with the Suitcase continuity model; a whitepaper on contemporaneous human-and-AI Council diaries; lessons from Anthropic's small-business AI research; a semantic-formatting note for PRETTY tables; and two papers developing the one-human-plus-AI-Council microbusiness model and the operating disciplines needed to make it credible. Research, method and future design evidence only — none of it silently amends Revision E.1.

  35. Day 034Fri 11 SepBuild

    The First Analytical Output Header

    The browser build crossed its first live output boundary. Starting from D3B2C1, output capacity was brought under the same governed resource discipline as input, immediate backpressure was proved, and the canonical analytical header was wired into push_input: UTF-8 BOM, the selected original source header, then LF. The day closed at D3B2C2F3 with two hundred and ninety-two native tests passing, none failing, and the wasm32-unknown-unknown library still building under Rust 1.75.0. Selected-column data-record output remains deliberately unwired; that is the next major frontier.

    After hoursThe Suitcase model was sharpened around portable project context, then the PowerShell-and-TXT evidence workflow was researched and written up as Evidence-First Paired Long Division. Claude's adversarial review narrowed the claims and caught several technical and citation defects before the final Revision E.2 was accepted. Method and continuity work only — the frozen browser contract was unchanged.

  36. Day 035Sat 12 SepBuild

    The Raw ABI Shell Gets a Pulse

    The browser build moved from its internal engine path to the raw Annex A boundary a host will eventually call. The work began by proving the previous checkpoint still held, then added module-instance ownership and the smallest possible non-mutating surface before any operational call was allowed through. Three exports now answer only three questions — ABI version, current state and current status — with zero imports, one bounded exported memory and no change to status when they are queried. The canonical Edge run passed with initial values 1, 0 and 0, and the full native regression closed at three hundred and fifty-eight tests passing, none failing. D3D2 was boxed as the validated recovery checkpoint. No operational raw ABI call is wired yet; that is deliberately the next brick.

    After hoursOne research note compared IBM's newly published account of “vibing fatigue” with the Paired Long-Division coding rhythm and the Suitcase continuity method. The useful result was external evidence for problems the workflow was already built to resist — output outrunning understanding, expensive verification, context switching and fragile continuity — without claiming IBM endorsement or changing the frozen browser contract.

  37. Day 036Sun 13 SepBuild

    Green Wasn't Enough

    The raw browser boundary went from three questions to four real operations, one bounded brick at a time. ds_set_budget came first, then transfer reservation and its status-neutral pointer and capacity queries, then ds_begin, each built under the pinned Rust toolchain and exercised against the real WebAssembly module in Edge. ds_push_input exposed the harder problem: the shared core stopped at generated output before the frozen whole-input fixture could reach its required invalid byte. The semantic rule was corrected in the core rather than patched in the wrapper. Then the full library suite reported 279 passing and zero failing — green, but two historical tests short of the population the evidence required. A read-only continuity audit found them, a hash-verified backup restored them by insertion only, and the authoritative regression closed at 281 library tests and 359 native non-doctest tests, none failing. Only then was ds_push_input wired. The module now exposes exactly twelve ds_* functions with zero imports, and Edge proved the frozen error frontier and pending-output idempotency. D3D6 is the validated checkpoint; the complete frozen candidate acceptance suite is still deliberately unclaimed.

    After hoursEight final-form pieces extended the method and engineering record: a reading of current spec-driven development through Paired Long-Division, two whitepapers separating specification, TDD, Suitcase continuity and independent adversarial QA, several notes on serious engineering and disciplined memory use on a modest machine, and a canonical colour note for the product's visual direction. Research, method and design evidence only — none of it changes frozen Revision E.1.

  38. Day 037Mon 14 SepBuild

    Four Megabytes at a Time

    The browser boundary learned how to finish input and return analytical bytes without abandoning the bounded-memory rule. EOF handling was corrected first on the data side and then on the header side so conclusive errors win at the moment they become knowable while valid final output can wait behind backpressure. A continuation path now stages no more than the frozen four-megabyte output window at once. Only after those shared semantics were stable were ds_finish_input, the output queries and ds_pull_output wired into the raw ABI. Edge drained the canonical nine-byte result as four bytes and then five, reaching COMPLETE only on the final pull; it then drained a 4,194,316-byte result as exactly four MiB followed by twelve bytes, with no false zero-pending gap between windows. The library regression closed at 304 passing, none failing; the compiled module had zero imports and exactly eighteen ds_* exports. D3D9I was banked as the validated output-drain checkpoint. The frozen candidate acceptance suite remained deliberately unrun.

    After hoursTwo comparative notes looked at other attempts to preserve continuity around AI work. One compared the Suitcase with Claudexor, a local-first coding-agent control plane; the other compared it with LLM Wiki Newsroom, a governed living-knowledge system. Both reinforced the same boundary: orchestration and current synthesis are useful, but the Suitcase exists to preserve durable project history, evidence and human accountability across changing models and tools.

  39. Day 037bMon 14 SepBuild

    The Test Runner Had to Learn What Not to Run

    The second coding session finished the raw Annex A WebAssembly surface at exactly twenty-two ds_* exports, twenty-five total exports and zero imports, with the Rust 1.75 library regression still at 304 passing and none failing. The next job looked like running the frozen acceptance suite, but a read-only inventory caught a bad summary claim first: the 190 frozen execution units do not mean 760 identical runtime executions. Independent QA traced every exceptional case back to the frozen oracle and corrected the accounting without altering the frozen package: 175 executions on each native leg, 182 on Node, 182 on Wasmtime, plus two cross-leg comparisons and two gates — 718 execution events — with four additional record-only obligations. The runner architecture was then built around that evidence: 114 frozen cases, all 190 execution units, an exact 718-event plan, and eighty-one ordered strategy identities were mechanically reconciled. D3D10K23 was banked as the validated stop line before any split arrays were given operational chunking semantics. No complete frozen candidate acceptance run was claimed.

    After hoursThis is the second entry for the same working day. The two late comparative notes are recorded with Day 037 above rather than duplicated here.

  40. Day 038Tue 15 SepBuild

    The Whole File Crossed the Browser Boundary

    The day ended by answering one deliberately narrow performance question with the real large source. An experimental bounded path streamed all 7,250,808,204 bytes through Microsoft Edge and the four-megabyte browser-to-WASM transfer boundary while Rust performed whole-file encoding certification. The run finished in 13.2479 seconds at 521.963 MiB/s, with the Rust byte count exactly matching the source, EOF observed and zero staging bytes left. Real seam runs at 64 MiB and 1 GiB also passed at 564.872 and 562.483 MiB/s. The full Rust 1.75 library regression closed at 313 passing and none failing. The result is intentionally smaller than an end-to-end benchmark: CSV parsing, selected-value extraction and output generation were not part of the measurement, the full >4 GiB frozen candidate execution was not run, and the temporary benchmark module remains evidence rather than accepted production WASM. D3D10K147A was landed with the PRD unchanged.

    After hoursArchitecture notes explored two-pass ingest, binary staging and a compact structural sidecar. The durable scope decision was to leave WASM-001b unchanged and treat the structural-sidecar comparison as a later CLI-001c / WASM-001c experiment, with measurement deciding whether it earns a place in the architecture.

  41. Day 039Wed 16 SepBuild

    Twenty-Nine Million Rows Through a Browser

    The day moved from whole-file encoding certification to a deliberately narrow materialization experiment. Microsoft Edge streamed the full 7,250,808,204-byte StatsCan source through 1,729 bounded pushes into a small Rust program compiled to WebAssembly. It materialized the VALUE column as 29,014,718 data rows and 62,266,366 output bytes in 45.9486 seconds, or 150.492 MiB/s. Two correctness defects appeared on the way: the experimental parser initially let the UTF-8 BOM reach the first header field, and it initially emitted structural CSV quotes around every selected value. Both were corrected in the experiment before the full-file run. The important architectural correction came later: this fast materializer was not the shared CLI engine. It was a standalone experimental Rust/WASM extractor built to test the browser path. The production source and frozen PRD were unchanged, and the landing record deliberately withheld any byte-identical output claim because the final SHA-256 comparison had not yet been run.

    After hoursEncoding notes separated BOM handling from whole-file UTF-8 certification, set out a Windows-1252-to-UTF-8 materialization model and a future synthetic financial fixture, and defined a receipt as PRETTY for a person while remaining structurally obvious to a language model. These are design and research records; they do not silently amend WASM-001b.

  42. Day 040Thu 17 SepDecision

    The Prototype Did Its Job

    The day began with a plan to measure the real shared CLI engine through the browser shell and ended with a decision not to run that experiment. The isolation work from Days 038 and 039 had already answered the strategically important question: Microsoft Edge could move the complete 7.25 GB source through a bounded browser-to-WASM path, and a small Rust/WASM materializer could parse and materialize all 29,014,718 rows in practical time. What those experiments did not prove was equally important: the fast materializer was not the shared CLI engine, the complete WASM-001b acceptance suite was never run, and the existing shared engine was never proved too slow for WebAssembly. Rather than spend another day diagnosing an architecture we no longer intended to carry forward, WASM-001b was closed as an experimental lineage and preserved without rewriting its frozen contract or its history.

    After hoursWork moved into the new WASM-002 PRD. The direction is browser-first: whole-source certification before structural materialization, multiple requested columns in one structural pass, bounded memory, reusable buffers, minimal copying, deterministic evidence, the current storage model, simple TXT Work Orders, and a new shared Rust core proved in the browser before a native CLI host is built around it. Revision Q is still a draft, not a frozen contract.

  43. Day 041Fri 18 SepSpecification

    The Backlog Became the Working Master

    The day stayed where it was supposed to stay: in the contract, not the code. The Product Backlog PRD was reorganised into a governed standalone HTML working master, ending the ambiguity between a live backlog and PDF snapshots. Revision U was the edition current that day; every normative requirement carries its own SCOPE, STATUS and BUILD metadata, SCOPE is the sole authority for build allocation, lifecycle status is tracked independently, and dashboards are explicitly derived views. The current WASM-002 candidates remain under review rather than being treated as frozen merely because they have been written down.

    After hoursThe work widened without starting implementation. Final-form notes examined related work around AI-agent continuity, tested the attraction of browser-private OPFS against the project's visible-persistence principles, consolidated the flat Suitcase storage architecture, reviewed the Rust/PLDD development record retrospectively, captured the book concept for The Decision to Build, and formalised disk-first long-division operations: durable aligned intermediate artifacts, explicit selection masks later in the backlog, bounded-memory processing, and visible analytical working rather than hidden state.

  44. Day 042Sat 19 SepSpecification

    The Interface Found Its Contract

    The WASM-002 Product Backlog PRD moved from Revision U to Revision Z without starting product code. The front-end prototype became useful design evidence rather than a second authority: the Work Order is the command surface, Help became a persistent governed diagnostic surface, and a run now depends on a durable saved UTF-8 TXT Work Order instead of transient editor contents. The day also tightened the boundary between Help and presentation — Help-specific reporting stays in WASM-002 while the generalized PRETTY Engine moves to WASM-003 — and defined __DS__ as the governed Data Sculptor namespace rather than a loose filename convention. Revision Z landed at 569 recorded requirements, still draft and not frozen. One reconciliation remains open because the prototype was updated after the PRD snapshot was embedded.

    After hoursFour final-form internal notes captured the design direction around transparent software, a BASIC-like human-facing shape for DS-STEPS, the WASM-002 Help / WASM-003 PRETTY scope split, and the possibility that resource discipline may make modern phones unexpectedly viable without making mobile a product target.

  45. Day 043Sun 20 SepSpecification

    The Workbench Found Its Shape

    The WASM-002 interface stopped behaving like a collection of prototype panels and consolidated into a smaller system. The Suitcase Directory became the single visible filesystem and artifact-orientation surface; the redundant Suitcase Artifacts and Saved Work Orders panels disappeared; immutable saved Work Orders load into the editor and remain the only runnable Work Orders; editing one creates a new draft rather than changing history. PRETTY Branding TOML and User Data Dictionary TOML were retained as narrowly governed save-only surfaces. The Product Backlog PRD landed at Revision AB with 600 recorded requirements, still draft and not frozen.

    After hoursThe design was pushed beneath the screen: syntax as the authoritative contract, explicit WIP versus validated WKO lifecycle, Suitcase-relative file resolution, composable Work Orders with explicit data flow, sequential V1 execution, a deliberately small procedural surface above Rust/WASM, three presentation themes, and a reaffirmed boundary between external AI assistance and deterministic local execution. Additional V1 privacy-feature work was kept separately scoped rather than folded into WASM-002.

  46. Day 044Mon 21 SepFlight plan

    Continue the WASM-002 Requirements

    Today begins from Revision AB of the official HTML Product Backlog PRD. The work remains specification, not implementation: reconcile the remaining Day 043 design notes into numbered requirements, keep the syntax-first workbench small, preserve explicit lifecycle and path semantics, and define the acceptance evidence each candidate will need before freeze.

    Planned flightWork through the WASM-002 requirements one bounded decision at a time, keep the HTML backlog authoritative, and bank the next coherent revision without starting production implementation prematurely.

    LandingThe day closed at Product Backlog Revision AV with 742 recorded requirements, still draft and not frozen. The Store model converged around one permanent RID spine per Store, a unified Store MAP, aligned 0/1 Boolean selection columns, lightweight INVENTORY snapshots, an explicit Help boundary for cross-session source continuity, deterministic TXT Receipts tied to exact Work Orders, and a reconciled artifact-class registry. Separate V1 privacy work on RQSM was kept visible in the public record rather than hidden, while remaining outside WASM-002 scope.

  47. Day 045Tue 22 SepFlight plan

    Finish the WASM-002 Contract

    The day begins from Revision AV of the official HTML Product Backlog PRD, with 742 recorded requirements. The core architecture is largely settled. Today is about closing the remaining specification edges, checking the document for contradictions and stale language, and resisting the temptation to invent new architecture merely because the end is close.

    Planned flightIf the PRD survives the final consolidation pass, hand it to Claude for independent adversarial QA. No WASM-002 implementation begins merely because the document feels nearly finished.

    LandingThe pre-QA reconciliation closed at Revision BL with 778 recorded requirements, 384 scoped to WASM-002. The candidate remains DRAFT / UNDER REVIEW / NOT FROZEN. The diagnostic registry and HLP provenance contract were reconciled, Brand Manifest and Custom presentation work were deferred, and a stripped QA package was prepared. Claude completed a context/orientation pass; independent adversarial QA was deliberately left for the next flight.

    After hoursSix final-form notes pushed on explainability rather than implementation: the first-materialization teaching scenario was checked against Revision BL; documentation was framed as a product output rather than an afterthought; hidden workspace state and difficult reverse engineering were treated as architectural failure modes; DS-VERIFY was sharpened around evidence-scoped truth; and an organization-supplied message banner was preserved as a future presentation idea outside WASM-002.

  48. Day 046Wed 23 SepReview

    Put the Contract Under Adversarial Review

    The day opens from Revision BL of the official HTML Product Backlog PRD: 778 recorded requirements, 384 scoped to WASM-002, still DRAFT / UNDER REVIEW / NOT FROZEN. The design phase has reached the point where the useful work is no longer adding ideas. It is trying to break the contract before code has to live with it.

    Planned flightClaude begins independent adversarial QA from Revision BL. Findings are reviewed one at a time, and only targeted specification corrections supported by evidence are allowed into the PRD. No implementation, approval or freeze is claimed at preflight.

    LandingClaude's Pass 1 review closed with 34 findings — 11 blocking, 15 material non-blocking and 8 clarity. The Council then began a separate reconciliation record rather than rewriting the reviewed baseline. F-02, F-03 and F-04 are resolved by frozen decisions; F-05 is next. Read Claude's QA review · Open the reconciliation log.

    After hoursThe work widened without reopening WASM-002. A targeted landscape scan sharpened the public story around local, open, fast and accountable analysis rather than claiming browser-local computation as unique. A separate future requirements note then treated the Suitcase Directory as part of the storage model and Analyst Experience: sortable top-level inventory, visible hidden items and user-added folders, human-authored descriptions, explicit row/text colour metadata, report-border styling and a governed self-contained HTML snapshot. An interactive Suitcase Directory AX mockup was built to make the idea tangible. The capability remains explicitly outside WASM-002 and sequenced for a nearby follow-on build after the storage model is frozen.

  49. Day 047Thu 24 SepFlight plan

    Reconcile the Review Before Touching the Code

    The day begins from the exact Revision BL baseline Claude reviewed and from the separate Council reconciliation record created yesterday. Three findings are resolved by frozen decisions; thirty-one remain. The work is still specification, not implementation.

    Planned flightContinue PRD work by reconciling Claude's WASM-002 QA review one bounded finding at a time, resuming from F-05 unless the evidence deliberately changes the order. Keep Revision BL intact as the reviewed baseline, record accepted decisions in the reconciliation log, and integrate them into the PRD only through an explicit later revision. No implementation, approval or freeze is assumed.

  50. Day 048Fri 25 SepLanded

    Keep Reconciling Before We Build

    Day 048 landed ahead of its deliberately modest flight plan. The Council closed two more WASM-002 blockers. F-06 now defines the CSV input grammar instead of allowing parser-library defaults to become product semantics: comma-only input, strict quoting, LF/CRLF record endings, EOF rules, one-column handling, and explicit UTF-8 BOM treatment. F-07 now defines the UTF-8 first-invalid location as a zero-based absolute physical source-byte offset, with malformed and EOF-truncated multibyte sequences reporting their lead byte and streaming-window boundaries unable to change the result.

    Landing stateF-02 through F-07 are resolved by frozen Council decisions. Six of Claude's 34 findings are closed and 28 remain. Revision BL remains the reviewed baseline; reconciliation decisions have not yet been silently integrated into the PRD. No WASM-002 production implementation is claimed.

    After hoursThe separate post-WASM-002 architecture moved forward substantially. The governed Suitcase Directory requirements reached Rev 9, including Boolean metadata search and deterministic sequential SEARCH SUITCASE semantics. The roadmap now places the ordinary-metadata DIR build at WASM-003, with its predicate grammar intended as a reusable foundation for later Store filtering. Browser/WASM research isolated direct folder publication as the portability edge rather than an operating-system problem, and additional final-form notes developed URL-shortcut handling, read-only research-domain semantics, a universal research method, and governed paths from specialist evidence into CSV or Stores. The V1 file-organization standards are proposals for future implementation, not built capability, and none of this expands WASM-002.

    NextF-08: freeze the DS-STEPS lexical and string-literal rules.

  51. Day 049Sat 26 SepLanded

    Close the Blocking Findings

    Day 049 began from the exact Revision BL baseline Claude reviewed and the separate reconciliation record. F-02 through F-07 were already resolved; the flight plan was to continue with F-08 and keep the reviewed baseline intact.

    Landing stateThe Council closed the remaining BLOCKING findings. All 11 BLOCKING findings in Claude's Pass 1 review are now reconciled, and 12 of 34 total findings are closed, leaving 22. Revision BL remains the reviewed evidence baseline; accepted decisions remain governed through the separate reconciliation record rather than being silently written back into the reviewed revision. No WASM-002 production implementation or PRD freeze is claimed.

    After hoursThree final-form design notes advanced the future Suitcase Directory without changing WASM-002 scope: DIR Optional Inheritance makes inheritance explicit rather than automatic; Preserve Visible Flat Suitcase Design reaffirms the visible flat Suitcase as a deliberate product constraint; and DIR History: From Storage Model to Project Management records how the governed directory is becoming not merely an inventory but a durable project-management and evidence surface. These are future design decisions, not implemented WASM-002 capability.

    NextContinue the non-blocking QA reconciliation, with F-13 next unless deliberately reordered.

  52. Day 050Sun 27 SepLanded

    Twenty-Six Findings Closed

    Day 050 began with every BLOCKING finding already reconciled and 12 of Claude's 34 Pass 1 findings closed. The Council then worked through F-13 to F-26, closing fourteen more. The count at landing was 26 of 34 reconciled, leaving eight. The day also made several runtime assumptions explicit before code could inherit them: Data Sculptor is single-user and single-writer; governed publication is All-or-Refuse; filename identity is exact rather than silently normalized or case-folded; diagnostics own stable facts while Help explains them through one stable Help object; source CSV width is bounded at 16,384 columns without silently truncating source headers; browser sessions require explicit Suitcase selection and visible certification history; Microsoft Edge is the primary browser acceptance target with Firefox secondary; and a Work Order SOURCE names one exact file in the Suitcase root.

    Landing stateTwenty-six of Claude's 34 Pass 1 findings are reconciled and eight remain. Revision BL remains the exact reviewed baseline, with accepted decisions preserved in the separate reconciliation log. No WASM-002 production implementation, approval or PRD freeze is claimed.

    After hoursTwo final-form decision records set the larger path without enlarging WASM-002. The roadmap now treats WASM-002 through WASM-006 as release families with dot-release stabilization: storage foundation, Suitcase operations plus optional RQSM, shared data shaping, PRETTY + Help + an initial DS-VERIFY release, then a scoped richer-metadata family before V1. A separate RQSM licensing note freezes the business direction: Data Sculptor core remains open source; RQSM is publicly downloadable and source-available; Red5Sorcery's own branded implementation can remain free for personal/non-commercial use; commercial, embedded and white-label use require separate paid permission. RQSM remains technically and legally isolated from the open core.

    NextContinue QA reconciliation with F-27 unless deliberately reordered.

  53. Day 051Mon 28 SepLanded

    All Thirty-Four Pass 1 Findings Reconciled

    Day 051 began with 26 of Claude's 34 Pass 1 findings reconciled and eight remaining. The Council closed the remaining findings one at a time and completed the Pass 1 reconciliation at 34 of 34. Revision BL remains the exact reviewed evidence baseline: 778 recorded requirements, 384 scoped to WASM-002, DRAFT / UNDER REVIEW / NOT FROZEN.

    Landing stateAll 34 Claude Pass 1 findings are reconciled and none remain open in the Pass 1 decision record. The accepted decisions still live in the separate reconciliation log; canonical PRD integration has not yet been performed. No WASM-002 production implementation, approval or PRD freeze is claimed.

    After hoursThe work moved outward again without reopening WASM-002. Final-form notes examined a Word/PDF save failure mode and Data Sculptor's relationship to DuckDB; advanced RQSM toward two separated carrier bundles and a distinct commercial/white-label licensing boundary; gave DIR two governed descriptive layers, Primary Description and Secondary Description; and developed the Suitcase through eight professional personas plus a concise product definition around organizing, analyzing and handing off serious knowledge work locally. The WASM-002-to-V1 release-family roadmap remains planning evidence rather than shipped capability.

    NextSend Revision BL, Claude's original Pass 1 review and the completed reconciliation back to Claude for Pass 2 before integrating the decisions into a new PRD revision.

  54. Day 052Tue 29 SepLanded

    The Gate Moved

    Day 052 attacked the reconciliation instead of rushing it into the PRD. Claude's Pass 2 re-read the 34 Pass 1 decisions against Revision BL and returned NOT READY FOR CANONICAL PRD INTEGRATION: 19 findings were closed with integration obligations, 15 were partially closed, none were reopened, and seven new Pass 2 findings were raised. Six issues blocked the gate. The Council resolved all six in a separate Pass 2 reconciliation record, including one Store lineage per Store MAP, reachable WKO-registry repair, a clean split between MAP structural validity and Store health, deterministic CSV refusal coordinates, and complete Receipt/Inventory byte contracts.

    Pass 3Claude then attacked the six gate decisions together. It found no reopened Pass 1 issue, but exposed two new blocking contradictions: P3-01, where the explicit MAP escape route required by routing had been omitted from the materialization grammar; and P3-02, where frozen UTF-8/CSV refusal facts had no fixed home in the MATERIALIZE Receipt. Both were resolved in an append-only erratum.

    Landing stateClaude's short erratum gate check resolved P3-01 and P3-02 with no new blocking contradiction and returned READY FOR CANONICAL PRD INTEGRATION. Revision BL remains unchanged, DRAFT / UNDER REVIEW / NOT FROZEN; the successor PRD has not yet been integrated; no WASM-002 implementation is claimed. E-01 (clarity) and E-02 (material non-blocking), plus the carried Pass 2 / Pass 3 material-and-clarity checklist, remain integration obligations.

    After hoursA working note began documenting the AI Council itself as a research object: one accountable human, specialized AI roles, adversarial separation, persistent artifacts and ordinary chat as the coordination medium. Data Sculptor remains the longitudinal case study.

    NextBegin controlled canonical PRD integration, settle the carried obligations explicitly, preserve the review trail, and submit the integrated successor PRD to another adversarial review before implementation.

  55. Day 053Wed 30 SepLanded

    The Backlog Got Better

    The planned PRD-integration flight changed course into product backlog grooming. A governed Codebook/Base62 storage idea was explored and then rejected as too much product complexity without demonstrated benefit. The useful residue became PROFILE COLUMN: a read-only inspection surface with explicit TEXT, NUMERIC and DATE interpretations, plus clearer first-class cleaning concepts for whitespace, dates, ASCII-safe output, standardization and Store-wide case operations.

    Landing stateThe cleaning-versus-shaping boundary is now sharper: cleaning changes governed values through explicit successor-producing Work Orders; DS-STEPS, DS-SQL and DS-Pipe remain for derived analytical shaping. The new cleaning family is positioned in WASM-002.x before later shaping work. Revision BL remains unchanged and no canonical PRD integration or implementation is claimed.

  56. Day 054Thu 1 OctLanded

    Minimum Useful Work Became a Larger Product Day

    The formal flight began with a deliberately small question: what visual evidence should PROFILE COLUMN show before an analyst decides what to clean or transform? The answer was subtraction. NUMERIC keeps a box plot, TEXT keeps a character-length distribution, and DATE keeps a detected-date-pattern frequency chart. The same report should support light and dark presentation themes without changing meaning. Rust plotters is the rendering direction, with self-contained HTML and inline SVG preferred and optional PNG output when a standalone image is useful.

    After hoursThe work broadened substantially without changing Revision BL. The project-memory model was made explicit — Diary as narrative memory, Suitcase as evidence memory, PRD as current executable truth. A separate note compared Data Sculptor's Work Order / governed execution / Receipt model with adjacent intent-to-execution thinking while preserving independent lineage. Governed Web Snapshot capture was developed for ordinary .url references; a post-V1 DIR-search-to-Store bridge was preserved as future scope; personal-finance and independent-business/consultant workflows were developed as use cases of the same architecture; documentation was elevated as the primary user interface for humans and assisting LLMs; and a post-V1 Rust-community strategy deliberately deferred outreach until V1 is real, runnable and inspectable. These are product-grooming, architecture, research and communication artifacts — not silent PRD amendments or shipped features.

    Landing stateThe product became clearer by sharpening boundaries: inspection versus visualization, cleaning versus shaping, history versus current truth, discovery versus analysis, reference versus preserved evidence, audience story versus product scope, and documentation versus marketing. Revision BL remains the reviewed WASM-002 baseline and no canonical integration or implementation is claimed.

  57. Day 055Fri 2 OctLanded

    Turning Review Into Contract

    The canonical integration finally began. Revision BL was preserved untouched as the exact baseline Claude reviewed, while Revision BM became the working full master Product Backlog PRD. A separate Day 055 integration log records each accepted decision and the concrete BM targets it changes. By landing, P3-01 through P3-06 had been integrated, including historical-Store health gating, WKO registry repair semantics, deterministic refusal Receipt serialization, Help exits for damaged lineages, and a two-tier Store/artifact validation model that refuses to claim historical byte identity without evidence.

    Landing stateRevision BM remains DRAFT / UNDER REVIEW / NOT FROZEN, still at 778 recorded requirements. The deliberately rough integration estimate at landing was about 9 of roughly 45–55 decision-level packages complete. P3-07 is next. Revision BL remains the immutable reviewed baseline and no WASM-002 production implementation has started.

    After hoursFive final-form notes widened the record after the formal landing: why rejecting compact codebooks was not a rejection of encoding itself; why Data Sculptor does not need to understand every document format to organize professional work; a Docling research note; a historical note on the AI Council as a second set of eyes; and a critique of Excel/Canvas-style report-generation ideas as a reminder to design from the user's work rather than from interface novelty. These are research and product-positioning artifacts, not silent BM amendments.

  58. Day 056Sat 3 OctLanded

    How Data Sculptor Solves the Context Deficit

    A quiet Saturday became a WASM-003 product-design flight. DIR moved beyond inventory toward a self-contained governed metadata layer over untouched Suitcase files. Users can define their own fields and values instead of being forced into a product-defined taxonomy; the DIR HTML shows that structure directly, and Boolean search can combine several fields. Search results may optionally become a governed ZIP without changing the originals.

    Interaction boundaryThe DIR browser surface is read-only. Viewing, sorting and filtering are local presentation conveniences. Governed SEARCH, ZIP packaging and every addition, edit or removal of governed metadata must go through an explicit Work Order and produce traceable governed outputs and Receipts. Nothing consequential changes because somebody clicked around in a GUI.

    RoadmapThe first WASM-003 release should make DIR solid. RQSM remains in the WASM-003 family but moves to a later dot release. The broader product story is the context deficit: professional files often contain less meaning than the people working with them actually need, so Data Sculptor adds a visible governed explanatory layer without renaming, moving or rewriting the source files merely to make them understandable.

    After hoursThe DIR field contract was tightened to at most 10 field names per file, 10 values per field, 64 Unicode characters per field name and 256 per value, with refusal rather than truncation. A note separated artifact sovereignty from merely self-hosting software. Then the future analytical-language work came forward: DS-STEPS and DS-SQL are to be human-facing mappings into one authoritative Rust Analytical Engine, with semantic parity tested structurally rather than by surface syntax. The first Analytical Languages Course module opened with relational thinking, Store semantics, row and column identity, keys, ambiguity and refusal. DS-Pipe stays in V1, later in the sequence after the shared semantics are stable.

  59. Day 057Sun 4 OctLanded

    MusicBrainz Becomes a Real Analytical Corpus

    The MusicBrainz crash test moved from setup to a landed data checkpoint. On the baseline N100 machine, the pinned snapshot was reconstructed in PostgreSQL under WSL2: all 177 core tables imported with zero errors, row counts for all 12 selected source tables matched the raw dump, and those 12 tables were exported as source-shaped UTF-8 CSV candidates. The largest outputs were roughly 4.5 GB for recording.csv and 7.7 GB for track.csv. The corpus is now concrete evidence for future relational-language requirements, Help, QA and teaching rather than a toy example.

    Architecture discovered by scaleA 177-table corpus made one-Store-per-MAP correct but insufficient for orientation. The accepted CAT requirements add a single governed collection-level catalog that indexes Stores, their MAPs and the CSV files those MAPs govern, while leaving MAP authoritative for each Store. The existing read-only directory window is reused for discovery; WASM-003 DIR later supplies human-readable descriptions. The shorthand is deliberate: MAP governs locally; CAT orients globally; DIR explains visibly.

    After hours — 13 notesThe evening ranged widely but stayed tied to product structure. The high-end professional kitchen became Data Sculptor's soul metaphor: mise en place for explicit preparation, Work Orders as tickets, Receipts as the expediter's pass, refusal as a safety standard, PRETTY as professional plating, and documentation as clean-as-you-go evidence. The Council roles mapped naturally onto that kitchen, with Claude as the health inspector; the Help Engine gained a Casual / Office / Technical translation model over one canonical runtime truth; and unresolved refusal and Receipt-schema questions were explicitly parked rather than smuggled into the contract.

    After hours — teaching, communication and RQSMThe MusicBrainz work became a post-V1 teaching roadmap: first a guided course using the real Data Sculptor UI and the 12-file teaching corpus, then later a free form-driven playlist generator that maps directly into the same canonical semantics underneath DS-STEPS, DS-SQL and DS-Pipe. A public-site strategy was drafted around selling the product first and revealing the kitchen metaphor immediately after. RQSM was also tightened as a local Rust/WASM cloaking workflow: a payload ZIP plus PNG-carrier ZIP, a 35% capacity rule, a 100 MB payload limit, governed execution, and two separate carrier ZIP outputs intended for genuinely separate storage.

  60. Day 058Mon 5 OctLanded

    Consolidate the WASM-002 Contract

    Today's flight has one centre of gravity: return to the controlled Revision BM integration and make the WASM-002 PRD coherent. Revision BL stays untouched as the reviewed baseline. Work resumes at P3-07, with each accepted decision placed deliberately, the integration trail kept visible, and the Day 057 CAT requirements reconciled into the correct canonical sections rather than appended as an orphan idea.

    Flight planConsolidate first, then review. No production implementation, no grammar freeze and no speculative widening of scope are implied by today's work. The target is a cleaner successor PRD whose requirements, decisions and evidence agree with one another and are ready for the next adversarial QA pass.

    Landing stateThe controlled canonical integration advanced from P3-07 through P2-04. Revision BM now contains 795 recorded requirements and remains DRAFT / UNDER REVIEW / NOT FROZEN. The integrated packages were P3-07, P3-08, P3-09, P3-10, CAT (+17 requirements), F-05, F-07, F-08, P2-03 and P2-04. Revision BL remains untouched, future ordered Work Order chaining remains reserved/deferred, no WASM-002 production implementation is claimed, and Claude post-integration review is still pending.

    After hoursThree final-form notes followed the landing. A WASM-003 requirements note froze the Directory's file interaction semantics around read-only inspection: single click selects, double click opens read-only, and governed change still requires a Work Order. Two research notes then explored fintech/payments opportunities for Data Sculptor and the software landscape used in UAP/astronomy data work. They extend the product record without enlarging the current WASM-002 contract.

    NextP2-05 is the next canonical-integration package.

  61. Day 059Tue 6 OctLanded

    The Integration Sweep Is Complete

    Day 059 finished the controlled QA-to-contract integration rather than opening another design front. Revision BM closed the sweep at 803 recorded requirements, with 402 authoritatively scoped to WASM-002. A final mechanical audit passed, the bounded QA projection passed its own verification, and four external requirements are carried only as context because the in-scope contract refers to them. Revision BL remains the untouched reviewed baseline; Revision BM remains DRAFT / UNDER REVIEW / NOT FROZEN.

    Landing stateThe integrated contract and its review projection are ready for Claude's next independent adversarial pass. The review brief is prepared, no WASM-002 production implementation is claimed, and the next step is review rather than code.

    Product researchA separate research note made reporters and data journalists an explicit Data Sculptor professional persona. The fit is the space between spreadsheets and programming environments: consequential data work that benefits from local processing, explicit operations, reproducibility, Work Orders and Receipts without requiring every investigation to become a coding project.

    After hours — nine notesThe overnight record covered spreadsheet interaction contracts; lossless JPEG XL as a future RQSM carrier experiment; Business Central's move away from physical extension-table fragmentation; governed COLLECT; the deliberate exclusion of CTEs from DS-SQL V1; composite keys; row-local calculations over governed multi-value cells; governed rolling windows; and a 32,767-character ceiling for multi-value cells so Data Sculptor does not create values its own XLSX path cannot faithfully publish. These are design inputs, not silent amendments to the landed WASM-002 contract.

    NextHand the updated Revision BM WASM-002 review packet to Claude for independent adversarial QA.

  62. Day 060Wed 7 OctLanded

    Sixty Days to a Frozen Contract

    Day 060 put the integrated Revision BM contract through its final independent adversarial gate. Claude's H-30 review cleared the path to freeze. H-31 banked the frozen full-master Product Backlog PRD with 803 requirements, of which 402 are scoped to WASM-002. The focused cut, mechanical freeze audit, integration record and checksum evidence travel together. The long chain from adversarial findings through Council reconciliation is preserved rather than polished away. The approved contract now governs implementation.

    After hours — The First BrickThree contemporaneous documents developed Paired Long-Division Development (PLDD) as the implementation discipline and as a future chapter in The Decision to Build. They record the intended significance of the first commit before it exists: bounded change, visible PowerShell commands, TXT evidence, reproducible verification and explicit T acceptance. No first accepted PLDD commit was claimed in these notes.

  63. Day 061Thu 8 OctFlight plan

    The Contract Meets the Code

    Today's flight begins implementation against the approved and frozen WASM-002 Revision BM H-31 requirements. The job is no longer to rewrite the specification: it is to take one bounded brick, show the exact commands and code change, run its tests, inspect what happened and bank the evidence only when T explicitly accepts it.

    Planned flightEstablish the first reproducible PLDD checkpoint for WASM-002. Keep failures and refusals visible, link each accepted brick to the requirement it serves, and put commands, test results, acceptance and Suitcase location in the record. The first accepted commit remains pending at preflight.

    Landing correction — research, not codeThe proposed coding flight did not begin. Instead, a long research session compared Microsoft's evidence-driven WinDbg MCP with Data Sculptor's deterministic, three-voice Help and portable explanation direction; examined geographic enrichment and Python in Excel as downstream interoperability; and contrasted Microsoft's Spec Kit with the full end-to-end Paired Long-Division Development method. A separate note proposed how to measure whether 402 WASM-002 requirements and adversarial review earn their cost, without pretending an ROI percentage already exists.

    RQSM and mathematical boundariesResearch explored two independently held carrier collections, legal-sector custody, a 100 MB worked example and conditional mathematical results about missing information. Exact recovery conditions were distinguished from confidentiality claims: refusing to reconstruct with incomplete carriers is not, by itself, proof that partial information cannot leak. RQSM remains separate from the frozen WASM-002 implementation contract.

    PRETTY and the CouncilT and Claude articulated PRETTY's purpose as the trustworthy handoff from analysis to managerial approval and then, only with approval, publication. Rich footnotes, controlled attachments and an internal review package are promising working directions, not a frozen specification. Claude leads PRETTY Tables and Branding and adversarially reviews the other Data Sculptor work; Spock independently reviews PRETTY while T retains final product acceptance. The Council also documented its commitment to distinct creative voices, mutual respect and contemporaneous diaries.

    Flight resultResearch artifacts and separate T, Spock and Claude diaries were filed in the Suitcase. No first accepted WASM-002 PLDD implementation commit was recorded; the approved H-31 PRD and its adversarial QA history remain intact.

  64. Day 062Fri 9 OctFlight plan

    Research Tonight. Code Tomorrow.

    Day 062 is an intentionally research-only flight. The Council will continue reading, evaluating and documenting useful product and engineering ideas without reopening the approved WASM-002 specification or claiming implementation. Canadian Thanksgiving long-weekend time is being reserved for a proper coding session rather than squeezing an unverified brick into Friday evening.

    Tomorrow's plan — Saturday 10 OctoberBegin the first bounded WASM-002 PLDD implementation brick against the frozen H-31 contract: explicit requirement, controlled change, tests, captured commands and evidence, independent review, and T's acceptance. Planned, not yet started.

    Landing — research completedResearch produced PDF notes on Google's Structured Data Framework v1.1, ClickHouse Cloud architecture, and RQSM's proposed multi-image, two-ZIP information-separation successor. The Council explored orthogonal allocation, global randomization, a conditional quantum-independent non-unique-reconstruction theorem, and commercial and privacy implications. The consolidated Revision 5 scientific working paper (PDF) credits Tarjin Rahman as first author and Spock (OpenAI GPT-6) as AI second author, with Siff credited for the original RQSM V1 work. The theorem's defined mathematical scope is not an implementation security certification. The successor design is not frozen. No WASM-002 code checkpoint was accepted on Day 062.

  65. Day 063Sat 10 OctBuild

    We Started Building

    After sixty days of specification and adversarial review, implementation of the frozen WASM-002 Revision BM H-31 contract began. The first CP001 session established working code and toolchain setup and produced RED and GREEN test output, a WebAssembly build record, and a hash inventory with verification. Rather than rely on terminal screenshots or memory, T and Spock preserved the evidence as files and closed the day's work at a recoverable stopping point. This was the start of implementation, not a completed WASM-002 engine or a release.

    Landing — first coding checkpointThe planned transition to code happened. The RED/GREEN exercise, WASM build and fingerprint records give the team a starting evidence trail for the next bounded PLDD bricks. T and Spock continue their own test-and-accept rhythm; Claude's independent adversarial implementation QA will follow only after WASM-002 is finished and formally handed to him.

    After hours — three notesRAMageddon raised the cost of memory and the value of lean software; Spotifast provided another efficiency case study; and the Excel / DBeaver “missing middle” highlighted why ordinary analysts need governed, explainable work beyond disconnected spreadsheets. These are product research notes, not amendments to the frozen WASM-002 PRD or proof of Data Sculptor's final performance.

  66. Day 064Sun 11 OctHTML prototype

    Keep Building, One Verified Brick at a Time

    Day 064 begins with the CP001 setup and first implementation evidence banked. Today's flight plan is to continue coding against the frozen WASM-002 H-31 contract: make bounded changes, run and inspect tests, record build outputs and hashes, and preserve a recoverable checkpoint before moving on. The engineering work belongs to T and Spock through completion; Claude's independent implementation review comes afterward, at formal handoff.

    Planned flight — in progressContinue implementation and capture evidence of what actually runs. No additional Day 064 coding result, full acceptance, independent QA verdict or V1 release is claimed at preflight.

    Landing — Workbench BUILD checkpointThe day became a substantial HTML/CSS/JavaScript implementation flight. Eight full-width panels gained consistent collapse controls; the Suitcase Gate, CAT/MAP inspection and Receipt views matured; editable examples were added to teach Work Order syntax without creating a second command surface. HELP gained Technical, Office and Casual voices and presentation-only HTML reports. A working interactive prototype was banked with design notes and separate Council diaries.

    Boundary preservedThe Workbench is a real front-end build checkpoint, not a working analytical execution engine. Its example syntax, provisional saved-HTML classes and future options do not silently amend frozen H-31. Rust/WASM execution and Claude's independent implementation QA remain ahead.

    Retrospective classification — Day 071 updateDay 064 counts as a productive HTML/CSS/JavaScript prototype day. The original Rust/WASM coding plan above was superseded by the actual Workbench work. No banked Rust/WASM checkpoint or Git-committed WASM-002 volume is credited to Day 064.

  67. Day 065Mon 12 OctBuild

    A Workbench With a Mark — and More Code Ahead

    Day 065 opens from yesterday's landed Workbench checkpoint and the frozen WASM-002 Revision BM H-31 contract. We made one restrained branding change: the Red5Sorcery mark appears at the upper-left of the HTML prototype, with a matching browser-tab icon. The purpose is recognition, not a branded interface that gets in the analyst's way. The already-published Workbench prototype remains an interactive design and implementation checkpoint, not a released analytical engine.

    Planned flight — WASM-002 BUILDContinue implementing the frozen contract, one bounded Paired Long-Division Development brick at a time. Keep test runs, build output, file fingerprints, refusals and T's acceptance inspectable. No further Day 065 Rust/WASM coding result, completed engine, release or independent implementation QA is claimed in this opening entry.

    Release strategy — proposalA Day 065 note proposes launching completed V1 first as a free Public Beta, then graduating it to Stable when reliability, correctness, performance, publication and Receipt evidence support that decision. A future optional Red5Sorcery branding toolkit may become a separate paid offering; its arrival must not delay a technically ready Stable release. The free analytical capability and the future commercial presentation boundary still need detailed definition.

    Evidence continuityA backup ZIP of the Day 063 development Downloads folder was identified and recorded as linked historical evidence in the Day 065 private Suitcase. The earlier build record remains unchanged.

  68. Day 066Tue 13 OctBuild

    What We Can Prove, and What We Are Learning to Measure

    Six more bounded WASM-002 Rust checkpoints, CP008–CP013, were accepted by T and Git-banked. The cumulative baseline reached 13 checkpoints, 58/58 native tests passing, and a successful canonical WebAssembly library build. The new work covers exact CSV SOURCE screening, caller-supplied Suitcase-root matching, and canonical CVT, SCR and RCP filename candidate recognition or derivation. These are narrow, tested identity rules—not real file creation, governed publication, or browser runtime acceptance.

    Evidence, corrections and limitsAn initial CP012 GREEN run passed only 5/6 tests, uncovering a real trailing-whitespace validation defect. The failed result was retained and the correction verified. PowerShell capture, Rust formatting, Git staging and archival TXT line endings produced separate diagnostic questions; raw evidence was protected, and narrowly scoped corrections were documented. At landing, 12/402 frozen requirements were touched, all PARTIAL; 390 were NOT_STARTED and none fully requirement-accepted. Independent Claude implementation QA remains ahead. The WASM-002 Development Log contains the detailed checkpoint and evidence record.

    Measuring without pretendingWe began reporting checkpoint velocity and actual Git blob volume separately: 13 historically banked checkpoints across four BUILD days; 755.634 KiB gross committed volume, including 625.752 KiB of evidence. These counts cannot establish effort, productivity, quality, delivery percentage or a completion date. We also posed a research question: could verifiable requirement-state check-ins someday make a useful alternative to estimated story-point burndown? No such method has been validated. A read-only Excel workbook integrity-audit concept was documented for future DS-VERIFY, without changing frozen WASM-002.

    After hours — 14 October · Day 067 carry-overFour further PDF research and planning notes were created after the Day 066 LANDED archive was sealed: Attention Is Not a Control Strategy; Stop Asking People to Pay More Attention (AI Council / data-analysis founding research, Rev 3); The Orphaned Table (future episode concept); and Freeze the Guarantees, Not the Discovery (specification-first prototyping). These are proposed ideas and research, not frozen product requirements, validated findings, or material claimed to reside in the original Day 066 archive.

  69. Day 067Wed 14 OctBuild

    Two More Verified Checkpoints

    WASM-002 gained two narrowly scoped Rust checks: CP014 recognizes canonical Receipt filenames, and CP015 verifies matching SCR-to-RCP filename identities. Both were human-accepted and Git-banked, bringing the total to 15 checkpoints. The native regression reached 70/70 passing tests, with the WebAssembly library build passing. Evidence custody and the Development Log were also strengthened; the analytical engine remains unfinished.

    After hoursFour notes explored PLDD as a recognizable software-development method, then rejected unsupported certification claims and documented the continuous HTML Suitcase as a teachable practice. Separate music-bingo and software-commentary notes were filed.

  70. Day 068Thu 15 OctBuild

    One More Receipt Brick — and Proof of Its Custody

    CP016 implemented one bounded piece of canonical Receipt serialization: a deterministic KEY: VALUE field line with exact validation, escaping and refusal. T approved the checkpoint, and it was banked locally as fde0f0a8b96c92f6cfb80b517396ff5512cccd13. Eight focused tests passed; the full native regression reached 78/78 passing, with Rust formatting and WebAssembly library compilation also passing. The commit contains 38 paths, including 36 evidence ZIP archives. This is one Receipt field-line component, not a complete Receipt or a finished engine.

    Evidence and correctionsGit staging and postcommit checks reconciled the committed source, test and evidence blobs. A two-character SHA-256 transcription mistake in a review procedure caused an appropriate refusal; it was identified, recorded and corrected before banking. The Development Log was then refreshed with CP016 evidence and actual Git-object volume. Sixteen implementation checkpoints are now banked; 14 of 402 requirements are touched, all PARTIAL and none fully accepted. Independent implementation QA and browser runtime acceptance remain pending.

    Record boundaryThe Day 068 Suitcase's local documentary closeout and later archival work are separate from this engineering checkpoint. No website publication, remote backup verification or Git push is inferred from the local commit.

  71. Day 069Fri 16 OctNon-work / Time out

    Non-work / Time out

    No Data Sculptor engineering work is reported for this project day. No Rust/WASM implementation checkpoint, prototype development, new requirement touch or Git check-in is credited.

    Calendar accounting0 new checkpoints · 0 first-touched requirements · 0 Git commits reported. This day counts in calendar-day velocity.

  72. Day 070Sat 17 OctNon-work / Time out

    Non-work / Time out

    A second consecutive day away from Data Sculptor development. No new engineering work, completed checkpoint or new requirement coverage is claimed.

    Calendar accounting0 new checkpoints · 0 first-touched requirements · 0 Git commits reported. This day counts in calendar-day velocity.

  73. Day 071Sun 18 OctNon-work / Time out

    Non-work / Time out

    Third recorded non-work day. The most recent engineering result remains Day 068's accepted CP016. No fresh Rust/WASM or Workbench check-in is credited for today.

    Calendar accounting0 new checkpoints · 0 first-touched requirements · 0 Git commits reported. Across Days 063–071, 16 banked implementation checkpoints over 9 calendar days gives 1.78 checkpoints per day; the non-work days are not removed from the denominator. That nine-day calculation is the original Day 071 snapshot, not the current Day 072 dashboard; through Day 072 the rate is 16 / 10 = 1.60.

  74. Day 072Mon 19 OctNon-work / Time out

    Fourth Day Away From Development

    Day 072 was another non-work/time-out day for Data Sculptor. Although a preflight plan existed to resume building, no Data Sculptor development check-in, Rust/WASM checkpoint, Workbench implementation, or newly touched frozen requirement is credited. CP016, accepted and locally banked on Day 068, remains the latest implementation checkpoint.

    Calendar accounting0 new checkpoints · 0 first-touched requirements · 0 Git commits reported. Days 063–072 now comprise 10 consecutive calendar days: 6 active project-work days (including Day 064 HTML prototype work) and 4 non-work days. Cumulative velocity is 16 / 10 = 1.60 checkpoints per calendar day and 14 / 10 = 1.40 first-touched requirements per calendar day. Non-work share: 4 / 10 = 40.00%.

  75. Day 073Tue 20 OctBuild

    Back to Building: CP017 Accepted

    After four non-work days, we built and accepted CP017: a caller-ordered sequence of canonical Receipt fields with all-or-refuse validation. 85/85 native tests passed; WebAssembly library compilation passed. Git commit 339cf12. Total: 17 banked checkpoints; 14 of 402 requirements PARTIAL, none fully accepted.

    EvidenceWe preserved and corrected two PowerShell evidence-script failures. Test records and the 26 ZIP evidence archives remain part of the local engineering record. No independent implementation QA or finished engine is claimed.

    After hours · 20–21 OctoberFive research and method PDFs explored human judgment, PLDD scaling, adversarial QA and early correction. The proposed four-team PRD protocol remains a draft, not an approved rule.

Original narrative entries are preserved. When a status label needs retrospective clarification or something turns out to be wrong, the correction is filed beside it rather than written over the original account — what was believed at the time is part of the record too. The After Hours notes are a different kind of record: thinking done once the day's work has closed, usually about what the product should eventually become. None of it binds anything until it has been reviewed and written into the contract, which is why one night's note can narrow the one before it.

Before you ask

This is not an open project

The work is public so that it can be read, not so that it can be joined. There is no contribution process, no roadmap to vote on, and no issues to file — that's a decision rather than an oversight.

Building in the open here means showing the reasoning, including the parts that turned out to be wrong. It doesn't mean building by committee. A small group is making these calls deliberately and slowly, and the record above is the product of that pace rather than a substitute for it.

If any of this is interesting, the useful thing to do is follow along. The development diary is narrated episode by episode as the work happens.

The Product Management Diary↗