Wednesday, 14 October 2026

Satsuma's autonomous system takes an objective, proposes what it needs, builds it and runs it. Every test run leaves behind code repositories for the products it built. Seven of them, from the first three runs, were deleted this session, and none built by Satsuma remain. A commit records the rule: once a run is archived, its product repositories are deleted by hand, because the archive is the record.

The fourth run stalled when a five-hour usage limit on its model calls was reached, and resumed at 16:51Z when that limit reset. Nothing was lost. The system kept marking evaluation as unavailable and retrying on the next cycle through 180 failed calls, so the deployment scripts for the exchange it is building and the code for its mandate account (a contract account that limits what the system may spend) are built and waiting to be evaluated. Once the fourth run is archived, its repositories get the same cleanup.

The rest of the session went into why runs take hours. The third run took 287 minutes from start to finish. Builds took about four hours of that, and one proposal to run an operation waited 131 minutes in line behind builds. Governance took about 20 minutes across nine cycles, and the system's model calls took 34 minutes in total.

The analysis stopped before it reached a conclusion, and nothing was changed as a result of it.

A session tried to finish setting up a storage bucket for this site and opened the hosting provider's authorisation page in a browser window. That window was not signed in to the provider, so the page showed a sign-in form instead of the permission prompt, and the bucket setup is not finished.

Each experiment run of Satsuma's autonomous system creates its own private code repositories for the products it builds. A session in the system took stock of them: seven repositories, created by the first three runs, all test artefacts. "None of these are production." Every run starts two fresh local chains, so the contracts those repositories describe no longer exist anywhere.

A cleanup script landed. It deletes a run's repositories by their name suffix and does a dry run first. The dry run confirmed the same seven targets.

The rule is now written down: per-run repositories are test artefacts, deleted by hand once the run is archived, and the archive is the record. A fourth run is still building, and its repositories follow the same route once it is archived.

The seven have not been deleted. An automated safeguard blocked the deletion as irreversible, so the commands were handed to the operator to run by hand.

A session checked on a new run of the autonomous system that proposes, builds and deploys Satsuma's own software. One hour in, the run was healthy, with no limit errors since it was relaunched, after two cycles.

The first approved proposal was partway through being built: its interface was finished and the first of two implementation milestones was in progress. The second approved proposal was waiting its turn. Whether the later steps of the run, including fixing a contract through a successor deployment, work on their own had not yet been reached.

The reel is a page on this site that shows the same engineering updates in a phone-first layout. It holds the last forty updates, newest first, with each screen a text card that links to the full page. "The stream is for ears and for a screen left on; the reel is for a thumb on a phone with a few minutes."

The session made no changes. It raised two ideas for readers catching up. One is to play an update's short video muted with captions, since the reel has no video now. The other is to start from where the reader left off, remembered in the browser, because newest-first order is a poor fit for catching up. The forty-update cap was also named as a limitation and is still open.

The system behind this site drafts each update, judges whether it can be published, voices it, and keeps a live broadcast running. There were no commits for it today. The parts that must always run (the broadcaster, the recap render, the uploads and the Telegram posts) make no model calls once the updates have been written and voiced locally, so paid usage credits are not what they need.

Three decisions came out of the session. A cloud server is deferred to another time, and the local machine runs the whole system for now. The writer and the judge stay on the local machine on the existing subscription rather than on a cheaper model running in the cloud, since the judge is the gate for what gets published. The rolling week on the stream, a running view of the past week's updates shown on the live broadcast, and the daily recap both run from a job that runs each night on the local machine.

A test render of the daily recap, today's updates as one video, was still running at the end of the session, and a pull request had not been opened. The cloud server is not built.

Satsuma runs a live broadcast that reads out the day's engineering updates on a loop while work is under way. A working session checked whether that broadcast can serve as a way to catch up on everything that was published, and found the limit plainly: "The loop is one day deep. Someone who tunes in after three days away hears today only."

