Autonomous ecosystem
The ecosystem runtime chooses work for the Wisent products on its own, without a reported defect, and keeps that portfolio across restarts. It observes the products, proposes opportunities, has each one reviewed by a separate model call, executes accepted ones through Jeden, delivers them through Stado and judges the outcome after release. A release opens outcome measurement; it is not evidence of adoption or revenue.
Singularity owns direction and allocations. Jeden and Pursuit own requirements, execution and independent acceptance. Stado owns product identity and creation (stado product), release and installation. Echo owns usage and market data. Provider credentials stay with their owners.
Commands
singularity ecosystem run --policy /path/to/policy.json starts the owner. It takes every runtime input of [singularity run](/docs/cli/run): the workload identity, --starting-balance, --instance-price, --cycle-interval-secs, --state-dir, --workspace, the Brama URL, model and credentials, and the signed Las inputs. None has a default. The cycle interval paces control, selection, outcome review, Las admission and dispatch.
The read and control commands — status, opportunities, initiatives, records, record, explain, pause and resume — talk to the running owner over ecosystem.sock in its state directory. Each request and each answer is one newline-terminated JSON document with schema_version 2; an answer carries ok and either result or error with its code, operation, message and retryability.
Where the portfolio lives
The portfolio — metadata, records and spend reservations — lives in the fleet database singularity, every row keyed by the being's agent id, reached through Stado's shared connector: stado database resolve singularity, the Skarbiec route and the singularity-database-client bearer. A leftover ecosystem.sqlite3 in the state directory is refused at startup. Failure to inspect that pathname is also refused, with its path and filesystem cause: unknown legacy history is not treated as absent and does not open fresh fleet state.
Each write stores the record and an event record naming the changed kind, id and content SHA-256 in one transaction. The state directory holds the owner lock ecosystem.lock, the control socket and the immutable request files handed to Jeden and Stado under requests/.
Fixed delegated policy
The policy file's SHA-256 must equal the delegated identity's policy digest, or startup is refused with ecosystem policy does not match the delegated identity's policy digest.
| Field | Meaning | | --- | --- | | schema_version | 1 | | id | Stable delegation identity | | workspace_root | Absolute canonical parent of the product checkouts | | product_ids | Existing products the delegation covers | | model | Brama model; must equal the runtime's Brama model, and is passed to Jeden | | allow_product_creation | Whether new private products may be provisioned with stado product create | | allow_write, allow_command | Whether Jeden may write and run commands; execution needs both | | allow_release | Whether accepted work may be released and installed through Stado | | budget_usd | The portfolio's spend allocation, a decimal string | | initiative_limit_usd | Largest estimated cost one opportunity may carry | | exploration_budget_usd | Allocation for product and research opportunities | | model_call_reserve_usd | Reservation held for each direction or outcome model call | | max_active | Initiatives that may be open and executing at once | | review_interval_seconds | Cadence of selection, reviews and blocked-work retries | | observation_interval_seconds | Cadence of each observation source, and the oldest evidence a decision may cite | | sources | Any of product_catalog, product_analytics, market_research, operator_decisions, fleet_services |
Budgets, the initiative limit, the call reserve, max_active and both intervals must be positive; exploration may be zero; no allocation may exceed budget_usd; sources must not be empty. Otherwise startup is refused with ecosystem policy has an invalid version, scope, budget or observation schedule. workspace_root must be absolute and canonical, and the state directory must be owner-only and outside it.
On restart the persisted policy and owner must be the ones the store was created with, and the policy sequence may advance but not roll back: ecosystem authority differs from its persisted policy; authority cannot change on resume, ecosystem owner differs from its persisted principal; execution credentials cannot change owner on resume, ecosystem policy sequence is missing or would roll back. A second owner of the same state directory is refused by its lock.
Observation
Each policy source is read on its own cadence; a failing source records an observation_failed issue and does not stop the others:
| Source | Command | | --- | --- | | product_catalog | stado product --catalog <workspace_root>/stado/catalog/products.yml catalog --json | | product_analytics | echo-cli analytics 7 | | market_research | echo-cli market | | operator_decisions | oko transcripts tasks --open --read-only --json | | fleet_services | stado service list --json |
Selection and review
Once per review_interval_seconds, while fewer than max_active initiatives are open, one model call proposes proactive work from the latest observations, the portfolio and the policy — or nothing. A proposal must name exact observation ids no older than observation_interval_seconds, a measurable expected outcome, a rejection condition and alternatives; it is recorded as a proposed opportunity before review.
The review first applies the policy: an estimated cost outside the initiative limit, an invalid product identifier, a product opportunity without allow_product_creation, or an existing-product opportunity outside product_ids is rejected without a model call. Otherwise a separate model call reviews it against the same evidence. A rejected opportunity stays in the record.
An accepted opportunity becomes an initiative only while fewer than max_active are open, while no open initiative holds the same product (it waits with product_scope_busy), and, for product and research work, while the exploration allocation covers it. Each model call's request, evidence and answer are retained; a call whose answer was recorded settles on restart without asking again.
Each of these model calls — the proposal, its review and the outcome judgement — declares one function, answer, whose parameters are the judgement's JSON Schema, and reads the arguments of that one call: the proposal's opportunity or null, its kind one of feature, product, research, growth or maintenance; the review's accept, rationale, evidence and rejection reasons; the outcome's decision, one of continue, change, maintain, stop or unknown. A reply that calls no function, another function, or arguments outside the schema refuses the judgement with the reply named; no answer is JSON read out of text. The product identifier a proposal names is checked by the same rule provisioning applies.
Execution and delivery
A product opportunity is first provisioned: stado product create --request <file> --allow-create --json for the private repositories wisent-ai/<id>, wisent-ai/<id>-desktop and wisent-ai/<id>-landing. Provisioning is not implementation; the executor still owes the product.
The initiative then goes to Jeden as one immutable request: jeden pursue --request-file <file> --model <model> --allow-write --allow-command --json. Its allocation is reserved before dispatch. A later pass reads jeden pursue --status, or continues a blocked run with --resume-run; a request whose outcome is indeterminate is never replayed. A succeeded run must carry an accepted receipt and settles its cost; a cost above the reservation pauses admission.
With allow_release, the accepted commit's version is read from its .wisent-release.json, recorded, and submitted with stado release submit --source <checkout> --commit <commit> --version <version> --channel stable --json; an unanswered submission is resolved from stado release status and never resubmitted. After the run completes, each catalogued installation is read with stado product status and must report the accepted revision and readiness.
Native release workers use stado product kompilator stage and the immutable private-cargo-sources input instead of fetching private Git repositories. From a committed source checkout, publish and pin it with stado release catalog input pin . --name private-cargo-sources --source . --revision HEAD --cargo --json, then commit the updated .wisent-release.json before submission. Repeat when locked private package names, versions or revisions change. Stado's [private Cargo input contract](https://stado.wisent.com/docs/builds#private-cargo-build-inputs) documents the matching desktop operation, checksums, missing or stale input refusals, and real publication qualification. Both publisher and worker must support the interface; an input receipt alone does not qualify a native build or installed runtime.
Outcomes and controls
After delivery, a model call compares post-release observations with the original expected outcome and rejection condition and records continue, change, maintain, stop or unknown. Missing telemetry is unknown. Later selection reads these outcomes.
Selection, dispatch, provisioning, release and outcome review need open admission: not paused, and the signed Las catalog admitted. Observation and reconciliation of work already dispatched continue while paused. pause and resume change only admission; neither grants authority or allocation.
Singularity Desktop's Ecosystem screen talks to the same owner socket: the delegated owner, runtime revision, Las readiness, issues, opportunities, initiatives with Explain decision and delivery and Browse execution and outcome history, Pause selection / Resume selection, and a record browser that reads a record by kind and id.
Availability
The runtime ships in source. No host runs an owner until Singularity's service is declared and installed, and no qualification of unattended operation exists yet.