csf

One Go runtime for agent work, typed tools, shared knowledge and observable experiments.

Take the tour · What is CSF · North star · Why CSF · Proofs · Architecture · Quick start · CSF guide · Agent instructions · Citation

What is CSF

Most robots run two kinds of software side by side: a slow, best-effort layer that decides what to do (planning, perception, learned policies) and a fast, real-time layer that does it (the control loop that must never miss a deadline). LITHE (Lim and Clites, 2026) turns that split into an architecture on one ordinary computer. A best-effort Brain proposes, a real-time Spine executes, and each gets its own CPU core. On LITHE's quad-core board, CPU 1 runs the Spine's control loop alone, CPU 2 runs the Brain, CPU 3 handles the motor bus, and CPU 0 is the housekeeping core: it takes the operating system's chores, absorbs timing jitter so the other cores never feel it, and prepares the next controller before it is swapped in. LITHE demonstrates this on one robot, but deciding versus doing is the shape of most robot software stacks, so we expect the architecture to carry over to most robots. Figure 1 is LITHE's own diagram of that split.

Figure 1. LITHE's system architecture: the Brain, Spine, Housekeeping and Transport roles, each on its own core of one Raspberry Pi, driving a one-degree-of-freedom robot. LITHE, Figure 2, shown from arXiv and not copied into this repository (Lim and Clites, 2026).

CSF is the LITHE philosophy applied to CPU 0. It is the housekeeping layer: the tools, records, schedules and experiments around an agent system's decisions, composed into one Go process so they talk through function calls instead of inter-process communication. In CSF the architecture is a checked artifact and the engineers are agents working under rules. It ships with working implementations (gotth-live, Warden, xetcas, pgmem, liquidproto) that prove the loop works. Figure 2 places CSF on LITHE's CPU 0.

Figure 2. CSF inside LITHE's CPU 0: one Go process holding typed tools, sessions, schedules, knowledge, observation and bounded workers. LITHE's Brain, Spine and Transport cores, and the external systems CSF talks to, sit outside it. Drawn by hand as our mapping onto LITHE; it is not generated.

New here? Take the tour of CSF: ten stops from the idea to the running pieces, each with a diagram, real code, an example next to a counterexample, and one command to run.

It has four parts, and together they form one loop:

1. A language. architecture.csf declares what the system is: its terms (124 today), how they contain and depend on each other, and the paper each borrowed word comes from. For example: term widget "Widget" "A component of gotth-live ...".
2. A compiler, csfc. It checks the code against that declaration and generates what used to be hand-written: the glossary, the dictionary, the architecture diagrams below, and this README's north star. For example, tools/merge-pr.sh refuses a pull request whose ontology alignment score regresses against main.
3. A harness. One process per machine runs coding-agent sessions with a gate on every shell command and every commit. For example, harness submit -recipe agent.json starts an agent that cannot run a polling loop and whose first commit opens a draft pull request.
4. Miners (ouroboros). They read the operator–agent record and the repository, find where intent and code diverge, and turn each divergence into the next gate or change. For example, on 2026-10-02 the finding that 64 of the 124 terms own no directory became a ticket that states the gate's predicate; the gate itself is not built yet.

What it can be used as

• An agentic software engineer. Hand it a ticket and it works the ticket end to end: an agent session in its own git worktree writes the change under a gate on every command and commit, opens a draft pull request at its first commit, and the merge gate refuses the change unless its checks and its architecture score hold. Many sessions run at once, one harness per machine, and you steer any of them from its chat page. CSF is developed this way.
• An agent-operated deployment system: propose and approve changes, reconcile applications, approve infrastructure updates, and watch the fleet.
• A server-driven live UI that keeps one copy of the state on the server and syncs every browser tab to it.
• A self-hosted build and evidence cache that uploads only what changed.
• Fast tests with real SQL and no database server.

What you get, grouped by what it is for:

• CSF — The Cerebrospinal Fluid, the core: a Go library and runtime for the coordination around an agent system, covering typed tools, sessions and worktrees, schedules, knowledge ingestion and search, traces and retained evidence. Its services are libraries mounted into one Go process through functional options, and each operation is generated once and served as HTTP, CLI and MCP. Start with the consumer example.
  • Agent harness and ops view: one process per machine runs every agent session with gates on every command and commit. The csf binary is both that process and its client: csf init puts CSF into a repository, csf submit takes an assignment recipe, csf send adds a turn, and csf view serves a gotth-live page with one live card per session (command reference). See Quick start.
  • Ouroboros: miners that read the record of what agents did, find mistakes no gate catches yet, and turn each into a gate once a walk-forward backtest on history finds every labeled case.
  • csfc compiler: checks the code against architecture.csf and generates the glossary, the dictionary, the diagrams and this README's north star.