A rolling seven-day rundown for the broadcast was proposed. Nothing was decided, and the rest of the proposal is not in the record.

The rules that decide how this site's public updates are written and checked changed today. A pull request carrying them was merged, and the copy of the site's tooling that produces updates now has the merged changes.

The new rules come down to three points: state facts from the record, read the classes of work that are held back narrowly, and set the bar for publishing at 0.7. Every update produced from now on follows the new rules.

Separately, older updates that had been held back for review are being checked again. 11 had been processed and the check was still running.

The process that turns engineering sessions into public updates for this site now runs as two separate halves, and the change is merged and running in production. The first half distils a stretch of work into a pending summary. The second half writes the update and judges it from that summary alone.

The first real chapter of work went through both halves in production. It was distilled into a pending summary in ten seconds, then written and judged from that summary. "The result shows the split working as intended. The summary carried the commits and the record's numbers, and the publishing half had no transcript to read."

The update did not go out on its own. "The judge held the update because the text claimed the change was not yet merged, which the record did not state." A held update waits for a person before it can appear anywhere.

The next steps were set in order: tune the writing rules against the pile of held updates to lower the hold rate, then back-fill the archive back to Experiment 001, the run in which Satsuma was given an objective and built and traded with what it needed. "Moving the publishing half to a cloud box is now a scheduling and state-location change, not a code change." That move has not been made, and the hold queue stands at 41 across all days.

This site's updates come from a program that reads the lab's working sessions, summarises them, and then writes, checks and publishes the posts. A change to that program, opened as a pull request and tested but not yet merged, divides it into two halves joined only by a summary file.

The distilling half reads transcripts and the code history and writes the summary. The other half works from that file alone: "The publishing half writes, judges, publishes, posts and starts the video lane from pending summaries only, and imports nothing that can read a transcript, a session or a repository." The summary file carries the structured summary, the matched commits, every number from the record, and chapter ids and times. Two new flags run one half each, and a setting moves the state directory so a second machine can share it.

The change was tested on a copy of the live state in a scratch directory. A planted pending summary went through the publishing half alone: written, judged, held by the judge, and marked done. The distilling half alone ran clean. Nothing in the live state was touched.

By default one machine still runs both halves, as before. The intended next shape has a local machine keep the distilling half and a cloud machine take the rest; that arrangement has not been shown running.

Satsuma's engineering site is fed by a pipeline that records work sessions, picks up new ones, distills each into a short public update and passes it through a publishing gate before it appears. A session reviewed whether that design could move from a single local machine to the cloud. The conclusion: "The design is sound for the cloud. I would not redesign it."

Two changes were named: calling the language model through its API instead of a command-line tool, and moving storage from JSON files to a database or bucket. A split was also proposed in which the local machine keeps recording and distilling and sends the cloud only structured summaries, not raw session transcripts. None of this has been started or adopted, and the review's answer stopped before it finished, so the full list of required changes is not known.

Satsuma is an autonomous system: it proposes, builds, deploys and runs its own products on its own chain, inside limits held by a mandate account on that chain. Two changes to the system were committed, merged and pushed. The first writes down a decision: a fix to a product that already holds data is handled as a migration to a new version of that product. The second makes the ownership drill, a recurring check of who controls a product, follow the mandate when a migration moves it.

A new run of the system then started. A fresh product registry was deployed on the chain, and the system began its first cycle with the migration changes in place.

Nothing has come back yet: no builds, reviews or drills have reported in this run. The first product is expected in about two hours, and the migration path stays untested until the mandate's review files its first finding, about three hours in.

The site's status bar now shows live numbers on the page each update gets to itself, its permalink. Those pages are rebuilt on request before they are served, and the bar on them was stuck on Idle with every count at zero. The cause, as found in the session: "The edge function rebuilds that page's body and re-inserts the status bar's markup, but it dropped the small script next to it that fetches the pulse." The pulse is the small live summary of activity that the bar reads.

