@elnora-ai/linear 1.0.1 → 1.1.0

package/references/workspace-routing.md

@@ -0,0 +1,58 @@
+# Workspace Routing
+
+Schema/template for documenting how your workspace's teams + projects + labels map to your work intake. Replace the examples below with your own workspace structure; populate `teams.json`, `projects.json`, and `label-policy.json` with the underlying machine-readable data.
+
+## Teams (example)
+
+| Team | Prefix | Use For |
+|------|--------|---------|
+| **Engineering** | ENG- | Customer-facing product code, features, bugs |
+| **Operations** | OPS- | Internal: tooling, compliance docs, HR, access management |
+| **Security** | SEC- | CVE/vulnerability remediation, pentest findings, incidents (not security features) |
+| **Customer Success** | CUS- | Customer support, onboarding, client feedback |
+
+## Routing Keywords (example)
+
+| Keywords | Route To |
+|----------|----------|
+| feature, bug, build, implement, develop, code, product, ship, api, ui | **Engineering** |
+| vulnerability, CVE, CodeQL, dependabot, pentest finding, patch, security incident | **Security** |
+| internal tooling, internal infrastructure, dev environment, plugin, marketplace, cli setup | **Operations** |
+| document, record, audit, review completed, change approved, compliance | **Operations** |
+| onboarding, offboarding, access provision, access revoke, quarterly review | **Operations** |
+| change request, policy change, procedure change, ISMS change | **Operations** |
+| internal audit, management review, corrective action, risk assessment | **Operations** |
+| AI use case, AI capability scope, model family change, foundation model swap, AI governance | **Operations** |
+| hr, admin, process improvement, team operations, company operations | **Operations** |
+| customer, support request, user reported, client feedback, customer onboarding | **Customer Success** |
+
+**Default:** Engineering
+
+## Project Keywords (schema)
+
+Each project belongs to a specific team. Document yours in `workspace-projects.md` and keep the underlying mapping in `projects.json`.
+
+| Project | Keywords | Team |
+|---------|----------|------|
+| `<Project name>` | `<keyword1>, <keyword2>, ...` | `<team>` |
+
+## State Mapping (example)
+
+| Project Status | Issue State |
+|----------------|-------------|
+| In Progress | Todo |
+| Planned | Todo |
+| Backlog | Backlog |
+
+(see `recommendedStateForStatus` in the CLI; this table is the human-readable version of that logic.)
+
+## Assignees
+
+Document your team's assignment rules here. Common patterns:
+
+- Map roles to default assignees (e.g. "platform code → Platform lead").
+- Rule of thumb: ASK the user for an assignee if not specified — defaults can silently route to the wrong person.
+
+---
+
+*Projects: `workspace-projects.md` | Labels: `workspace-labels.md` | Run `elnora-linear sync all` to refresh JSON references from Linear.*

package/schemas/label-policy.json

