Versioning and rollback

Every agent has versions, and the release ledger in your deployment records each one: its gate decision, whether it passed, and which version is current. Only a version that passed its evaluations can be made current, and a rollback always goes to the last version that passed, never just the previous one.

Versions and releases

• A version is recorded with its gate decision and the digest of what was built.
• Promote makes a passed version current. A version that did not pass cannot be promoted.
• The orchestrator can require the ledger: then a card whose current version is not a released one does not run.

From LightHouse, a handler makes a released version current with the release.add command; the engine refuses it (gate-not-passed) unless that version passed the gate in your deployment. See Handlers.

In the deployment, the ledger’s own commands:

python -m aal_engine.assurance --ledger var/release-ledger.sqlite record <agent> <version> --decision decision.json --by ops@example.com
python -m aal_engine.assurance --ledger var/release-ledger.sqlite promote <agent> <version> --by ops@example.com
python -m aal_engine.assurance --ledger var/release-ledger.sqlite status

Rolling back

• Automatically: when the online monitor or a scheduled golden-set run finds a breach, the agent rolls back to the last version that passed its evaluations. With no passed version to return to, the agent is stopped through the gateway’s kill switch.
• By hand: python -m aal_engine.assurance --ledger var/release-ledger.sqlite rollback <agent> --by ops@example.com --reason "...", or release.add with the earlier version from LightHouse.

A rollback from a command line (lighthouse agents rollback) is Coming.

What is kept

Every version, every gate decision and every promotion and rollback stays in the ledger. Each release is also reported to LightHouse as a release record (pack, agent, version, digest, whether it passed the gate): see GET /api/v1/releases and Reinforcement → Evaluations and releases.