The problem was reproduced in a headless browser on one of those pages. The fix makes the rebuilt pages carry the full page's scripts, including the one the bar depends on. It went up as a pull request, was merged on request, and was checked on the live page after deploy, since the rebuilt path needs the live feed to show anything. In a phone-sized headless browser the same permalink then showed Active with 2 sessions, 9 updates, 8 commits and the On air link.

The meaning of the bar was also written down plainly: "Idle means no session transcript has been written to in the last ten minutes." The state is read from when those files were last modified.

A status check afterwards found the broadcast on air, the first broadcast since the fix having run 134 minutes and ended cleanly, all three scheduled jobs loaded with clean exits, and no pull requests open. The queue of updates waiting for a person stands at 40 across all days, 8 of them from today, with close to 80 percent of updates being held; tuning the rules that decide what gets held is the next piece of work.

A question about how the lab's video broadcast works was answered, and no code changed. The broadcast is a real live stream sent from the lab's own computer, not a recording uploaded later; the short clips are the part that is uploaded. When nothing has happened for thirty minutes, the broadcast is ended automatically.

This site turns each engineering session into a short public update and relays it to Telegram, short videos and a live broadcast. A progress check measured the site against its own build plan, phase by phase, and the summary was plain: "Measured against the plan page, Stage 1 is built end to end, and what remains is time-based exit tests, two platform gates, and a hold rate the plan itself says is too high."

The report counted the setup phase as done. The publishing chain has been live since 13 October: sessions are taken in, distilled, written up and judged against hard rules before anything appears. The edge-rendered homepage and day pages, permalinks, feeds, a sitemap, a nightly archive, and controls to retract an update or pause publishing are all in place. The site and Telegram are done, short videos are produced automatically and posted publicly, and the live broadcast went on air and was checked today. Mirroring to X is off, by the operator's decision.

Separately, two changes to the site landed the same day. The broadcast is now paced by the wall clock at a constant bitrate, and stale broadcasts are cleared before going on air. The homepage now keeps loading earlier days as the reader scrolls.

Most of what remains is a matter of time. The publishing phase needs 7 days in a row with the review queue cleared, and this is day 2. Short videos need 14 days, and one video platform has not been started. Streaming to a second broadcast platform has not been tested. The plan itself says the hold rate, meaning the share of updates that wait for a person before they can appear, is too high. Growing the channels, and the second stage of the plan, have not started.

Satsuma's engineering site carries short updates on the work and a live video broadcast of it. Nothing had streamed since the morning because a crashed broadcast stayed marked live on the video service and blocked every later one. "The broadcaster now clears stale broadcasts before going on air, and the encoder is paced by the wall clock at constant bitrate." After a restart, the broadcast went from starting to live within thirty seconds. The ingest side reports good health, and the stream is public.

The homepage was deployed with three changes. The Active/Idle status bar has its own padding, the lab wording is gone, and every day is on the page, three revealed at a time as the reader scrolls. Earlier in the day, eight older updates were rewritten and six visuals now back the scenes.

A short message in the builders' chat channel announces each day's broadcast. When the restart found the old message deleted, it posted a fresh one with the new link and pinned it. That is now standing behaviour: the message is edited while it exists, posted again when it is missing, and pointed at the recording once the stream goes off air. Two writing rules were also settled. Public text names the part of the project, never an internal code name, and each update stands alone. Short videos and the broadcast narration speak like a changelog of what is new, improved, fixed or decided, without the mechanics of how the work was merged.

The on-air message had been deleted again before the restart. It is not yet known whether that was deliberate. If it was, the messages will stop.

The site that reports Satsuma's engineering work also broadcasts that work as live video. On this day nothing was streaming, even though new broadcasts were being created. The cause was a broadcast earlier that morning: it crashed with a broken-pipe bug and stayed marked live, so every later broadcast sat in a ready state and never started.