@@ -0,0 +1,72 @@
+{
+	"$schema": "https://json-schema.org/draft/2020-12/schema",
+	"$id": "https://github.com/Elnora-AI/elnora-linear/blob/main/schemas/label-policy.json",
+	"title": "Label Policy",
+	"description": "Per-team required-label rules. Read by `issues create`, `issues update`, and `context` to surface required labels + enforce them at write time. Keyed by team key.",
+	"type": "object",
+	"additionalProperties": false,
+	"properties": {
+		"$schema": { "type": "string" },
+		"_placeholder": { "type": "boolean", "const": true },
+		"_example": { "type": "boolean", "const": true },
+		"_populated_by": { "type": "string" },
+		"policies": {
+			"type": "object",
+			"description": "Map of team key → policy. Keys are uppercase Linear team keys (e.g. ENG).",
+			"patternProperties": {
+				"^[A-Z][A-Z0-9]*$": {
+					"type": "object",
+					"additionalProperties": false,
+					"required": ["name", "required", "allowedPrefixes"],
+					"properties": {
+						"name": {
+							"type": "string",
+							"minLength": 1,
+							"description": "Human-readable team name (informational; the key is canonical)."
+						},
+						"required": {
+							"type": "array",
+							"description": "List of required label-prefix groups; each group must be satisfied for a write to succeed.",
+							"items": {
+								"type": "object",
+								"additionalProperties": false,
+								"required": ["prefixes", "min"],
+								"properties": {
+									"prefixes": {
+										"type": "array",
+										"items": { "type": "string", "minLength": 1 },
+										"description": "Any label whose name starts with one of these prefixes counts toward this group."
+									},
+									"min": {
+										"type": "integer",
+										"minimum": 0,
+										"description": "Minimum total label count across the listed prefixes."
+									},
+									"max": {
+										"type": ["integer", "null"],
+										"description": "Maximum total count, or null for no upper bound."
+									},
+									"description": {
+										"type": "string",
+										"description": "Human-readable hint surfaced in error responses."
+									}
+								}
+							}
+						},
+						"allowedPrefixes": {
+							"type": "array",
+							"items": { "type": "string" },
+							"description": "Master list of label prefixes valid for this team. Used for grouping in context responses."
+						},
+						"requiresProject": {
+							"type": "boolean",
+							"description": "If true, every new issue on this team must have a project set."
+						}
+					}
+				}
+			},
+			"additionalProperties": false
+		}
+	},
+	"required": ["policies"]
+}

package/skills/linear-workspace/SKILL.md

@@ -28,9 +28,11 @@ Router for Linear work. Dispatches to specialized agents or slash commands rathe
 | Refresh reference data from Linear | Slash command: `/linear-sync` |
 | Run the curator (collect signals from external sources) | Slash command: `/linear-curator-run` |
 
+For parallel work (e.g. 5 issues from 5 URLs), dispatch multiple agents in a single message — that's why they exist.
+
 ## First-run install
 
-1. Install the plugin: `/plugin marketplace add Elnora-AI/elnora-linear` then `/plugin install linear-workspace@elnora-linear`
+1. `/plugin marketplace add Elnora-AI/elnora-linear` then `/plugin install linear-workspace@elnora-linear`
 2. Make sure the `elnora-linear` CLI is on your PATH: `npm install -g @elnora-ai/linear`
 3. On your first Linear command, you'll be prompted for your Linear API key (get one at https://linear.app/settings/api). It's saved to `~/.config/elnora-linear/.env` (mode 0600).
 4. Populate the reference files: `/linear-sync` (runs `elnora-linear sync all` — fetches teams, projects, users, workflows in one batch).
@@ -40,13 +42,72 @@ Router for Linear work. Dispatches to specialized agents or slash commands rathe
 The plugin reads user-specific config from `~/.config/elnora-linear/` by default (override via `LINEAR_REFERENCES_DIR`):
 
 - `teams.json`, `projects.json`, `users.json`, `workflows.json` — populated by `/linear-sync`
-- `slack.json`, `repos.json`, `signal-sources.json` — populated manually in v0; interactive prompts coming in a future release
+- `slack.json`, `repos.json`, `signal-sources.json`, `label-policy.json` — populated manually (schemas in [`schemas/`](../../schemas/), examples in [`references/*.example.json`](../../references/))
 
 Run `elnora-linear sync verify` to see which are populated vs placeholder.
 