• Deploy, an agent-operated deployment system: an agent harness proposes, the deploy service approves and fences every change, the node executor reconciles Compose applications, and the operator UI watches.
  • Deploy service and node executor, with the deployment kit for Compose applications.
  • Warden: the fleet watchdog the deploy service fences against: Raft-style leader election [5] over a static peer set, liveness, incidents, and an authoritative view every mutation is checked against.
• Libraries you can use on their own:
  • gotth-live: server-driven live user interfaces from Go. Widgets, event handlers and state are synced from the application layer, and the browser renders each change as the app commits it. State and rendering stay in your process; one WebSocket per tab carries events up and re-rendered fragments down. No npm, no CDN.
  • xetcas: a self-hosted Xet [6] content-addressable storage server with a Git LFS [7] front door, used for build caches, snapshots and evidence archival. Re-pushing a 48 MiB model after editing 2% of it costs about 1 MiB.
  • pkg/: domain-neutral Go primitives: pgmem, a process-local PostgreSQL [8] emulator for fast tests (real PostgreSQL AST, no server); liquidproto, the runtime for Liquid Proto, protobuf with refinement types [9] compiled into the generated Go; cron, config, redact, telemetry, mailbox, and more.

The north star is a robot software stack whose correctness is proven end to end; today that is a goal, not a capability: the generated table below reports no completed milestone, and the csfc verifier does not yet issue certificates. It ships as one Go monorepo with a CLI.

1. Introduction

The name comes from the architecture that shaped it. In LITHE (Lim and Clites, 2026), a best-effort Brain proposes and a real-time Spine executes, on one partitioned computer. CSF is the fluid around them: the housekeeping layer that carries tools, records and experiments between decisions (Figures 1 and 2).

New to the words used here? The glossary explains every CSF term in plain language, plus the words CSF borrows from papers, with citations.

First-party source is Apache-2.0. Dependencies, vendor simulator images and paper figures retain their own licenses.

North star

Generated from architecture.csf; change that file, not this section.

Goal. End-to-end correctness of a robot software stack, proven relative to stated assumptions and checked against them at runtime. The physical world and the models in it are not proven; the envelope around them is: check before execute, contracts at every io boundary, and runtime monitors with a safe fallback.

Milestones. 0 done, 6 in progress, 1 planned. A done milestone names a path in this repository that the generator checks exists; PR and issue numbers refer to the source monorepo.

2. Why CSF: no IPC inside CPU 0

LITHE runs a whole robot control hierarchy on one quad-core single-board computer by partitioning its cores (LITHE §III-B):

LITHE treats inter-process communication as architecture (LITHE §III-C): the Brain and Spine exchange state through lock-free, zero-copy POSIX shared memory whose layout a build-time generator owns. Its abstract names complex middleware as one cost of the conventional alternatives.

The coordination an agent system needs — tools, sessions, schedules, knowledge and observation — lands on the housekeeping side of that partition. Built the usual way, each capability is its own daemon, and every handoff inside CPU 0 becomes a socket, a serialization format and another process lifecycle to supervise.

CSF prevents that IPC problem inside CPU 0 by composing those capabilities in one Go process. Services are Go libraries selected with functional options. They exchange typed values through function calls and coordinate concurrent work with goroutines and channels; contexts and explicit ownership give each operation a cancellation and cleanup path. An internal handoff needs no socket, no wire serialization and no separate daemon. Separate architecture checks inspect selected Go ownership and process boundaries in source; they establish those source constraints, not runtime timing.

Figure 2 is our architectural mapping onto LITHE [1], drawn by hand; it is not generated from the architecture model. Its boundaries are exact:

• PostgreSQL, OpenSearch, Langfuse and external model or simulator processes keep their protocol boundaries. CSF removes IPC between its own capabilities, not IPC with systems that genuinely live elsewhere.
• LITHE's Brain–Spine shared-memory IPC remains a separate integration boundary.
• CPU affinity and isolation are deployment configuration. CSF does not implement LITHE's loader, CPU isolation or real-time controller hot swap.