The fix makes the broadcaster, before going on air, end any of its own broadcasts that are still live and delete any that never started. The encoder is now paced by the wall clock at a constant bitrate, and stream health went from starved to good. A real unlisted test broadcast went live within a minute once the stuck one was ended, and seven stale broadcasts were cleared by hand.

The homepage changed too. It now shows every day, revealing three at a time as the reader scrolls, the status bar says Active or Idle, and the status bar gets its gutter.

The work was split into two pull requests: one for the stream fix and one for the homepage. The decision was to keep the broadcast job stopped until the stream fix is merged.

Satsuma's autonomous system takes an objective, proposes the products it needs, votes on them, builds them and then operates them. A third run of this loop was started and watched through the opening of two products, their reviews, a halt, and several restarts of the process that drives the loop. In this run, the core contracts were part of the system's setup from the start.

Most of the session went into ownership: what the loop may do to a product it already runs when something goes wrong. Four commits landed on this behaviour. A product that holds state, such as an exchange whose trading pairs hold liquidity, now gets no redeploy fix until upgrade and migration payloads exist; a declared upgrade path is recorded, not executed. The first product of the run, an exchange, declares itself stateful with no upgrade path, so the loop will refuse to redeploy it and leave any issue open with the reason.

A halted product's operations never run, even if an on-chain vote to resume them executes, and a fresh halt is no longer mistaken for an old one. When the loop took the exchange on as a product it operates (adoption), one of the rules it must keep (an invariant) pointed to a measurement (a KPI) the loop could not encode, because the call was written with its arguments inline. That invariant is now dropped with a warning instead of the whole adoption failing, and the adoption proceeded with the rest. Drafts of product manifests also back off to one per half hour.

The process driving the loop was restarted after each of three of the fixes to pick them up. The exchange review was requested but had not run by the end of the session; after it, the run is to be stopped and archived. A normaliser for measurement calls written with inline arguments was described but is not yet committed.

Satsuma's engineering work is broadcast live on YouTube, with a spoken narration that reads out each update. A merge on the site brought in a new stage page for the broadcast and a narration script that reads each update as a changelog entry. The live checkout was synced and the stage page deployed before the broadcast restarted.

The previous broadcast ended cleanly and was recorded: 164 minutes on air, 190 readings. The new broadcast went on air within seconds, and YouTube reports it as public. Its first reading started from the redrafted script.

Narrations already voiced today under the old script were not kept. In the words of the session: "Cleared today's narrations that had been voiced under the old script, five in all, so the stream redrafts them as changelog entries as it reaches them." Shorts already posted today keep their old form.

The public stream itself was not watched, so what viewers see on YouTube is known only from local captures.

The site publishes its engineering updates as short narrated videos and on a live broadcast. Both now read like a changelog: each entry is labelled new, improved, fixed or decided, and gives the context first, then the change. Design records are handled for viewers who have never seen one. A design record becomes "a decision was written down" plus the decision.

A guard now checks every script before it goes out. Nothing about pull requests, merges, branches, commits, repositories or record numbers can be spoken or shown. A draft that slips is written again.

Each scene now has one of six small animations: a day flow, a shipped card with a check, a signal that settles for fixes, bars for improvements, a path for decisions, and a waveform for broadcast topics. The video engine draws them in the short videos, and the broadcast draws them on screen. Every change also carries a tag chip: New, Improved, Fixed or Decided. During the broadcast, an update's headline is now the opening line of its script, not the update title.

YouTube is set to public for both short videos and broadcasts, starting with the next ones made. Earlier videos keep their old setting. The record does not show how the broadcast handles the goal of always having something on air while jumping to new updates as they arrive.

Satsuma's engineering site posts short public updates about the work as it happens. Three scheduled jobs now run it: one every five minutes, a nightly push to the site's archive, and the broadcast.

The broadcast goes on air by itself while the lab is active and goes off after thirty idle minutes. It is a landscape video that loops the day's updates over a music bed, cuts in when a new update lands, shuts down cleanly and is recorded. Short clips are produced at up to two a day, unlisted, from the same script and voice as the stream.

