Production evidence is often scattered across tickets, test runs, monitoring tools and team messages. A coordination Virtual Employee assembles that evidence, exposes gaps and keeps the rollout record current. Approval and execution stay with named people.
Joint guidance from CISA, the FBI and the Australian Signals Directorate's Australian Cyber Security Centre recommends controlled deployment, including limited canary releases that teams can monitor before wider rollout.[1] NIST's Secure Software Development Framework is a set of high-level practices designed to fit different software development life cycles, and it gives producers, purchasers and other stakeholders a shared vocabulary.[2] MAJLS adapts those ideas here into a change-coordination workflow. Neither source prescribes this exact pack or endorses it.
The coordinator may collect approved records, check required fields, link evidence, schedule tasks, watch pre-defined signals and draft go, hold or rollback packets. It may not change code or configuration, approve a release, start deployment, expand exposure, halt, roll back, contact customers or close the change.
The change-to-release evidence pack
Use one record for the whole change. Keep rejected assumptions and failed checks visible rather than replacing them with a cleaner summary.
- Change record: request, purpose, owner, affected services, version, dependencies, planned window and customer-facing risk.
- Readiness block: test evidence, security and privacy reviews, operational impact, support preparation, monitoring signals, migration conditions and recovery prerequisites.
- Staged rollout: first cohort, expansion sequence, observation windows, and go, hold and rollback conditions defined before deployment.
- Authority map: one named role for each approval or execution decision, with deputies recorded under the organization's own policy.
- Chronology: every task, signal, packet and decision linked to its source, author and time.
- Rollback packet: last known good version, trigger, data safeguards, named executor, validation checks and post-rollback owner.
The coordinator should mark a block ready only when the required source evidence exists. A blank field, unavailable owner or conflicting check remains visible. Model confidence cannot turn any of those states into approval.
Filled example: a routing-rule change
This is an illustrative example. Cedar Notice is a fictional customer-notification service; all identifiers, systems and observations are synthetic. This is not a client, deployment, product capability or performance result.
Change record
| Field | Filled value |
|---|---|
| Change reference | CHG-2026-041, synthetic |
| Purpose | Route low-priority service notices through delivery path B |
| Owner | Messaging service owner |
| Version | Routing rules 4.7.2 |
| Affected service | Cedar Notice, fictional |
| Dependencies | Template service, preference store, delivery path B and notice-status monitor |
| Planned window | 30 September, 20:00–21:30 Gulf Standard Time |
| Customer-facing risk | A notice may be delayed, duplicated or assigned the wrong delivery path |
| Explicit exclusion | Priority alerts and regulated notices stay on the existing route |
Readiness block at 17:00
| Evidence | Source | Owner | State |
|---|---|---|---|
| Rule tests for included and excluded notice classes | Test run TR-4721 | QA lead | Passed; source linked |
| Dependency compatibility | Signed dependency checklist DEP-88 | Service owners | Passed |
| Security and privacy review | Review SEC-144 | Security and privacy owners | Approved for this change scope |
| Support preparation | Draft runbook SUP-31 | Support lead | Ready; activation requires release approval |
| Monitoring | Delay, duplicate, route-mismatch and queue-depth signals | Reliability lead | Available; synthetic baselines recorded |
| Recovery prerequisite | Version 4.7.1 retained and restorable | Release engineer | Verified |
| Data migration | None planned | Change owner | Confirmed in change record |
The Virtual Employee does not judge whether the tests are technically sufficient. It checks that the policy-required records are present, current, owned and consistent, then routes any gap to the named reviewer.
Staged rollout plan
| Stage | Exposure | Observe for | Go evidence | Hold condition | Rollback condition |
|---|---|---|---|---|---|
| 1 | Synthetic internal notices only | 15 minutes | All expected notices use path B; exclusions remain on the existing route | Any required signal is unavailable | Wrong route, duplicate notice or integrity-check failure |
| 2 | Pre-approved low-priority internal cohort | 30 minutes | Stage 1 remains valid and the release owner approves expansion | Delay rises above the change-specific bound or an owner is unavailable | Repeated wrong route, duplicate notice or failed recovery prerequisite |
| 3 | Pre-approved limited external cohort | 45 minutes | Source-linked checks pass and business plus release owners approve expansion | Support reports an unexplained notice problem | Customer-impact evidence meets the organization's recorded rollback rule |
These conditions are examples, not universal thresholds. The service owner must set bounds from architecture, policy, risk tolerance and tested operating data before the window begins.
Human authority map
| Coordinator may prepare or track | Named person must approve or execute |
|---|---|
| Verify that required evidence is linked | Release authority approves initial deployment |
| Issue reminders and show missing owners | Authorized engineer executes the change |
| Watch the pre-defined signals | Release and business owners approve each expansion |
| Draft a hold or rollback packet | Release authority orders a halt or rollback |
| Draft customer-impact copy from confirmed facts | Communications owner approves any customer notice |
| Assemble closure evidence | Change owner approves final closure |
Consequential approval remains with the named human release authority and other policy-defined owners. The coordinator cannot treat silence, elapsed time or model confidence as permission.
Live chronology
| Time | Entry | Source | State |
|---|---|---|---|
| 17:00 | Readiness pack assembled | Linked records above | One owner review outstanding |
| 18:12 | Security and privacy review signed | SEC-144 | Readiness complete |
| 19:45 | Release packet issued | CHG-2026-041 | Awaiting human approval |
| 20:02 | Initial deployment approved | Release authority decision | Engineer may execute stage 1 |
| 20:09 | Stage 1 started | Deployment record DEP-472 | Observation open |
| 20:18 | Route-mismatch signal unavailable | Monitor event MON-91 | Hold packet prepared; no expansion |
Even if monitoring returns, the 20:18 entry stays in the evidence for the next human decision.
Rollback packet at 20:18
- Trigger under review: a required route-mismatch signal is unavailable during the observation window.
- Last known good version: routing rules 4.7.1.
- Data safeguard: preserve notice IDs and delivery receipts before and after any rollback; do not replay notices automatically.
- Named executor: on-duty release engineer after an authorized rollback order.
- Validation checks: confirm version 4.7.1 is active, excluded classes still use the original route, queues are stable and a synthetic notice completes once.
- Post-rollback owner: messaging service owner verifies service state; support lead checks for related reports.
- Communication state: no customer notice drafted or sent unless the communications owner requests and approves one.
CISA's guidance calls for a detailed recovery plan with reversion steps, validation checks and safeguards against data loss.[1] The filled packet turns that principle into inspectable change evidence without letting the coordinator execute the recovery.
First-run checklist
- Choose the system of record and link every supporting item rather than copying untraceable summaries.
- Name release, business, engineering, security, privacy, support and communications owners, plus policy-defined deputies.
- Define required evidence and observable go, hold and rollback conditions before the change window.
- Test missing monitoring, conflicting checks, unavailable owners and rollback validation with synthetic records.
- Require a fresh human approval for initial deployment and every expansion.
- Keep failed checks, rejected assumptions and superseded decisions in the chronology.
- Close only after the named owner verifies service state, evidence retention and required follow-up work.
This role earns its place by keeping the release decision inspectable. It does not make the decision.