examples/csf-consumer shows the composition: CSF, its generated routes, its MCP server and the consumer's own endpoint in one router owned by the consumer's process.

3. Proofs, not just hardware: CSF and LITHE's safety problem

LITHE is explicit about where its guarantee stops. Its user-space real-time approach "provides a functional margin of safety, even if it lacks the formal mathematical guarantees of a verified real-time operating system" (LITHE §V-A). For model-written controllers, "it remains an area of active research to implement appropriate safety and verification bounds on the model's output" (LITHE §V-B); "theoretical stability guarantees remain an open challenge", so safety "must be enforced via strict hardware-level limits on torque and velocity" (LITHE §V-C).

A hardware limit is enforced per device. A proof about a language holds for every program written in it. CSF's direction is to narrow what a model may author to a typed, bounded language, and to prove what that language's compiled code computes. The model then chooses among checked options instead of emitting arbitrary code. That is how we think LITHE's idea scales past one robot on one bench.

What is proved today. csf/examples/proof/BrainSpine.lean models the arithmetic slice of brainspine.proto: a typed expression language with constants, four observation slots, addition, integer scaling and clamping over saturating integers, compiled to a postfix stack machine. Lean machine-checks four theorems:

bash csf/examples/proof/check.sh downloads the pinned Lean release, verifies its SHA-256, runs Lean with --trust=0, and audits the axioms of all four theorems: only Lean's standard propext, Classical.choice and Quot.sound are admitted, and sorryAx or custom axioms fail the check. CI runs it in its own job.

What is not proved. Be precise about the gap:

• Agreement between the Lean model and the canonical wire semantics is a reviewed translation boundary. CSF ships no controller implementation: the low-level spine is external and ROS-side, reached through ipc/ros.
• The csfc compiler verifier is a stub: CSFC.Verification.verify returns notImplemented for every input and issues no certificate.
• The actuator clamp proves a numeric range only. Timing, stability, collision avoidance, safe controller switching and physical safety are outside every theorem here. A hardware watchdog remains necessary.
• The Lean kernel, its official release build, the standard library, the operating system and the hardware remain trusted.

The improvement loop in Figure 3 is generated from the same architecture model as every CSF diagram. Choose and controller selection are planned: the low-level controller is external and ROS-side, and an agent choosing among proved options is the next step, not a shipped one.

%% Generated from csf/compiler/language/architecture.csf; do not edit.
%% Documentation model only; status labels do not establish runtime verification.
flowchart LR
  classDef csf_existing fill:#0F766E,stroke:#115E59,stroke-width:2px,color:#FFFFFF;
  classDef csf_planned fill:#FEF3C7,stroke:#B45309,stroke-width:2px,color:#78350F;
  n_observe["Observe (existing)"]:::csf_existing
  n_retrieve["Retrieve (existing)"]:::csf_existing
  n_choose["Choose (planned)"]:::csf_planned
  n_check["Check (existing)"]:::csf_existing
  n_execute["Execute (existing)"]:::csf_existing
  n_evaluate["Evaluate (existing)"]:::csf_existing
  n_save_evidence["Save evidence (existing)"]:::csf_existing
  n_ouroboros["Ouroboros (planned)"]:::csf_planned
  n_select_controller["Select a controller between episodes (planned)"]:::csf_planned
  n_observe -.-> n_retrieve
  n_retrieve -.-> n_choose
  n_choose -.-> n_check
  n_check --> n_execute
  n_execute --> n_evaluate
  n_evaluate --> n_save_evidence
  n_evaluate -.-> n_select_controller
  n_select_controller -.->|"next agent iteration"| n_choose
  n_save_evidence -.-> n_ouroboros
  n_ouroboros -.->|"next iteration"| n_observe
  linkStyle 0 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 1 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 2 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 3 stroke:#0F766E,stroke-width:2px
  linkStyle 4 stroke:#0F766E,stroke-width:2px
  linkStyle 5 stroke:#0F766E,stroke-width:2px
  linkStyle 6 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 7 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 8 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 9 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5

Figure 3. The improvement loop, generated from architecture.csf. Solid steps exist today; dashed steps are planned.

4. Architecture

Figure 4 is generated from csf/compiler/language/architecture.csf by the CSF documentation compiler, which also produces the shared vocabulary and the plain-language glossary. Solid connections are existing components or configurable integrations; dotted connections are planned. An integration shown here still needs its dependencies and configuration; it is not automatically running when you import CSF.

