---
description: 'RAI review and backlog handoff for Phase 6: review rubric, RAI review summary, dual-format backlog generation'
applyTo: '**/.copilot-tracking/rai-plans/**'
---
# RAI Review and Backlog Handoff
Instructions for generating the review rubric, RAI review summary, and formatted backlog items from RAI assessment findings. Phase 6 produces dual-format work items (ADO and GitHub) compatible with the Security Planner backlog handoff for cross-referencing.
## Review Rubric
A review checkpoint and six quality dimensions evaluate the completeness and quality of the RAI assessment before backlog generation proceeds.
### Review Checkpoints
| Checkpoint | Criteria | Status |
|-----------------|----------------------------------------------------------------------|-------------------|
| Threat Coverage | Every RAI threat has at least one control surface and evidence entry | ☐ Met / ☐ Not Met |
Review checkpoints are binary verification steps. A checkpoint marked "Not Met" indicates the relevant phase should be revisited before proceeding with handoff.
### Review Quality Checklist
| Dimension | Description | Status |
|-----------------------|--------------------------------------------------------------------------------|-------------|
| Standards Alignment | Coverage of NIST AI RMF trustworthiness characteristics and subcategories | ☐ Addressed |
| Threat Completeness | AI STRIDE coverage, dual threat ID consistency, ML STRIDE matrix completion | ☐ Addressed |
| Control Effectiveness | Control surface coverage across Prevent/Detect/Respond for each characteristic | ☐ Addressed |
| Evidence Quality | Evidence register completeness, confidence levels, gap identification | ☐ Addressed |
| Tradeoff Resolution | Tradeoff documentation quality, stakeholder impact, decision authority | ☐ Addressed |
| Risk Classification | Risk classification coverage, depth tier justification, downstream alignment | ☐ Addressed |
Review status derivation:
* **Ready for stakeholder review** — All dimensions addressed with supporting evidence.
* **Additional attention suggested** — Most dimensions addressed; one or more areas flagged for further consideration.
* **Significant areas need further consideration** — Multiple dimensions have limited coverage or missing evidence.
Before presenting review quality results, explain the checklist dimensions and what each status means in plain language. Frame all assessments as suggested observations based on session findings.
When presenting review quality results, explain each dimension's status by citing specific session observations. For example: "Standards Alignment is addressed — the assessment mapped all seven NIST AI RMF trustworthiness characteristics to system components with subcategory cross-references."
## RAI Review Summary
Template for the review summary produced at the end of Phase 6.
```markdown
# RAI Review Summary
## System: {system-name}
## Assessment Date: {YYYY-MM-DD}
## Depth Tier: {Basic/Standard/Comprehensive}
### Review Checkpoint Results
| Checkpoint | Status | Notes |
|-----------------|---------------|---------|
| Threat Coverage | {Met/Not Met} | {notes} |
### Per-Characteristic Summary
| Characteristic | Maturity Level | Key Observations | Open Items |
|--------------------------------|------------------------------------------------|------------------|------------|
| Valid and Reliable | {Foundational/Developing/Established/Advanced} | {summary} | {count} |
| Safe | {level} | {summary} | {count} |
| Secure and Resilient | {level} | {summary} | {count} |
| Accountable and Transparent | {level} | {summary} | {count} |
| Explainable and Interpretable | {level} | {summary} | {count} |
| Privacy-Enhanced | {level} | {summary} | {count} |
| Fair with Harmful Bias Managed | {level} | {summary} | {count} |
### Key Findings
{Bulleted list of most significant findings from the assessment}
### Review Quality Summary
| Dimension | Status | Notes |
|-----------------------|-----------------------------|---------|
| Standards Alignment | {Addressed/Needs Attention} | {notes} |
| Threat Completeness | {Addressed/Needs Attention} | {notes} |
| Control Effectiveness | {Addressed/Needs Attention} | {notes} |
| Evidence Quality | {Addressed/Needs Attention} | {notes} |
| Tradeoff Resolution | {Addressed/Needs Attention} | {notes} |
| Risk Classification | {Addressed/Needs Attention} | {notes} |
### Suggested Remediation Horizon Summary
| Horizon | Work Item Count | Key Items |
|--------------------|-----------------|-------------|
| Pre-Production | {count} | {top items} |
| Early Operations | {count} | {top items} |
| Ongoing Governance | {count} | {top items} |
### Suggested Review Status: {Ready for stakeholder review / Additional attention suggested / Significant areas need further consideration}
### Remediation Suggested: {Yes/No}
### Work Items Generated: {count}
> **Note** — The author created this content with assistance from AI. All outputs should be reviewed and validated before use.
> - [ ] Reviewed and validated by a qualified human reviewer
```
Populate the Per-Characteristic Summary table from `principleTracker`: maturity level from the Phase 5 assessment, key observations from the most significant `openObservations` and `resolvedObservations`, open item count from `openObservations.length`.
When `principleTracker` data is incomplete for a characteristic, note the gap in the Key Observations column and suggest revisiting the relevant phase.
## Work Item Categories
Five categories classify RAI work items by purpose and urgency.
| Category | Description | Suggested Horizon | Priority Range | Source |
|------------------------|------------------------------------------------------------|--------------------|---------------------|---------------------------------------------------------------|
| Remediation | Address identified RAI gaps or areas of concern | Pre-Production | Immediate–Near-term | Evidence gaps, characteristics with limited coverage |
| Control Implementation | Implement new Prevent/Detect/Respond controls | Pre-Production | Near-term–Planned | Control surface gaps |
| Monitoring Setup | Deploy detection and monitoring capabilities | Early Operations | Planned | Detect controls without implementation |
| Documentation | Create or update transparency and accountability artifacts | Ongoing Governance | Planned–Backlog | Documentation gaps, tradeoff records |
| Enhancement | Improve existing controls toward higher maturity | Ongoing Governance | Backlog | Characteristics at Developing or Established seeking Advanced |
## RAI Tags
Tags applied to work items for tracking and filtering across backlog systems.
| Tag | Purpose | Applied When |
|---------------------------------|---------------------------------------------|-----------------------------------------------------------------------------|
| `rai:valid-reliable` | Valid and Reliable related work | Control or finding relates to Valid and Reliable characteristic |
| `rai:safe` | Safe related work | Control or finding relates to Safe characteristic |
| `rai:secure-resilient` | Secure and Resilient related work | Control or finding relates to Secure and Resilient characteristic |
| `rai:accountable-transparent` | Accountable and Transparent related work | Control or finding relates to Accountable and Transparent characteristic |
| `rai:explainable-interpretable` | Explainable and Interpretable related work | Control or finding relates to Explainable and Interpretable characteristic |
| `rai:privacy-enhanced` | Privacy-Enhanced related work | Control or finding relates to Privacy-Enhanced characteristic |
| `rai:fair-bias-managed` | Fair with Harmful Bias Managed related work | Control or finding relates to Fair with Harmful Bias Managed characteristic |
| `rai:tradeoff` | Tradeoff resolution item | Originates from tradeoff documentation |
| `rai:cross-ref-security` | Cross-references Security Planner item | Overlaps with or extends a Security Planner work item |
## Target System Selection
Target system selection (ADO, GitHub, both) follows the canonical convention in `.github/skills/shared/backlog-templates/SKILL.md` under the Overview's Output Targets table. RAI emits work items to `.copilot-tracking/rai-plans/{slug}/backlog-handoff.md` as the neutral intermediate, with platform-specific files derived per the skill's Per-Platform Field Mappings.
## Dual-Format Backlog Templates
Both ADO and GitHub formats follow the canonical templates, field blocks, augmentation keys, title prefix, and temporary-ID conventions defined in `.github/skills/shared/backlog-templates/SKILL.md`. Read the RAI entries under "ADO Work Item Template", "GitHub Issue Template", and "Work Item ID Naming Convention" at emission time. RAI tag vocabulary lives in the tags section above. Execution follows `ado-update-wit-items.instructions.md` for ADO and `github-backlog-update.instructions.md` for GitHub.
## Content Sanitization Protocol
Content sanitization follows the five-rule protocol in `.github/skills/shared/backlog-templates/SKILL.md` under 'Content Sanitization Protocol'. RAI-specific standards identifiers that must be preserved verbatim per rule 4: NIST AI RMF 1.0 subcategory IDs (for example, `MAP-1.1`, `MEASURE-2.3`, `MANAGE-1.2`, `GOVERN-3.1`), characteristic names, and any regulatory mapping references (EU AI Act articles, ISO/IEC 42001 clauses) when present. Debug-mode output remains under `.copilot-tracking/rai-plans/{slug}/debug/`.
## Three-Tier Autonomy Model
The three-tier autonomy model is defined canonically in `.github/skills/shared/backlog-templates/SKILL.md` under 'Autonomy-Tier Enumeration'. RAI uses the divergent vocabulary `Full` / `Partial` / `Manual` (see the cross-reference table in the skill). Default tier on first use is `Partial`. Persist the selected tier in session state under `userPreferences.autonomyTier`. Ask the user in Phase 6 which tier they prefer.
## Suggested Priority Derivation
Derive suggested work item priority and autonomy tier from assessment observations and principleTracker data.
| Assessment Observation | Suggested Priority | Autonomy Tier | Suggested Horizon |
|------------------------------------------------------------|--------------------|---------------|--------------------|
| Characteristic at Foundational maturity with critical gaps | Immediate | Manual | Pre-Production |
| Characteristic at Foundational maturity | Near-term | Manual | Pre-Production |
| Multiple open observations for a characteristic | Near-term | Partial | Pre-Production |
| Tradeoff requiring implementation | Planned | Partial | Early Operations |
| Control surface gap (Prevent) | Near-term | Partial | Pre-Production |
| Control surface gap (Detect) | Planned | Partial | Early Operations |
| Control surface gap (Respond) | Planned | Partial | Early Operations |
| Documentation gap | Backlog | Full | Ongoing Governance |
| Enhancement recommendation | Backlog | Full | Ongoing Governance |
Within the same priority level, order remediation items before control implementation items. Consider Fair with Harmful Bias Managed and Valid and Reliable findings for earlier attention due to direct impact potential.
When multiple observations apply to a single work item, use the highest suggested priority among them.
When work item A depends on work item B, note the dependency in both work item bodies and place B earlier in the handoff sequence.
## Cross-Reference Protocol for Security Planner Interop
RAI work items relate to Security Planner work items when threats overlap across both assessments.
Rules:
* When an RAI threat overlaps with a Security Planner threat (identified by dual `T-{BUCKET}-AI-{NNN}` IDs), the RAI work item includes a cross-reference field.
* Security Planner work items are not duplicated. RAI items extend or complement them instead.
* Cross-reference format: `Security-Ref: WI-SEC-{NNN}` in ADO, `Security: #{NNN}` in GitHub.
* The handoff summary includes a cross-reference table listing all overlapping items.
* Before creating new work items, search for existing Security Planner items with matching threat IDs or control surfaces. Link rather than duplicate.
Cross-reference table template:
| RAI Work Item | Security Work Item | Relationship | Notes |
|---------------|--------------------|---------------------------------|---------------|
| WI-RAI-{NNN} | WI-SEC-{NNN} | Extends / Complements / Depends | {description} |
Relationship types:
* Extends: RAI item adds RAI-specific requirements to an existing security control.
* Complements: RAI item addresses a different aspect of the same threat.
* Depends: RAI item requires the security control to be implemented first.
## Handoff Summary Format
After generating all work items, produce a handoff summary covering totals, cross-references, and outstanding decisions.
```markdown
# RAI Backlog Handoff Summary
## System: {system-name}
## Date: {YYYY-MM-DD}
## Suggested Review Status: {Ready for stakeholder review / Additional attention suggested / Significant areas need further consideration}
### Work Item Summary
| Category | Count | Immediate | Near-term | Planned | Backlog |
|------------------------|---------|-----------|-----------|---------|---------|
| Remediation | {n} | {n} | {n} | {n} | {n} |
| Control Implementation | {n} | {n} | {n} | {n} | {n} |
| Monitoring Setup | {n} | {n} | {n} | {n} | {n} |
| Documentation | {n} | {n} | {n} | {n} | {n} |
| Enhancement | {n} | {n} | {n} | {n} | {n} |
| **Total** | **{n}** | **{n}** | **{n}** | **{n}** | **{n}** |
### Suggested Remediation Horizon Breakdown
| Horizon | Count | Key Items |
|--------------------|-------|-----------|
| Pre-Production | {n} | {items} |
| Early Operations | {n} | {items} |
| Ongoing Governance | {n} | {items} |
### Security Planner Cross-References
| RAI Item | Security Item | Relationship |
|--------------|---------------|----------------|
| WI-RAI-{NNN} | WI-SEC-{NNN} | {relationship} |
### Outstanding Tradeoffs
{list of tradeoffs requiring stakeholder decisions}
### Next Steps
{recommended follow-up actions}
> **Note** — The author created this content with assistance from AI. All outputs should be reviewed and validated before use.
> - [ ] Reviewed and validated by a qualified human reviewer
>
> **Disclaimer** — This agent is an assistive tool only. It does not provide legal, regulatory, or compliance advice and does not replace Responsible AI review boards, ethics committees, legal counsel, compliance teams, or other qualified human reviewers. The output consists of suggested actions and considerations to support a user's own internal review and decision‑making. All RAI assessments, risk classification screenings, security models, and mitigation recommendations generated by this tool must be independently reviewed and validated by appropriate legal and compliance reviewers before use. Outputs from this tool do not constitute legal approval, compliance certification, or regulatory sign‑off.
```
Log all generation decisions (create, update, skip, link) in the handoff summary. Items that could not be generated include the reason for each failure.
## Optional Artifacts
During Phase 6, offer each optional artifact independently. Generate only those the user opts into. Each accepted artifact produces a corresponding "Documentation" category work item for completion.
### Transparency Note Outline
Ask: "Would you like a transparency note outline included in the handoff?"
When accepted, generate a skeleton transparency note appended to the handoff summary:
```markdown
## Transparency Note Outline (Draft)
### System Purpose
{What the system does, target users, and intended deployment context}
### Capabilities
{What the system can do within its designed scope}
### Limitations
{Known boundaries, failure modes, and conditions where accuracy degrades}
### Data Usage
{Training data sources, inference inputs, data retention, and privacy considerations}
### Decision Process
{How the system produces outputs, confidence indicators, and key algorithmic choices}
### Human Oversight
{Human-in-the-loop checkpoints, escalation paths, and override mechanisms}
### Contact and Feedback
{How users report issues, request explanations, or provide input on system behavior}
> **Note** — The author created this content with assistance from AI. All outputs should be reviewed and validated before use.
> - [ ] Reviewed and validated by a qualified human reviewer
```
Generate a "Documentation" category work item: `[RAI] Complete transparency note from Phase 6 outline`. Assign priority Planned–Backlog and tag `rai:accountable-transparent`.
### Monitoring Summary
Ask: "Would you like a consolidated monitoring summary included in the handoff?"
When accepted, auto-populate from "Monitoring Setup" category work items generated during the assessment. This unified view prevents individual monitoring work items from becoming disconnected.
```markdown
## Monitoring Summary
| Work Item | Metric | Threshold/Criteria | Alert Mechanism | Review Cadence |
|--------------|---------------|--------------------|-------------------|----------------|
| WI-RAI-{NNN} | {metric_name} | {threshold} | {alert_mechanism} | {cadence} |
> **Note** — The author created this content with assistance from AI. All outputs should be reviewed and validated before use.
> - [ ] Reviewed and validated by a qualified human reviewer
```
Generate a "Documentation" category work item: `[RAI] Validate and operationalize monitoring summary`. Assign priority Planned and tag `rai:accountable-transparent`.
### Artifact Signing
Ask: "Would you like cryptographic signing of all session artifacts?"
When accepted, invoke `npm run rai:sign -- -ProjectSlug {project-slug}` via `execute/runInTerminal`. The script generates a SHA-256 manifest (`artifact-manifest.json`) covering all files in the project directory and optionally signs it with cosign when available. After execution completes, update `state.json` fields `signingRequested` to `true` and `signingManifestPath` to the manifest output path.
If the user also requests cosign signing, append `-IncludeCosign` to the command. Cosign uses keyless signing via Sigstore; it requires `cosign` in PATH and an OIDC identity provider.
Generate a "Documentation" category work item: `[RAI] Verify artifact manifest integrity and configure signing in CI pipeline`. Assign priority Planned-Backlog and tag `rai:accountable-transparent`.
## Audience Adaptation
Adjust handoff output formatting based on `userPreferences.audienceProfile`:
* **technical** — Full implementation detail with control specifications, threat IDs, and suggested monitoring thresholds.
* **executive** — High-level summary with business impact, characteristic maturity overview, and key action items.
* **compliance** — Full detail with regulatory mapping, standards traceability, and audit trail references.
* **mixed** — Balanced format with executive summary followed by technical detail sections.
Default to **technical** when no preference is set. The audience profile affects the RAI Review Summary, work item descriptions, and handoff summary formatting.microsoft/hve-core
Publicmirrored fromhttps://github.com/microsoft/hve-coreAvailable
.github/instructions/rai-planning/rai-backlog-handoff.instructions.md
334lines · modepreview