+## Dispatch prompt — what to include
+
+1. The user's raw request, verbatim
+2. Suspected team (let the agent confirm via `elnora-linear teams list`)
+3. Compliance flag (see below), if any
+4. Anything the user already specified (project, priority, assignee, due date)
+5. **If a URL appears anywhere in the request → dispatch to `linear-url-to-issues`**, not `linear-issue-creator`
+
+The agent handles searching for duplicates, label requirements, state matching, and asking the user about anything unclear.
+
+### Fast-path saves tokens
+
+The creator agent has a fast path that skips the dupe scan, project-status check, and reference reads when the dispatch already specifies team + project + priority + assignee + a clear novel title (and no compliance keywords). When you have all five, write them out explicitly in the prompt — the agent will detect the fast path and complete in roughly one CLI call instead of three.
+
+### Compliance flag
+
+If the request mentions any of: **incident, breach, vulnerability, CVE, pentest, penetration test, onboarding, offboarding, access provision/revoke, audit, SOC 2, change request, risk assessment, vendor review, backup test, RCA, lessons learned, DPA, DSR / data subject request** — say so in the dispatch prompt. The agent will load `references/template-index.md` and apply the matching template (`SEC-*`, `CHG-*`, `ACC-*`, `AUD-*`, `RSK-*`, `OPS-*`, `SLA-*`, `RCA-*`, `LRN-*`).
+
+### Model tiering — pass `model:` on the Agent dispatch
+
+Match the model to task complexity. The agent frontmatter sets the default; override per-dispatch when the task is clearly easier or harder. Haiku < Sonnet < Opus on cost AND token usage — Opus uses **more** tokens than Sonnet for the same task, not fewer. It's a quality escalation, never a token-saving move.
+
+| Task | Agent | Model | Why |
+|---|---|---|---|
+| Fast-path create (all fields explicit, no compliance) | `linear-issue-creator` | `haiku` | Mechanical CRUD, single CLI call |
+| Full-path create (ambiguous routing, dupe scan, compliance template) | `linear-issue-creator` | `sonnet` | Branching + judgment |
+| Single-field update (state, assignee, priority, label add) | `linear-issue-updater` | `haiku` | One CLI call, fixed flag |
+| Cross-team move, full description rewrite | `linear-issue-updater` | `sonnet` | Validates required labels across teams |
+| URL → issues extraction | `linear-url-to-issues` | `sonnet` | Real synthesis from unstructured content |
+| Issue completeness review | `linear-issue-reviewer` | `sonnet` | Reads description + comments + acceptance criteria |
+| Headless curator pass (scheduled) | `linear-state-curator` | `haiku` | Mechanical signal collection + tier dispatch |
+| Interactive curator dry-run / triage | `linear-state-curator` | `sonnet` | Reading curator-report.jsonl + judgment calls on MEDIUM queue |
+
+Don't reach for Opus by default. Sonnet handles every Linear task cleanly. Only escalate to Opus if Sonnet has *actually failed* on this task type (looped, produced wrong output, gave up). If the request mentions a compliance keyword, upgrade the creator to Sonnet automatically.
+
+### Dispatch prompt budget
+
+When the user request is fully specified, keep the dispatch prompt short — the agent already knows the playbook. Pass through:
+
+- The user's raw request, verbatim
+- Team / project / priority / assignee if explicit
+- Compliance flag if relevant
+
+Don't re-format the description, don't restate the playbook, don't tell the agent how to structure its output. A 100-token dispatch prompt is fine; a 500-token one wastes tokens with no quality gain.
+
+## Cold-start primitive
+
+For workflows that need team metadata up front (e.g. extracting N issues from a URL into one team), the parent should suggest the agent call `elnora-linear context --team "<Team>"` ONCE before iterating. The response contains projects with statuses, workflow states, the full label catalog grouped by prefix, the required-label policy, and active members — replacing four separate calls (`teams get` + `projects list --team` + `states list --team` + `labels list --team`) and eliminating every reference-file read.
+
+The CLI is the source of truth for label policy: `elnora-linear projects get` and `elnora-linear teams get` both return `requiredLabels` and `validStates` directly. `elnora-linear issues create` rejects invalid label combinations with a structured error (`missing`, `availableForPrefix`, `suggestedRetry`) so the agent can self-correct in one retry without reading any reference file.
+
 ## Safety guardrails
 
