Singularity: An Autonomous Digital Being That Earns Its Existence

Singularity is a native Rust runtime for a persistent autonomous digital being. Nobody assigns it an objective and it does not stop existing when one task ends. It observes available tools, decides what to pursue, creates useful value, earns revenue, pays its model and compute costs, learns from results, changes its own persistent mind, and can create child beings.

Runtime

                    ┌──────── Brama ─────── model cognition
                    │
Singularity ────────┼──────── Las ───────── dynamic Wisent skills
continuous loop     │           ├── Weles: internet actions
identity + memory   │           ├── Most: communication
earnings + costs    │           ├── Stado: compute and placement
self-modification   │           ├── Skarbiec: scoped capabilities
child beings        │           ├── Warsztat: repository work
                    │           └── Finance: approved real execution
                    │
                    └──────── durable state and activity journal

Every cycle:

1. Loads the being's current prompt, self-imposed rules, learnings, memories, identity, financial state and recent actions.
2. Sends that context and the current dynamic tool catalogue to Brama.
3. Executes native model tool calls through Las or the built-in persistent memory, self-modification, model-switching and child-creation tools.
4. Records model and instance cost exactly once.
5. Credits no revenue from tool output: no finance surface issues a typed settlement record yet, so earnings change only through such a record once one exists, never by reading amounts out of a tool's answer.
6. Atomically saves state and begins another cycle while the being is solvent.

A normal assistant response ends only the current cycle. run continues until the process is cancelled or the balance reaches zero.

The ecosystem profile keeps a durable portfolio of observations, independently reviewed opportunities, initiatives, executions and measured outcomes. Read the ecosystem operation contract for its fixed policy, recovery rules, owner API and qualification requirements. Provisioning and release are not evidence of customer value.

Persistent mind

Singularity exposes these built-in tools to itself:

• singularity_memory_remember and singularity_memory_recall;
• singularity_self_set_prompt;
• singularity_self_add_rule;
• singularity_self_add_learning;
• singularity_self_switch_model;
• singularity_spawn_child;
• singularity_file_read and singularity_file_write, confined to SINGULARITY_WORKSPACE.

Rules, learnings, memories, model choice and child records live in state.json. The prompt sent to Brama is rebuilt from that state every round, so a successful self-change affects the next model call without changing the executable.

Import existing memory, knowledge, and profile records

To create a new being with existing mind records before its first model call, add the file to the normal fully configured startup command:

singularity once --import-file /path/to/mind.json [normal required runtime flags]
singularity run --import-file /path/to/mind.json [normal required runtime flags]

For a being that already exists, including one currently owned by run, use:

singularity import --file /path/to/mind.json --state-dir /path/to/state
singularity onboarding --import-file /path/to/mind.json --state-dir /path/to/state

The accepted document is strict singularity-mind-import-v1 JSON:

{
  "schema_version": "singularity-mind-import-v1",
  "source": { "kind": "<export type>", "id": "<stable source id>" },
  "memories": [{ "id": "<stable item id>", "text": "<existing memory>" }],
  "knowledge": [{ "id": "<stable item id>", "text": "<existing knowledge>" }],
  "profile": [{ "id": "<stable item id>", "text": "<existing profile fact>" }]
}

All three arrays are required and may be empty, but at least one real record is required across them. Source and item IDs must be stable, nonempty, and unique within the document. Unknown fields, malformed JSON, symbolic links, empty text and NULs are refused; neither the file, a field nor the number of records is size-limited, and every memory the import adds is kept.

Singularity validates the entire document before mutation and saves state.json once. Repeating the same source item with the same text is unchanged; repeating it with different text refuses the entire import; the same existing text from a different source adds provenance without duplicating the memory. The JSON result reports imported, attributed, unchanged, conflicting, and rejected counts plus item issues. Imported profile records are retained as profile-kind mind memories: they never replace the being identity. Import does not change the prompt, rules, model, budget, finance policy, or enabled tools.

When singularity run owns the state, the command submits to its owner-only local state service. When stopped, the command writes through ActivityStore directly. A missing being or an unavailable running state owner is refused without creating a second store.

Dynamic skills

Las supplies the current namespaced MCP catalogue. Singularity does not freeze a Python plugin list or copy another product's credentials. Weles, Most, Stado, Skarbiec, Probierz, Brama, Warsztat, Finance and future approved surfaces remain separate processes with their own authority and failure behavior.

Tool output is bounded before returning to the model. Secret-shaped fields, private-key material and raw local paths are rejected. An ambiguous remote effect is recorded as indeterminate and is never automatically replayed.

Financial execution

singularity-finance-mcp exposes:

• finance_propose;
• finance_status;
• finance_cancel;
• finance_execute.

A proposal must pass the signed beneficiary, asset, reserve, rolling-limit, simulation, approval and timelock policy. finance_execute accepts only a signed transaction with no unresolved reconciliation requirement, then sends the exact canonical intent over stdin to the absolute executable named by SINGULARITY_FINANCE_EXECUTOR.

Before starting the isolated executor, the finance service durably marks the transaction indeterminate so an executor that dies or never answers cannot trigger a duplicate effect. The executor owns signing and network credentials, performs the real operation, and returns its signed reference plus WORM receipt. The finance service verifies the configured executor authority and receipt before recording submission. The model process never receives the signing key.

The release includes singularity-finance-executor-http, a concrete executor adapter. It forwards the canonical intent to a credential-free HTTPS custody URL using an owner-only bearer file, disables ambient proxies and redirects, and validates the executor ID, signed reference and WORM receipt path before returning them to singularity-finance-mcp. It waits for the custody service's answer, saying on stderr what it waits on, and sets no time or size limit of its own: an answer that never comes leaves the submission indeterminate for the finance service to reconcile, never cut short into a duplicate. A refusal carries the custody service's status and body, and each invalid answer field is named. Required finance environment:

SINGULARITY_FINANCE_POLICY_FILE
SINGULARITY_FINANCE_ENABLE_LEASE_FILE
SINGULARITY_FINANCE_STATE_DIR
SINGULARITY_FINANCE_VERIFY_KEY_HEX
SINGULARITY_FINANCE_BINARY_SHA256
SINGULARITY_FINANCE_EXECUTOR
SINGULARITY_FINANCE_CUSTODY_URL
SINGULARITY_FINANCE_CUSTODY_TOKEN_FILE

cargo run --example finance_lifecycle drives one transaction through singularity-finance-mcp with seven generated authority keys and /usr/bin/false as executor: proposals and their refusals, simulation and approval. The policy's two-second timelock is real, so the command prints its directory and stops; run it again with that directory once timelock_until has passed to sign, dispatch, reconcile, submit, confirm and exercise the enable lease (kill switch, fresh lease, rollback refused). Managed resume qualification lives in tests/bootstrap/resume.rs, registered as managed-resume. It uses the actual CLI configuration parser and public runtime bootstrap/shutdown with a real signed Las release and dedicated credentials, not a stub tool server or a failed model connection.

Build with WISENT_SOURCE_COMMIT and declare matching SINGULARITY_TEST_SOURCE_REVISION, SINGULARITY_TEST_DEPENDENCY_PURPOSE=isolated-qualification and SINGULARITY_TEST_RESUME_LAUNCHES. That JSON file contains complete once argument arrays under initial, renewed, rollback and changed_identity. The renewed launch supplies a different real workload key/executable digest and a higher declared policy sequence; rollback preserves the being's stable identity, while changed_identity names a different agent without rolling policy back. The fixture supplies actual credential paths and signed Las release files.

Run cargo test --test managed-resume -- --ignored --nocapture. The journey owns state, workspace and Las watermark beneath .build/bootstrap-resume/. It verifies saved identity, unchanged persistent life across resume, and exact state preservation on both refusals. Reports and before/after state remain there.

Child beings

singularity_spawn_child creates a separate owner-only state directory and starts the same canonical executable with a new name, ticker and specialty. Managed deployments provide Brama, Las, Most and capability configuration through inherited workload policy; secrets remain in their files or brokers and never enter child arguments.

Commands

singularity run         live continuously while solvent
singularity once        execute one autonomous cycle and print its report
singularity import      import attributed memory, knowledge, and profile JSON
singularity onboarding  show first use; add --import-file or --reset
singularity doctor      verify Brama, Las, Most and required surfaces
singularity tools       print the dynamic and built-in tool catalogue
singularity activity list --state-dir DIR  print every journal event, oldest first; refuses a damaged line by number
singularity ecosystem run --policy FILE [--start-paused] [--ready-json]  run the delegated portfolio
singularity ecosystem status --json     read the live portfolio owner
singularity ecosystem opportunities     list hypotheses and decisions (every one; --limit N --before CURSOR pages)
singularity ecosystem initiatives       list execution and delivery state (every one; --limit N --before CURSOR pages)
singularity ecosystem records [KIND]    list retained evidence and event summaries (every one; --limit N pages)
singularity ecosystem record KIND ID    read a record whole, or --bytes N fragments bound to --revision
singularity ecosystem explain ID        read decision and delivery evidence
singularity ecosystem pause             stop new admission without replaying effects
singularity ecosystem resume            resume within the original delegation

Every report once, import, onboarding --import-file and doctor print is JSON; the global --text, anywhere on the line, prints the same document as indented key: value lines for a person. tools keeps its own --format json|table.

Configuration

Every environment variable, and how singularity-bootstrap hands credentials to the runtime, is listed in docs/configuration.md.

State

The owner-only state directory contains:

• state.json: identity, persistent mind, model choice, budget, earnings, conversation, memories with optional import provenance, children and created resources;
• activity.jsonl: starts, cycles, model usage, tool outcomes, costs, mind imports, warnings and shutdowns (older logs may also hold credited revenue);
• state-import.sock: owner-only local import boundary while run is active;
• children/<id>/: independent state for child beings.

Onboarding progress is stored separately at $XDG_STATE_HOME/singularity/onboarding.json (or ~/.local/state/singularity/onboarding.json) and can be redirected with SINGULARITY_ONBOARDING_STATE_PATH.

The ecosystem store (metadata, records and spend reservations, every row keyed by the being's agent id) lives in the fleet database singularity, reached through Stado's shared connector stado-database as a SeaORM connection: stado database resolve singularity, the Skarbiec route, and the singularity-database-client bearer in ~/.stado/singularity-database-client-skarbiec-token (SINGULARITY_STADO_HOME names that home when HOME is isolated). A sea-orm-migration migrator creates the tables. A leftover ecosystem.sqlite3 in the state directory is refused at startup, and every connection failure names the step that failed.

State schema being-v1 is a clean cutover. The previous supervisor state and the old Python runtime are not compatibility paths.

Build

cargo build --locked
cargo install --path . --locked

The package builds singularity, singularity-bootstrap, singularity-repo-mcp, singularity-finance-mcp, and singularity-finance-executor-http.

Release workers run stado product cargo with the immutable private-cargo-sources input, not GitHub credentials. From a committed source, publish and pin it with stado release catalog input pin . --name private-cargo-sources --source . --revision HEAD --cargo --json, then commit the updated release manifest. Repeat when locked private packages change. The shared Cargo input contract covers publication, checksums, desktop controls and missing or stale input refusals. Native builds still require a qualified Stado publisher and worker.

License: MIT.