Use the publication form for a new plan. Use a linked lifecycle request when an existing solution changes, needs a temporary exception, or is ready to retire.
Manual retirement review and verified execution. No automatic deletion or revocation.
Request publication
Describe the solution's business purpose, capabilities, and how AI helped build it or acts at runtime. Supply the repository and all existing owner/risk fields, a target go-live date in YYYY-MM-DD format, and target environment dev, test, or prod. Confirm the three required attestations: no sensitive content, guide read, and responsibility for completing control issues with evidence.
Tiering choice: Description, requested date, target environment, and attestations are human-review context recorded only in the source issue. They are not parsed into the risk model or copied to generated issues. The existing structured risk answers remain authoritative. Dev/test does not lower the tier, a deadline does not waive controls, and an attestation is not proof of security.
The form requires these entries through GitHub's form UI; direct API submissions and later edits can omit them. A maintainer must check completeness, date validity, and attestations before processing and final review. Legacy requests still parse without the new fields. Metadata does not change the plan fingerprint, although an intake edit invalidates advisory approval and a new /publish run clears prior approval.
Use this when an approved solution's purpose, data, exposure, audience, integration privileges, hosting, or runtime AI changes. Link the original governance request and affected control issues. Compare current and proposed scope, describe the impact on evidence, name an accountable technical team, and request a change date.
Governance manually verifies the link and same solution repository, cross-links both requests, and removes ready-for-review and approved-for-production from the original request while reassessment is pending. Merely opening this form does not invalidate the original labels automatically.
Governance reopens the original publication request if closed, updates its structured intake answers to the new scope, and records the change decision and metadata there. Do not add publication-request to the reassessment issue or run commands on it: its issue number would create a separate marker namespace and duplicate the plan.
An authorized maintainer comments /publish on the original request. The existing automation re-tiers it, reuses the same parent and control issues, and creates only missing applicable controls. Changes to parsed intake or selected control definitions reopen required existing issues for fresh evidence. Every /publish run clears prior approval. Historical, no-longer-applicable issues remain for audit.
If scope changes leave the parsed answers and selected control definitions unchanged—for example, different runtime-model behavior while AI remains Yes—governance must assess the evidence impact and manually reopen affected controls for fresh evidence. Description and other metadata edits do not change the plan fingerprint, so /publish alone leaves completed controls closed in this case.
Complete the refreshed controls, run /validate on the original, and obtain a new human governance decision before release. Record links and the outcome in the reassessment issue, then close it.
A different solution repository requires a new publication request, not rebinding the original. Repeating unchanged intake does not duplicate controls or automatically reopen completed controls.
Use one request per exact catalog control ID. Link the original request and generated control issue. Explain the justification, residual risk, compensating controls and safe evidence, proposed expiry, and the accountable risk owner.
Governance validates the scope, date, mitigations, and authority of the named risk owner. Assign a reviewer and arrange a review/reminder before expiry in your approved tracking system; this toolkit does not send expiry reminders.
The accepting authority and governance explicitly record approval or rejection, scope, conditions, expiry, and remediation owner. Closing a request by itself is not approval. Link the decision from the original request and control issue.
Track implementation, remediation, renewal, and revocation manually. Renewal requires a fresh review. On expiry, the waiver no longer applies; reassess or stop the affected activity through the protected release/operations process.
No bypass: An exception does not change tiering, close generated issues, or convert FAIL/UNKNOWN to PASS. The stock gate continues to report its gaps. Any separately authorized manual production decision must say explicitly that automatic readiness was not achieved; never present an accepted waiver as a clean automated report.
Link the original request, identify the solution repository and accountable retirement team, propose a date, and document user impact, communications/migration, resources/access, and data retention/disposal. If no original request exists, explain that rather than inventing a link.
Business, technical, platform, data owners, and governance review the plan, rollback needs, retention, legal holds, and required approvals before destructive action.
Authorized operators execute the approved retirement: disable deployments and federation where appropriate, revoke unnecessary access/credentials, retire cloud resources and integrations, and verify billing, monitoring, DNS, data migration, and lawful disposal. The toolkit does none of this automatically.
Record safe evidence and owner confirmation. Governance removes readiness/production approval from the original request, records its retirement, and closes it to end the daily validation sweep. Preserve tracking issues, decisions, and required audit records rather than deleting history.
Close the decommission request only when agreed work and evidence are complete. Treat any later revival as a new governance decision.
Keep the three manual forms on their distinct labels. Do not add the automation's publication-request label to them. The bundled workflows and daily sweep process publication requests only; comments on manual forms do not run intake or validation. Required checkboxes and date prompts support review but are not a security boundary or date-validation engine.