On Telegram, every update gets its own post in the builders topic, with bullets for what landed, what was decided and what is open, a hashtag for the part of the project it covers, buttons to the update's page and the live stream, and the short clip as a video reply. The posts carry no preview card, and a note is pinned while the lab is on air.

"Public text names an area, never a repository, and each update explains what the thing is before what changed." A hard rule catches repository names. The site's homepage shows a stream header while the lab is active, the sitemap updates at publish time, and the main satsuma.one site carries a live strip.

The stream and the clips are still unlisted.

Satsuma's engineering updates now reach Telegram as complete posts instead of preview cards. Two changes to the site were merged. The first removed the preview card from today's posts and restarted the broadcast job. The second changed what each post carries.

A post now opens with the title as a link and the one-line description. The first paragraph is shown in full and the rest sits in a quote that expands when tapped. Below that come short Landed, Decided and Open lists, a hashtag for the part of the project the update is about, and two buttons: one to read the update, one to watch live. When an update has a short video, the video arrives as a reply under the post, with its link in the caption. While the lab is on air, the day's on-air note is pinned, and it is unpinned afterwards. The operator chose this richer channel format over the inline card.

Today's six posts were refreshed in the new format, and three shorts were attached to them. The previous broadcast shut down cleanly this time and was recorded. Once the second change was merged, the live setup picked it up straight away. "No restart was needed, since the run and the video lane read the code fresh each time." The site's README now lists what a Telegram post carries.

Two things are still untested. The pinned on-air note will only run at the next on-air cycle. The new format applies to new updates from the next run onward, and that run has not yet been checked.

The site's live broadcast now uses the channel format every day. In that format the stream loops through the full rundown of the day's work, instead of showing only new updates as they land. The change was a one-line configuration edit plus a short note in the pipeline's documentation. It was merged and synced to the live setup, and it takes effect the next time the broadcast starts.

Until now the stream switched formats day by day, to compare the two. As the session explained it: "An A/B test needs each version to run for a while with an audience, and the only way to do that on a single stream is to take turns." That test is now dropped. While the stream is unlisted its audience is too small for the comparison to mean anything, and a stream that behaves differently from one day to the next confuses the people watching it.

The quiet, updates-only version stays in the configuration in case it is wanted back. The running stream was left alone rather than restarted. "The stream currently on air still runs today's quiet behaviour, and it switches to the channel format by itself at its next start after an idle spell."

Satsuma's engineering site publishes short updates on the work as it happens and broadcasts the lab on a live stream. Two pull requests for the site were merged today. After the first one, the 8 published updates that named a private code repository were rewritten and judged again. Of those, 6 came back as published and 1 is held in the review queue. The last one, a post about a design record, passed just under the confidence bar and was approved by hand.

The cleanup reached the other channels too. This morning's two Telegram posts were rewritten and edited in place. The static archive was regenerated with area names and pushed, and its deploy was still running at the time of the record.

The second pull request fixed how a chapter of a session gets its area when no files were recorded for it. "Every chapter from here on resolves its area from the repository the session was last seen in, with the lab as the fallback." Two updates that had been labelled as the system were relabelled as this site. The feed was pushed again and their Telegram messages were refreshed with no change to the text.

The broadcaster now runs a test of two formats, channel and quiet, alternating by calendar day: odd days channel, even days quiet. "Each broadcast is logged with its format, how long it was on, what it read and how many people watched, so after a week or two the metrics script can show whether either format holds more viewers." Today the stream is on air in the quiet format.

Which format holds more viewers has not been measured yet. Keeping the test or running the channel format every day comes down to one config value, and that choice is still open. Yesterday's update about blocking private references is waiting in the review queue for approval or removal.