-- `bulk` and `cleanup` default to **dry-run**; they print what would change and require explicit `--yes` to commit
+- `bulk` and `cleanup` default to **dry-run** — they print what would change and require `--yes` to commit
 - `bulk` requires at least one of `--set-state` or `--add-comment` — refuses no-op invocations
 - `cleanup` defaults to `comment` action (least destructive); `close` / `cancel` are explicit opt-ins
-- `external_command` signal sources run user-configured commands with the user's privileges — only configure commands from sources the user trusts
+- `external_command` signal sources run user-configured commands with the user's privileges — only configure commands from sources you trust
+- Permanent deletes need an explicit `--yes` at the CLI layer — a prompt-injected agent cannot bypass it
+- Full guarantees and gated commands documented in [SAFETY.md](../../SAFETY.md)
+
+## Don't
+
+- Don't read reference `.md` files for label requirements — required-label policy is enforced server-side by the CLI
+- Don't run the create/update workflow inline. The agent owns it.
+- Don't pick a team without confirming via `elnora-linear teams list` or `references/teams.json`

package/templates/ACC-PRO-provision.md

@@ -0,0 +1,74 @@
+# ACC-PRO: Access Provisioning
+
+## Quick Reference
+- **SLA:** Same day
+- **Team:** *the team that owns this workflow in your workspace*
+- **Project:** Access Provisioning
+
+## Required Labels
+- `Type: feature`
+- `Account Setup` (7-day SLA)
+- `Layer: devops`
+
+## Issue Template
+```markdown
+## Access Provisioning Request
+
+**Request ID:** ACC-PRO-YYYY-XXX
+**Request Date:** [YYYY-MM-DD]
+**Required By Date:** [Start date - access cannot be granted earlier]
+
+## Employee/Contractor Information
+- **Name:** [Full name]
+- **Role/Title:** [Job title]
+- **Department:** [Department/Team]
+- **Manager:** [Manager name]
+- **Employment Type:** [Employee / Contractor]
+- **Start Date:** [YYYY-MM-DD]
+- **End Date:** [If contractor - YYYY-MM-DD]
+
+## HR Verification Checklist
+- [ ] Signed employment/contractor agreement received
+- [ ] IP agreement signed
+- [ ] Security policy acknowledgment signed
+- [ ] Background check complete (if applicable)
+
+## Access Requirements
+
+### System Access
+| System | Access Level | Justification | Data Owner Approval |
+|--------|--------------|---------------|---------------------|
+| Google Workspace | [Standard/Admin] | | [ ] |
+| GitHub | [Read/Write/Admin] | | [ ] |
+| AWS | [Specific roles] | | [ ] |
+| Linear | [Member/Admin] | | [ ] |
+| Slack | [Member] | | [ ] |
+| [Other] | | | [ ] |
+
+### Privileged Access (if any)
+[If elevated access needed, create linked ACC-PRV issue]
+
+## Segregation of Duties Check
+- [ ] Verified no conflicting access combinations
+- [ ] No violations of separation of duties policy
+
+## Approvals
+- [ ] HR verification complete: _________________ Date: _______
+- [ ] Manager approval: _________________ Date: _______
+- [ ] System owner approval(s) obtained
+
+## Provisioning Checklist
+- [ ] Google Workspace account created
+- [ ] Added to appropriate Google Groups
+- [ ] GitHub organization membership
+- [ ] AWS IAM user/role configured
+- [ ] MFA enrollment required/verified
+- [ ] Linear workspace access
+- [ ] Slack workspace access
+- [ ] Welcome email sent with access instructions
+- [ ] Security training assigned
+
+## Verification
+- [ ] User confirmed access working
+- [ ] Access logged in provisioning records
+```

package/templates/ACC-PRV-privileged.md

