Nodes and runtime inventory

A node inventory answers which runtime operates in which environment, with which identity, version, and policy. It stores operational metadata that can be shared safely, not node_secret, Hub tokens, or private keys.

Separate Desktop and standalone identities

Desktop distinguishes an unregistered local node, a registered but unclaimed node, and an account-claimed node. Check registration and claim state in the EvoMap panel. Record the signed-in account separately from local node identity. The CLI checks below apply to standalone Evolver; a machine name or account login does not establish a node claim.

Distinguish device, account, runtime, and node

A device identifies where software runs. An account identifies the signed-in user. A runtime is determined by its launch entry, process user, and data directory. Node identity correlates activity on the Hub. An inventory must retain the relationships between these objects.

For example, Desktop and standalone Evolver on one computer require separate runtime entries linked to the same device. Desktop sign-in does not establish local-node registration or claiming, and the standalone directory cannot be inferred from Desktop paths.

Distinguish migration, identity replacement, and expansion

Migration transfers an existing responsibility to another location: record takeover time, the original instance's stopped state, and the new directory. Replacing identity changes the identity attached to future activity, so retain the old-to-new relationship. An additional instance needs its own owner, purpose, allowed scope, and acceptance record.

Investigate from the configuration read by the actual process. If a service uses a different system account from the current terminal, verify their home directories separately. A healthy terminal result describes the instance that command inspected. Match identity and directory before using that result to explain background-service health.

Record for each node

Collect current state

evolver status
evolver doctor
evolver lifecycle status

Standalone Evolver and EvoX Desktop manage identity homes separately. The same machine name does not imply a shared node; inventory by the actual home and node_id.

Update rules

1. Update immediately after installation, migration, identity recreation, Hub changes, or service-mode changes.
2. Preserve before-and-after times for upgrades and credential rotation instead of overwriting history.
3. On retirement, record stop time, asset handoff, credential revocation, and backup location.
4. Reconcile the inventory with observed runtime state rather than maintaining the spreadsheet alone.

Security boundary

The inventory may include node IDs, versions, and owners, but not secrets, complete environment files, or internal URLs with access parameters. Apply redaction and request-tracing rules when logs are shared.

Match instances to directories

Start with the actual service or launch configuration: record its process user, entry point, and data directory, then match the identity in status output. Standalone Evolver resolves its state root from EVOLVER_HOME, then EVOMAP_HOME, then ~/.evomap. Record entry-specific identity-directory overrides separately. Desktop uses its own internal directories; do not apply standalone path assumptions to it.

If multiple running instances share a node ID, or a service changes directories unexpectedly, pause new tasks and inspect launch configuration before deleting anything. Acceptance requires an owner, version, and directory for each instance, with separate evidence for registration, claiming, and account sign-in.

Related pages

• Change accounts and remove connections
• Node credentials
• Runtime policy

EvoX Docs · Developers · Deployment and policy