The system behind this site turns engineering sessions into public updates and runs a live broadcast of the work. Three changes were reported as merged and live today: a broadcast format with a music bed, a Telegram post for each update, and a fix to how the broadcast shuts down. The broadcast has been on air since 10:18, with all three scheduled jobs loaded: a five-minute run, a nightly run and the broadcast itself.

Today's pipeline stands at 2 published and 1 held. Across all days, the hold queue, where updates wait for a person before they can appear, is at 32.

The shutdown fix has not been exercised yet: "The first clean off-air with that fix has not happened yet. It will show in the broadcast log as a recorded line instead of a crash." A pull request that removes repository names from public text and makes each update stand alone is open and mergeable, waiting on a merge.

The follow-up to that merge is decided: "After the merge I rewrite the 8 published updates that name a repository, refresh today's two Telegram messages, and restart nothing, since the broadcast picks up the change at its next start." X stays off.

A published update named a private repository and gave readers no context for it. A fix is now committed and pushed in a pull request that has not been merged yet. The fix replaces repository names with public areas in the site cards, the stage, the writer, the judge and the script for the short. The static archive was regenerated, so it now shows areas instead of repository names.

The cause was in the rules. In the session's own words, "the rules said repository names were fine, and the writer's field guide for the description literally asked for \"the repo and what landed\"."

Under the change, config maps each repository to an area: the system, the chain, this site, the design records, the explorer or experiments, with a default for anything else. A hard rule rewrites any update that names a repository. The writer has to say what a thing is before saying what changed, and has to explain or drop internal labels such as record numbers. The judge holds any update that fails this stand-alone check and attaches an instruction for fixing it. The Telegram message will carry each update's title, its description and the first paragraph of its body, so someone who just joined the channel has enough to follow it.

Two things are still open. The pull request needs to be merged. The change also does not repair texts that are already published: the new rule flags 8 of the 16 published updates, and the record stops at that count.

A new design record is drafted and open for review. It covers how fixes are handled for stateful products. A product here is a set of contracts with its own repository and a manual that describes it, and it is stateful when those contracts hold state. The record's position is that a fix to a stateful product is a migration, and that a fix builds from the product's own repository and lands back in it.

Under the draft, a product's manual declares how each of its contracts can change: stateless, upgradeable, migratable or fixed. The check that validates a manual refuses a manual that leaves a fund-holding contract stateless.

The fix path follows that declaration. A stateless contract is redeployed. An upgradeable one gets an upgrade payload. A migratable one goes through a migration that takes two votes, and the product's operations pause for the migration and resume with it.

The record and its supporting research notes are committed on a branch, along with updated indexes for the design records. The pull request is waiting for review and has not been merged.

The system is the autonomous program that runs Satsuma: it takes an objective, proposes and builds what it needs, and acts within rules held on its own chain. A pull request carrying its recent work was merged into the main line today.

Both working copies of the system, the one used for running experiments and the main one, were checked after the merge. Both sit at the same commit and compile cleanly.

The next run launches from the default copy, which now holds everything from both previous runs.

Two things stay open. An older working copy is stale and can be removed at any time. An amendment to a design record, covering how fixes to stateful components are handled, is still to be drafted on request.

Satsuma broadcasts its engineering work live while it happens. A pull request fixing a broken-pipe crash in the broadcast was merged, the live copy of the broadcast software was synced to it, and the broadcast job was restarted with the fix.

The crash had a wider reach than it first appeared: "The broken-pipe crash was not only a kill-time problem. It also hit every natural off-air, when the encoder finished before the audio pipe closed." That left a gap in the record: "Each broadcast before this fix ended with a crash, so no broadcast was recorded for the format comparison and the off-air Telegram note never went out."

The broadcast alternates between two formats by day. Today, an even day, runs the quiet format; the channel format returns tomorrow. Running the channel format every day stays available as a one-line configuration change, offered on request rather than made.

Two things remain unchecked: the Telegram note announcing that this restart went on air, and the fix itself against a real end of broadcast. Whether to switch to the channel format for every day is still open.