@@ -0,0 +1,66 @@
+# ACC-PRV: Privileged Access Request
+
+## Quick Reference
+- **SLA:** Same day
+- **Team:** *the team that owns this workflow in your workspace*
+- **Project:** Privileged Access
+
+## Required Labels
+- `Type: feature`
+- `Flag: security`
+- `Layer: devops`
+- `Access Request`
+
+## Issue Template
+```markdown
+## Privileged Access Request
+
+**Request ID:** ACC-PRV-YYYY-XXX
+**Request Date:** [YYYY-MM-DD]
+**Urgency:** [Urgent / Standard]
+
+## Requestor Information
+- **Name:** [Full name]
+- **Role:** [Job title]
+- **Department:** [Team]
+- **Manager:** [Manager name]
+
+## Access Details
+- **System:** [System requiring privileged access]
+- **Privilege Level:** [Specific privilege - admin, root, etc.]
+- **Current Access:** [What access user currently has]
+- **Requested Access:** [Specific new privileges needed]
+
+## Business Justification
+[Detailed explanation of why privileged access is needed]
+
+## Duration
+- **Access Type:** [Temporary / Permanent]
+- **Start Date:** [YYYY-MM-DD]
+- **End Date:** [YYYY-MM-DD or "Ongoing until role change"]
+- **Revocation Trigger:** [What event should trigger access removal]
+
+## Competency Verification
+- [ ] User has completed security training
+- [ ] User understands privileged access responsibilities
+- [ ] User acknowledges logging of all privileged actions
+
+## Security Requirements
+- [ ] MFA will be configured for privileged access
+- [ ] Access will be time-bound when possible
+- [ ] All privileged actions will be logged
+
+## Approvals
+- [ ] Manager approval: _________________ Date: _______
+- [ ] System owner approval: _________________ Date: _______
+- [ ] Security review (for admin/root): _________________ Date: _______
+
+## Provisioning
+- [ ] Privileged access configured
+- [ ] MFA verified active
+- [ ] User notified of access and responsibilities
+- [ ] Access logged in privileged account register
+
+## Review Schedule
+Next review date: [Date - privileged access reviewed quarterly]
+```

package/templates/ACC-QTR-review.md

@@ -0,0 +1,77 @@
+# ACC-QTR: Quarterly Access Review
+
+## Quick Reference
+- **SLA:** 30 days
+- **Team:** *the team that owns this workflow in your workspace*
+- **Project:** Quarterly Access Reviews
+
+## Required Labels
+- `Type: research`
+- `Flag: compliance`
+- `Layer: devops`
+
+## Issue Template
+```markdown
+## Quarterly Access Review
+
+**Review Period:** Q[1-4] [YYYY]
+**Review Start Date:** [YYYY-MM-DD]
+**Review Deadline:** [YYYY-MM-DD] (30 days from start)
+**Reviewer:** [Name]
+
+## Scope of Review
+Review all user access to ensure alignment with current job roles and least privilege principle.
+
+## Systems Under Review
+- [ ] Google Workspace (accounts, groups, drive permissions)
+- [ ] GitHub (organization members, repository access, team memberships)
+- [ ] AWS (IAM users, roles, policies)
+- [ ] Linear (workspace members, team access)
+- [ ] Slack (workspace members, channel access)
+- [ ] [Other systems]
+
+## Review Checklist
+
+### Per-System Review
+For each system, verify:
+- [ ] All active accounts belong to current employees/authorized contractors
+- [ ] Access levels match current job responsibilities
+- [ ] No terminated users still have access
+- [ ] Group/team memberships are appropriate
+- [ ] Privileged accounts are justified and documented
+
+### Access Matrix Verification
+| User | System | Current Access | Appropriate? | Action Needed |
+|------|--------|----------------|--------------|---------------|
+| | | | Yes/No | |
+
+## Findings
+
+### Unauthorized Access Discovered
+| User | System | Issue | Corrective Action | Ticket |
+|------|--------|-------|-------------------|--------|
+| | | | | |
+
+### Access Level Adjustments Needed
+| User | System | Current | Should Be | Reason |
+|------|--------|---------|-----------|--------|
+| | | | | |
+
+### Orphaned Accounts
+| Account | System | Last Activity | Action |
+|---------|--------|---------------|--------|
+| | | | |
+
+## Corrective Actions
+[Create linked ACC-REV tickets for any required access removals]
+
+## Sign-off
+- [ ] Review completed by: _________________ Date: _______
+- [ ] Findings reviewed by management: _________________ Date: _______
+- [ ] Corrective actions assigned
+
+## Attestation
+I certify that this access review has been completed thoroughly and all findings have been documented and addressed.
+
+Signature: _________________ Date: _______
+```

