Operations
Deploy traces
Deploy traces connect release activity to business impact. ISAAC records what changed, which services or adapters were affected, which smokes passed, and which rollback path exists.
Why deploy proof matters
A deploy can change model routing, source access, workflow behavior, or frontend behavior. Without a trace, teams can see that something broke but not why.
ISAAC treats deployments as evidence-bearing events. The deploy should include version, timestamp, comment, owner, expected behavior, smoke result, and rollback target.
Steward and Sentinel roles
Steward stores the outcome history and compares intent to result. Sentinel shows live health, affected domains, impacted workflows, and recommended actions.
Both should advise clearly without hiding mutation. If rollback or scale-up is recommended, the command should be visible and human-confirmed unless a separate policy explicitly permits automation.
What good looks like
A good deploy trace explains what shipped, which tests ran, which services were touched, which domains are affected, what the current health is, and where the rollback evidence lives.
For client-facing work, that same trace becomes part of the trust story: the system can prove how it changes, not just how it answers.