%% Generated from csf/compiler/language/architecture.csf; do not edit.
%% Documentation model only; status labels do not establish runtime verification.
flowchart TB
  classDef csf_existing fill:#0F766E,stroke:#115E59,stroke-width:2px,color:#FFFFFF;
  classDef csf_planned fill:#FEF3C7,stroke:#B45309,stroke-width:2px,color:#78350F;
  n_human["Human or agent client (existing)"]:::csf_existing
  n_brain["Brain (existing)"]:::csf_existing
  n_contracts["Shared typed contracts (existing)"]:::csf_existing
  n_stores["Store (existing)"]:::csf_existing
  n_jobs["Job ledger (existing)"]:::csf_existing
  n_views["Prometheus#44; Grafana and Langfuse (existing)"]:::csf_existing
  n_experiments["Training results and optional MLflow (existing)"]:::csf_existing
  n_vendor["Copilot brain provider (existing)"]:::csf_existing
  n_spine["Low#45;level spine controller (planned)"]:::csf_planned
  n_hardware["Consumer sensors and actuators (planned)"]:::csf_planned
  subgraph g_host["CSF#58; one Go application process"]
    n_bench["Workbench (existing)"]:::csf_existing
    n_api["Generated HTTP#44; CLI and MCP operations (existing)"]:::csf_existing
    n_knowledge["Knowledge and retrieval (existing)"]:::csf_existing
    n_ros["ROS spine capability (existing)"]:::csf_existing
    n_workers["Configured worker goroutines (existing)"]:::csf_existing
    n_inspect["Inspection (existing)"]:::csf_existing
    n_widgets["Widget SDK and gotth#45;live (existing)"]:::csf_existing
  end
  style g_host fill:#EEF2FF,stroke:#4338CA,stroke-width:2px,color:#1E1B4B
  n_human --> n_bench
  n_brain --> n_api
  n_contracts --> n_api
  n_bench --> n_api
  n_bench --> n_vendor
  n_api --> n_knowledge
  n_api -->|"spine status"| n_ros
  n_api --> n_workers
  n_api --> n_inspect
  n_knowledge --> n_stores
  n_workers --> n_jobs
  n_jobs --> n_stores
  n_inspect --> n_views
  n_brain --> n_experiments
  n_widgets -->|"keyed Kanban cards"| n_bench
  n_ros -.->|"planned ROS transport"| n_spine
  n_spine -.-> n_hardware
  linkStyle 0 stroke:#0F766E,stroke-width:2px
  linkStyle 1 stroke:#0F766E,stroke-width:2px
  linkStyle 2 stroke:#0F766E,stroke-width:2px
  linkStyle 3 stroke:#0F766E,stroke-width:2px
  linkStyle 4 stroke:#0F766E,stroke-width:2px
  linkStyle 5 stroke:#0F766E,stroke-width:2px
  linkStyle 6 stroke:#0F766E,stroke-width:2px
  linkStyle 7 stroke:#0F766E,stroke-width:2px
  linkStyle 8 stroke:#0F766E,stroke-width:2px
  linkStyle 9 stroke:#0F766E,stroke-width:2px
  linkStyle 10 stroke:#0F766E,stroke-width:2px
  linkStyle 11 stroke:#0F766E,stroke-width:2px
  linkStyle 12 stroke:#0F766E,stroke-width:2px
  linkStyle 13 stroke:#0F766E,stroke-width:2px
  linkStyle 14 stroke:#0F766E,stroke-width:2px
  linkStyle 15 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5
  linkStyle 16 stroke:#B45309,stroke-width:2px,stroke-dasharray:5 5

Figure 4. CSF's architecture, generated from architecture.csf. Solid connections exist or are configurable integrations; dotted connections are planned.

Stores and data structures

CSF separates what data is from where it lives, following the ANSI/SPARC three-level architecture [2] and Codd's physical data independence [3]:

Status: operator ruling recorded 2026-10-02; pkg/graph, pkg/store and the ontology terms are planned (source monorepo issue #366). The in-process Queue exists today in io/inproc.

Aspects: hooks on service actions

Anything that does something is a service, and cross-cutting behavior attaches to a service's actions the way aspect-oriented programming attaches advice to join points [4]:

An action CSF does not execute itself, such as git commit, enters through an adapter service whose operation is the join point.

Status: operator ruling recorded 2026-10-02; the generated options and ontology terms are planned (source monorepo issue #374).

What is in here

.
├── csf/          typed coordination library, contracts, examples and consumer guide
├── pkg/          domain-neutral primitives — nothing in them knows about any service
├── services/     composable business logic — deploy, warden, the agent harness, cron, ops view and more
├── app/          runnable compositions — csf, harness, deploy, node executor, warden, intake
├── runtime/      the process runtime: the lifetimes every goroutine starts under
├── ipc/          boundary crossings, each a capability granted through a constructor
├── io/           the in-process io tier (io/inproc)
├── web/          the deploy service's and node executor's web layers
├── proto/        .proto sources and their committed Go bindings
├── infra/        deploy-kit/ (Compose stack, installer, fleet driver, updater) and local dev services
├── tools/        build wrapper, house gates, the CSF kit installer and the csf operator CLI
├── xetcas/       a Rust workspace (xetcasd) plus its generated Go bindings
├── examples/     one worked consumer per extension seam, each with its own suite
├── extensions/   copilot-pair, a GitHub Copilot CLI extension
├── docs/         extending.md (the four compile-time seams) and GLOSSARY.md (for humans)
└── bazel/        the legacy WORKSPACE shim

The three Go trees are separated by one rule, about who may import whom:

Nothing in pkg/ imports services/ or app/, which is what makes the primitives usable on their own:

pkg/proto and pkg/scripts hold tooling rather than a package.

5. Quick start

To put CSF into a repository of yours, run csf init at its root. It writes a sample assignment under .csf/ and registers the repository with this machine's agent harness, starting it if none is running. Then:

csf submit -recipe .csf/assignments/sample/agent.json   # an agent session starts
csf events -assignment <id>                              # ends with a draft pull request
csf chat -assignment <id>                                # the session's chat address

csf comes from this repository, once per machine, with only Docker on the machine: tools/kit/install.sh from a clone. The CSF kit guide walks every step, its success check and how to undo it.

Use Go 1.26. The smallest CSF example needs no database, GPU, model account or extra process:

go run ./examples/csf-theme --listen 127.0.0.1:8089 --theme-dir ./examples/csf-theme

That mounts the generated HTTP API and MCP at http://127.0.0.1:8089/mcp. The caller owns the process; CSF only registers routes and hands back a handler. From examples/csf-consumer/main.go:

service, err := csf.New(options...)
if err != nil {
	return nil, fmt.Errorf("create CSF: %w", err)
}
router := httpserver.NewEngine(applicationName)
service.Register(router)
router.Any(mcpPath, gin.WrapH(service.MCPHandler()))
registerConsumerSummary(router, service)

Agent-native onboarding. The intended first instruction to your agent is “Learn about CSF.” The LearnAboutCSF MCP operation explains the pinned version's capabilities and extension points and, when knowledge is configured, submits the embedded guidance plus selected consumer files for indexing. Your own tools join the same MCP server with typed inputs and outputs; the pinned MCP SDK derives and validates their schemas, and CSF rejects name collisions with its own operations. The signature, from csf/service.go:

func WithMCPTool[In, Out any](tool mcp.Tool, handler mcp.ToolHandlerFor[In, Out]) Option

The host still owns listener startup, authentication, repository authorization and consumer checks. The CSF guide covers the Workbench, onboarding and every example with its boundary.

gotth-live, the web layer CSF's Workbench uses, runs with no npm or code generation:

go run ./examples/gotth/counter

counter: http://127.0.0.1:8080
counter: allowed origins [http://127.0.0.1:8080 http://localhost:8080]

Open that URL in two browser tabs. The number lives in the Go process and neither tab holds a copy of it: click in one and the other repaints, reload either and the count survives, and the client script that carried the patch was compiled into the binary and served by the same handler that serves the WebSocket. examples/gotth/counter/README.md follows one click all the way through and names the file each step lives in. The optional CSF Workbench has a separate browser-asset build documented in its README.

6. Consume it

This repository is generated

It is a one-way snapshot of the canonical repository at one exact revision, published with no upstream history. The canonical repository is private CSF staging since 2026-10-02; v0.1.3 and earlier were exported from a private monorepo's candace/ folder. Snapshot updates arrive as ready pull requests from the candace-export branch against main, and releases from candace-release. Make source changes in the canonical repository; editing the generated destination directly would conflict with its next snapshot.

After its review PR is merged, the publisher verifies that tree and creates immutable v<version> and export-<sha12> tags. The GitHub Release uses the semantic-version tag; .candace-export.json records the exact source revision. Cite a tag, not a branch.

Consume it in 60 seconds

Releases are published on candacelabs/csf; the current one is v0.2.7. For a private staging release, download the release assets with authenticated access and use the verified local-archive consumer. The Go module path is github.com/candacelabs/csf in both cases.

New releases carry csf-<sha12>.tar.gz and its .sha256; historical releases retain their original archive names. The tarball is this tree re-rooted so MODULE.bazel is at the archive root, plus a deterministic .candace-source.json recording the source revision and selected tree, built twice and byte-compared before it is kept.

Download both files from the same Release. In their directory, replace <sha12> with the 12-character revision from its tag and verify the hexadecimal checksum, then compute the base64 SRI value required by Bazel (Bash, sha256sum and OpenSSL):

set -euo pipefail
archive='csf-<sha12>.tar.gz'
sha256sum --check "$archive.sha256"
printf 'sha256-'
openssl dgst -sha256 -binary "$archive" | openssl base64 -A
printf '\n'

Copy the complete sha256-... output line into integrity in your own MODULE.bazel; the .sha256 file's hexadecimal value is not an SRI value. The archive's module() still declares version 0.1.0, so bazel_dep keeps that version while the URL names the release tag:

bazel_dep(name = "csf", version = "0.1.0")

archive_override(
    module_name = "csf",
    integrity = "sha256-...",          # base64 SRI output from the command above
    strip_prefix = "csf-<sha12>",
    urls = ["https://github.com/candacelabs/csf/releases/download/v0.2.7/csf-<sha12>.tar.gz"],
)

Then depend on what you use — @csf//services/deploy/component, @csf//pkg/gotth/live, @csf//services/warden — and build. Since v0.2.0 the deploy service sits at services/deploy/ and its kit at infra/deploy-kit/; v0.1.3 and earlier used services/candaceos/ and candaceos/.

Not a Bazel repository? The module path is the repository path:

go get github.com/candacelabs/csf@v0.2.7

Use the published semantic version matching your archive, not @latest. The accompanying export-<sha12> tag identifies its exact source snapshot.

docs/extending.md covers both shapes in full, plus the http_archive fallback and the legacy WORKSPACE path.

7. Examples

Every extension seam has a worked example with its own test suite. They are the contract's executable half — the documentation says what is guaranteed, and these fail if it stops being true.

8. Build it

Bazel is the primary build and comes from a pinned container, so the command is the same on a laptop and on a runner. Docker is the only prerequisite:

tools/bazel.sh build -- //... -//xetcas/...   # everything but the Rust workspace
tools/bazel.sh test  -- //... -//xetcas/...
tools/bazel.sh build //xetcas/...             # the Rust workspace and its Go bindings
tools/bazel.sh test  //xetcas/...

The plain go command works on the same tree and needs no Bazel:

go build ./...
go test ./...

The Rust workspace builds with plain Cargo too — that is the path its demo, container images, and just targets take:

cd xetcas && cargo build --workspace && cargo test --workspace

.bazelversion (Bazel 9.2.0) and MODULE.bazel (rules_go 0.62.0, Gazelle 0.52.2, Go SDK 1.26.5, rules_rust 0.73.0) are the only version authority. BUILD files are generated by Gazelle (tools/bazel.sh run //:gazelle) and CI fails on drift.

Run the deploy stack

The deployment kit installs and runs the whole one-box stack (deploy service, node executor and operator UI) from this clone. The default install is deliberately harmless: a simulated harness, a dry-run executor, and no Docker socket bind-mounted anywhere.

./infra/deploy-kit/install.sh          # then open http://<host>:7780
./infra/deploy-kit/status.sh
./infra/deploy-kit/uninstall.sh

The deploy service publishes on all host IPv4 interfaces with no built-in authentication: put it behind your own authenticating proxy before exposing it beyond a trusted network. infra/deploy-kit/README.md is the operations manual, and infra/deploy-kit/AGENTS.md states the trust model as eight invariants with their enforcement points.

9. Where to go next

• csf/README.md — the CSF guide: Workbench, onboarding, examples and release evidence.
• AGENTS.md — the repository's own guide: taxonomy, seams, invariants, conventions.
• docs/extending.md — the four compile-time seams and how to pin a snapshot.
• docs/GLOSSARY.md — every CSF term and borrowed literature term in plain language, for human readers.
• pkg/gotth/README.md, xetcas/README.md — each subsystem's own front page.
• app/*/CLAUDE.md — what may not be changed casually in each binary.

10. Citation

[1] He Kai Lim and Tyler R. Clites. LITHE: Bridging Best-Effort Python and Real-Time C++ for Hot-Swapping Robotic Control Laws on Commodity Linux. arXiv:2603.07442 [cs.RO], 2026. Submitted to IROS 2026. https://doi.org/10.48550/arXiv.2603.07442

@misc{lim2026lithe,
  title         = {{LITHE}: Bridging Best-Effort {Python} and Real-Time {C++} for Hot-Swapping Robotic Control Laws on Commodity {Linux}},
  author        = {Lim, He Kai and Clites, Tyler R.},
  year          = {2026},
  eprint        = {2603.07442},
  archivePrefix = {arXiv},
  primaryClass  = {cs.RO},
  doi           = {10.48550/arXiv.2603.07442},
  url           = {https://arxiv.org/abs/2603.07442},
  note          = {Submitted to IROS 2026}
}

CSF's architecture is inspired by LITHE [1]. To cite CSF itself, name the exact release tag you used:

@software{csf2026,
  title   = {CSF — The Cerebrospinal Fluid},
  author  = {{Candace Labs}},
  version = {0.2.7},
  year    = {2026},
  url     = {https://github.com/candacelabs/csf}
}

The LITHE paper and its figures are distributed under arXiv's non-exclusive distribution license, not a Creative Commons license. © the authors; this repository's license does not cover them. Figure 1 is displayed from arXiv; no figure file is copied into this repository.

[2] D. Tsichritzis and A. Klug. The ANSI/X3/SPARC DBMS framework report of the study group on database management systems. Information Systems 3(3):173–191, 1978. https://doi.org/10.1016/0306-4379(78)90001-7

[3] E. F. Codd. A relational model of data for large shared data banks. Communications of the ACM 13(6):377–387, 1970. https://doi.org/10.1145/362384.362685

[4] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier and J. Irwin. Aspect-oriented programming. ECOOP '97, LNCS 1241, pp. 220–242, 1997. https://doi.org/10.1007/BFb0053381

[5] D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. 2014 USENIX Annual Technical Conference (USENIX ATC 14), pp. 305–319, 2014. https://www.usenix.org/conference/atc14/technical-sessions/presentation/ongaro

[6] Hugging Face. xet-core: the Xet storage protocol, client and content-addressed chunk format. https://github.com/huggingface/xet-core

[7] Git LFS contributors. Git Large File Storage. https://git-lfs.com/

[8] M. Stonebraker and L. A. Rowe. The design of POSTGRES. Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, pp. 340–355, 1986. https://doi.org/10.1145/16894.16888

[9] T. Freeman and F. Pfenning. Refinement types for ML. Proceedings of the ACM SIGPLAN 1991 Conference on Programming Language Design and Implementation (PLDI), pp. 268–277, 1991. https://doi.org/10.1145/113445.113468

[10] N. Fulton, S. Mitsch, J.-D. Quesel, M. Völp and A. Platzer. KeYmaera X: an axiomatic tactical theorem prover for hybrid systems. CADE-25, LNCS 9195, pp. 527–538, 2015. https://doi.org/10.1007/978-3-319-21401-6_36

[11] R. Bohrer, Y. K. Tan, S. Mitsch, M. O. Myreen and A. Platzer. VeriPhy: verified controller executables from verified cyber-physical system models. PLDI 2018, pp. 617–630, 2018. https://doi.org/10.1145/3192366.3192406

[12] X. Leroy. Formal verification of a realistic compiler. Communications of the ACM 52(7):107–115, 2009. https://doi.org/10.1145/1538788.1538814

[13] G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch and S. Winwood. seL4: formal verification of an OS kernel. SOSP 2009, pp. 207–220, 2009. https://doi.org/10.1145/1629575.1629596

The north star's "Builds on" column links KeYmaera X [10], VeriPhy [11], CompCert [12] and seL4 [13].

License

Apache License 2.0. See LICENSE.

AI systems assisted with work in this repository. Their output is not presumed correct, secure, reviewed, or production-ready.