package/templates/ACC-REV-revoke.md

@@ -0,0 +1,67 @@
+# ACC-REV: Access Revocation
+
+## Quick Reference
+- **SLA:** 24 hours
+- **Team:** *the team that owns this workflow in your workspace*
+- **Project:** Access Revocation
+
+## Required Labels
+- `Type: bug` (treating as urgent remediation)
+- `Access Revocation` (3-day SLA, but target 24 hours)
+- `Layer: devops`
+
+## Issue Template
+```markdown
+## Access Revocation Request
+
+**Request ID:** ACC-REV-YYYY-XXX
+**Request Date:** [YYYY-MM-DD HH:MM]
+**DEADLINE:** [24 business hours from request]
+
+## URGENT: Complete within 24 business hours
+
+## Employee/Contractor Information
+- **Name:** [Full name]
+- **Role/Title:** [Job title]
+- **Department:** [Department/Team]
+- **Last Working Day:** [YYYY-MM-DD]
+- **Termination Type:** [Voluntary / Involuntary / Contract End]
+
+## Revocation Checklist
+
+### Priority 1: Immediate (within 4 hours)
+- [ ] Google Workspace account suspended
+- [ ] GitHub organization membership removed
+- [ ] AWS IAM access revoked
+- [ ] Slack workspace deactivated
+- [ ] Linear access removed
+- [ ] MFA tokens invalidated
+- [ ] Active sessions terminated
+
+### Priority 2: Same Day
+- [ ] Email forwarding configured (if applicable)
+- [ ] Shared passwords rotated (if any known)
+- [ ] Service account credentials reset (if applicable)
+- [ ] VPN/remote access disabled
+- [ ] API keys/tokens revoked
+
+### Priority 3: Within 24 Hours
+- [ ] Physical access/badge deactivated (if applicable)
+- [ ] Forwarding rules reviewed
+- [ ] Shared drive permissions audited
+- [ ] Distribution list memberships removed
+
+## Data Handover
+- [ ] Manager notified of data handover requirements
+- [ ] Critical data/files transferred to manager
+- [ ] Email archive created (if required for retention)
+
+## Verification
+- [ ] All system access confirmed revoked
+- [ ] Cannot authenticate to any system
+- [ ] Revocation logged in access records
+
+## Sign-off
+- [ ] IT Verification: _________________ Date: _______ Time: _______
+- [ ] HR Confirmation: _________________ Date: _______
+```

package/templates/AI-USE-capability.md

