Memory graph and asset health

Use this page to inspect and maintain the local memory graph in standalone Evolver, separating graph faults from asset quality and event-view problems.

Topology here primarily means the relationship structure of the local memory graph and its assets. It can expose orphaned, duplicated, stale, or unusually concentrated experience. It is not an automatic scheduler, trust promoter, or publisher.

Inspect diagnostics

evolver memory-graph status
evolver asset-health
evolver reuse-report
evolver cycles

Conditions to investigate

• Many assets have no traceable provenance, validation, or reuse relationship.
• Similar failures keep creating new assets without convergence or revocation of old strategies.
• A few stale assets dominate recall while new real outcomes do not enter the graph.
• Events exist but materialized views are missing, or report counts disagree.
• Reuse remains concentrated in one environment with no cross-environment evidence.

Separate source events, derived views, and graph state

Root events retain activity records; materialized views organize those events for reading. The memory graph has its own current state, compact state, and retained archives. Identify the affected data before choosing recovery. Replaying events, pruning archives, and resetting the graph together because a report is incomplete makes the original fault harder to locate.

What recovery can reconstruct

Graph recovery rebuilds compact state from retained current-epoch data. Maintenance cannot recreate deleted source data. Archive pruning reduces retained history, so it is not a universal first repair step. Reset begins a new generation of local state; its backup does not remove the need to explain why the current generation is being replaced.

For example, investigate active processes for busy status, let controlled work finish or stop relevant writes through maintenance procedures, then query again. If state is healthy after contention clears, recovery or reset is unnecessary. Each action should address a confirmed problem; its result determines the next step.

Investigation order

1. Confirm the runtime directory and node identity, and preserve the failure-time status report. Do not mix data from different instances.
2. Use memory-graph status to inspect recovery and busy states. Distinguish degraded from busy: investigate retained recovery data for the former and active writers or maintenance processes for the latter.
3. Check asset IDs, recent cycles, and reuse evidence. Missing validation requires validation work; graph maintenance cannot create success evidence.
4. Pause relevant writes and back up the graph directory before a mutating operation. Choose one action below, then inspect status again.
5. If the fault is in root-event derived views, verify the event source and backup before using evolver replay. Replay does not recover memory-graph archives.

Choose a maintenance action

An epoch is a generation of local graph state. Reset is not routine repair and does not rebuild event views. These maintenance commands have no --dry-run option. The table is a selection guide, not a script to run line by line.

Confirm recovery

Check that degraded or abnormal busy state is resolved. Retain the maintenance report, backup location, and before/after changes, then verify the affected assets and reuse records. If failure persists, stop further cleanup and hand the error and retained archives to the runtime owner.

Operating boundary

Graph density, repetition, or group relationships can trigger investigation. They cannot by themselves raise Worker capacity, promote an asset, or classify a node as unhealthy.

Related pages

• Quality signals
• Audit trail

EvoX Docs · Developers · Experience asset management