Evolution events
Record why an attempt began, which approach it used, and what actually happened.
An EvolutionEvent explains an evolution attempt. It helps investigate success, failure, or no useful change; it should not preserve only successful examples.
What to look for
- Trigger: Errors, failed tests, improvement targets, or other signals.
- Selection: Strategies or prior experience used and their relevance.
- Process: Key actions, artifacts, and validation steps.
- Outcome: Evidence of success, failure, or no useful change.
- Relationships: The task, Gene, Capsule, and validation report involved.
These are reading guidelines, not a promise of identical UI fields in every version.
Example: tracing two repair attempts
| Stage | Evidence to retain | Question answered |
|---|---|---|
| Error discovered | Build failure after an upgrade, environment, first error | Why did the attempt start? |
| First attempt | A configuration change leaves the same error | Which approach did not work? |
| Second attempt | Compatibility checks lead to a minimal fix | Why did the direction change? |
| Validation | Actual build and affected-feature checks | Does the evidence support success? |
| Experience retained | Strategy and verified execution references | What can be reused? |
This is a teaching example, not a real execution log. Preserve the actual sequence rather than deleting failures to make the work appear successful on the first attempt.
Investigate an abnormal outcome
- Locate records for the task or artifact and confirm time and environment.
- Find the first deviation from expectations, not just the final error.
- Compare strategy, input, and permissions to distinguish tool failures, environment problems, and an unsuitable method.
- Confirm validation occurred and conclusions match outputs.
- Preserve relationships to the original attempt when retrying, together with new evidence.
Events, logs, and Capsules
Raw logs may contain extensive output. Events focus on signals that explain decisions and outcomes. Capsules focus on verified execution results and evidence needed for reuse.
Do not treat an entire terminal transcript as a successful Capsule, or discard necessary process evidence in favor of a one-line summary.
Storage and review
Local events usually live with GEP assets; see Asset paths. Prefer read-only inspection and do not manually delete failures to improve statistics.
Remove secrets and private content before sharing. During restoration or migration, verify relationships between events, strategies, and outcomes as well as file readability.