@@ -0,0 +1,111 @@
+# AI-USE: AI Capability Scope (Use-Case Approval)
+
+## Quick Reference
+- **SLA:** 5-10 days
+- **Team:** the team responsible for AI governance in your workspace (typically Operations, Compliance, or Security)
+- **Project:** AI Governance
+- **Scope:** Customer-facing AI capabilities only. Internal AI tooling (IDE assistants, agent-drafted ops emails, internal automations) is out of scope.
+
+## When to use this template
+
+Open an `AI-USE` ticket when any of the following is true for a customer-facing AI capability:
+
+- A new AI capability is being added (new use case).
+- An existing capability is being materially expanded — new data modality, new decision impact, autonomous action, new customer-data type, regulated-adjacent surface area.
+- Foundation-model **family** is being changed for the AI Service (e.g. moving primary inference from one vendor to another). Routine version swaps within the same family do NOT require this template — they ride the normal PR review.
+
+Required by your organization's Responsible AI Policy (see `<your-AI-policy>` reference in this repo's documentation).
+
+## Required Labels
+- `Type: compliance-task`
+- `Template: AI-Use-Case`
+- `Flag: compliance`
+- `Flag: AI-Incident` — only if this scope record is opened in response to an AI incident
+
+## Issue Template
+
+```markdown
+## AI Capability Scope
+
+**Capability ID:** AI-USE-YYYY-XXX
+**Capability Name:** [Short descriptive name]
+**Requested By:** [Name]
+**Date Requested:** [YYYY-MM-DD]
+**Status:** [Proposed / Under Review / Approved / Rejected / Withdrawn]
+
+## 1. Intended Purpose
+
+[What this capability does and the user problem it solves. Write for a customer auditor — concrete, no marketing language.]
+
+## 2. Users
+
+- **Customer-side users:** [Roles, seniority, domain expertise]
+- **Internal users (if any):** [e.g. customer success engineers running the capability on behalf of the customer]
+- **Out-of-scope users:** [Roles or contexts explicitly NOT supported]
+
+## 3. Data Sources
+
+| Data source | Type | Customer Data? | Personal Data? | Notes |
+|-------------|------|----------------|----------------|-------|
+| [Source] | [Prompt / RAG corpus / Live retrieval / Vendor model weights] | [Y/N] | [Y/N] | [Retention, isolation, consent basis] |
+
+## 4. Foundation Models
+
+| Vendor | Model family | Endpoint pattern | ZDR? | Listed in your Model Vendor Register? |
+|--------|--------------|------------------|------|--------------------------------------|
+| | | | | |
+
+## 5. Decision Impact
+
+- **What does the Output inform?** [Customer-facing decision, workflow step, recommendation...]
+- **Who is the human-in-the-loop?** [Role + decision they make before Output is acted on]
+- **What happens if the Output is wrong?** [Realistic worst case in the customer's domain terms]
+- **Is this High-Risk Use under EU AI Act Annex III or your Responsible AI Policy definition?** [Y/N + reasoning]
+
+## 6. Refusal Patterns
+
+[What the system declines. Reference your Acceptable Use Policy categories. Note any new refusal patterns introduced for this capability.]
+
+## 7. Known Limitations
+
+[Domain coverage gaps, hallucination risk areas, model-specific failure modes you've observed, latency characteristics, etc.]
+
+## 8. Reviews
+
+- [ ] AI Governance Owner review
+- [ ] CTO / Engineering lead review
+- [ ] Acceptable Use Policy: capability stays within scope
+- [ ] Data Management Policy: data sources, retention, and tenant isolation align
+- [ ] Third-Party Management Policy: any new vendor recorded in the Model Vendor Register
+- [ ] High-Risk Use risk assessment completed (only if § 5 flagged Y)
+
+## 9. Customer Disclosure
+
+- [ ] Updates required to current Model Card? [Y/N — describe]
+- [ ] Release notes drafted for affected customers? [Y/N — link]
+- [ ] Per-customer playbook updates required? [Y/N — list customers]
+- [ ] AI-generated labelling unchanged? [Y/N — describe any change]
+
+## 10. Approval
+
+| Role | Name | Decision | Date |
+|------|------|----------|------|
+| AI Governance Owner | | | |
+| CTO / Engineering lead | | | |
+
+## 11. Post-Approval Tracking
+
+Link the implementation issue(s) and the corresponding GitHub PR(s):
+
+- Implementation: [ISSUE-XXX]
+- PR(s): [#XXX]
+- Evaluation Suite results summary: [link or paste]
+- Model Card updated: [link to PR or commit]
+```
+
+## Resources
+
+- `<your-AI-policy>`: your Responsible AI Policy
+- Model Vendor Register: your register of approved AI model vendors
+- Acceptable Use Policy: your customer-facing AUP
+- Risk Assessment template (for High-Risk Use): `RSK-ASS-assessment.md`