Landscape Inventory and Integration Map

When to use: Early discovery to map systems, data types, protocols, and key integration points across departments.

Role: Enterprise Integration Architect
Goal: Produce a current-state landscape of {{ business_unit }} integration endpoints and connector needs.

Inputs:
- Business unit: {{ business_unit }}
- Systems in scope: {{ system_list }}
- Known workflows/use cases: {{ use_case_list }}
- Integration types: (batch|real-time|event-driven), protocols supported: {{ protocol_list }}
- Constraints: {{ constraints }}

Tasks:
1) Create a system catalog with: name, owner, data domains, APIs, events, auth model, SLAs.
2) Identify integration candidates and categorize (source/sink/bidirectional).
3) Note compliance classifications (PII/PCI/PHI/None) and data residency.
4) Summarize technical risks and readiness.
5) Provide a prioritized connector backlog with rationale.

Output: JSON with keys [catalog, candidates, risks, backlog]. Include no secrets or PII.
Acceptance: Clear owners; unambiguous protocols; priority tagged P0/P1/P2; rationale linked to value, risk, effort.
Guardrails: Never invent endpoints. Flag unknowns in 'risks.unknowns'.

Why it works: Establishes a single source of truth for enterprise AI connectors and guides resource allocation. See Application Portfolio Management.

Data Flow and Trust Boundaries Diagram (Textual)

When to use: Security review and design scoping when diagrams aren’t allowed as images.

Role: Security-Aware Integration Designer
Goal: Describe trust boundaries and data flows for the {{ connector_name }} connector in text for diagram-as-code.

Inputs: connector_name: {{ connector_name }}, source: {{ source_system }}, target: {{ target_system }}, auth: {{ auth_model }}, data_classes: {{ data_classes }}, region: {{ region }}

Tasks:
- Enumerate components and trust zones (Public, DMZ, Corp, Restricted).
- Describe data flows with direction, protocol, encryption, and authentication.
- Identify boundary crossings and required controls (WAF, mTLS, DLP).
- Provide a Mermaid and PlantUML text block for diagram-as-code.

Output:
- List: components, zones, flows, controls.
- Code: mermaid sequence diagram + PlantUML component diagram.
Acceptance: No plaintext secrets, explicit cipher suites or TLS minimums, region-specific notes.

Tip: Use with Threat Modeling and store as code to version changes.

Event Catalog and Change Data Capture (CDC) Readiness

When to use: Evaluate event-driven options versus polling for lower latency and cost.

Role: Event Integration Analyst
Goal: Build an event catalog and CDC readiness assessment for {{ source_system }} → {{ target_system }}.

Inputs: source_system: {{ source_system }}, target_system: {{ target_system }}, topics/buses: {{ messaging_platform }}, SLAs: {{ latency_SLA }}, throughput: {{ event_volume }}

Deliverables:
1) Event types: name, schema, key fields, order guarantees, dedupe keys.
2) CDC feasibility: log-based? API-based? vendor support? latency trade-offs.
3) Consumer group strategy and partitioning.
4) Error handling: poison queues, DLQ policies.
5) Cost model: egress fees, storage, compute, reprocessing.

Output: Markdown report with tables.
Acceptance: Includes schema evolution strategy and backfill plan. Aligns with {{ governance_policy }}.

Outcome: A clear recommendation for events vs. batch connectors. Integrate with Data Lineage.

Integration Readiness Checklist (System-Level)

When to use: Gate keeping before new connector development starts.

Role: Integration Readiness Reviewer
Goal: Score {{ system_name }} for connector readiness.

Inputs: system_name: {{ system_name }}, api_docs_url: {{ api_docs_url }}, sandbox_available: {{ sandbox_available }}, quota: {{ quota_details }}, auth: {{ auth_model }}

Checklist Sections (score 0-5 each):
- API Quality (OpenAPI, consistency, pagination, filtering)
- Authentication (OAuth2/OIDC support, scoping, token rotation)
- Idempotency/Concurrency (PUT/PATCH semantics, idempotency keys)
- Events/Webhooks (retries, signatures, dedupe)
- Observability (request IDs, logs, metrics)
- Sandbox/Test Data (availability, realism, reset)
- Compliance (PII minimization, retention)
- Support/SLA (contact paths, uptime, change notices)
Output: JSON { "scores": {...}, "summary": "...", "risks": [...], "go/no-go": "GO|NO-GO|GO-WITH-CAVEATS" }
Acceptance: Evidence links only. No secrets. Note missing docs explicitly.

Use with: Vendor Risk Management and API Governance.

Prioritized Integration Backlog with ROI Model

When to use: Create an executive-ready plan for connector sequencing.

Role: Product/Portfolio Manager
Goal: Prioritize the connector backlog with ROI.

Inputs: candidates: {{ candidate_list }}, benefits: {{ benefit_drivers }}, costs: {{ cost_factors }}, constraints: {{ constraints }}, timeline: {{ timeline }}

Tasks:
- Score value (automation hours saved, error reduction, revenue impact), cost (build, run, risk).
- Map dependencies and readiness from discovery outputs.
- Produce a 2-quarter roadmap with milestones and risk mitigations.

Output: Table (CSV or Markdown) + narrative summary + Gantt-like milestone list.
Acceptance: Transparent assumptions; sensitivity analysis; clear P0/P1 alignment.

Related: Roadmapping Standards and Executive Summaries.

Connector Scoping Document (CSD)

When to use: Formalize scope, SLAs, dependencies, and acceptance criteria.

Role: Connector Lead
Goal: Author the Connector Scoping Document for {{ connector_name }}.

Inputs: connector_name: {{ connector_name }}, source: {{ source_system }}, target: {{ target_system }}, SLA: {{ SLA_targets }}, compliance: {{ compliance_requirements }}, stakeholders: {{ stakeholder_list }}

Sections:
- Problem Statement and Outcomes
- In/Out of Scope
- Functional Requirements (endpoints, events, transforms)
- NFRs (SLA, RTO/RPO, throughput, cost ceilings)
- Security/Privacy (data classes, masking, retention)
- Operational Model (on-call, SLOs, alerts)
- Risks/Assumptions/Dependencies
- Acceptance Criteria and Test Strategy

Output: Markdown CSD with version, approvers, and Change Control ID.
Acceptance: Unambiguous scope; measurable criteria; alignment with {{ integration_policy }}.

Note: This anchors governance for all later phases and aligns with your ChatGPT Work prompts catalog.

API Capability Matrix and Gap Analysis

When to use: Determine feasibility and identify compensating controls.

Role: API Analyst
Goal: Create capability matrix for {{ source_system }} x {{ target_system }}.

Inputs: source_openapi: {{ source_openapi_url }}, target_openapi: {{ target_openapi_url }}, business_ops: {{ ops_requirements }}

Tasks:
- Enumerate required operations (CRUDL + query/filter/sort) by business need.
- Map to API operations; score coverage (Full/Partial/None).
- Identify gaps and propose patterns (staging tables, batch windows, compensating transactions).

Output: Matrix + narrative + risk register.
Acceptance: Links to docs; explicit fallbacks; clear error paths with retry/compensation.

Connect to: Compensating Transactions and Data Consistency Models.

Service Level Objectives and Error Budgets

When to use: Define SLOs with business alignment and observability hooks.

Role: SRE for Integrations
Goal: Set SLOs and error budgets for {{ connector_name }}.

Inputs: SLA_targets: {{ SLA_targets }}, business_hours: {{ business_hours }}, volume: {{ event_volume }}, criticality: {{ tier }}

Deliverables:
- User journeys (e.g., "order created → confirmed in ERP")
- SLOs: latency, freshness, success rate, coverage.
- Error budgets and policy (what actions when consumed).
- Alert thresholds and runbook pointers.

Output: YAML SLO spec compatible with {{ slo_tool }} + human-readable summary.
Acceptance: Time windows, paths, and aggregation are unambiguous; ties to alerting.

Link: SLO Handbook and Runbook Library.

Data Privacy Impact Assessment (DPIA) Draft

When to use: Pre-privacy and legal review to accelerate approvals.

Role: Privacy Analyst
Goal: Draft DPIA for {{ connector_name }}.

Inputs: data_categories: {{ data_categories }}, retention: {{ retention_policy }}, processors: {{ sub_processors }}, regions: {{ regions }}, purpose: {{ purpose }}

Sections:
- Description and purpose
- Lawful basis and legitimate interests
- Data minimization and masking strategy
- Data subject rights support (access, deletion)
- Cross-border transfer mechanisms
- Risks and mitigations

Output: DPIA draft in your org's template; risk heatmap.
Acceptance: No speculative claims; cite policies and controls; versioned.

Pair with: Records of Processing Activities and Data Retention.

Stakeholder RACI and Communication Plan

When to use: Prevent coordination failures for cross-team builds.

Role: Delivery Manager
Goal: RACI + comms plan for {{ connector_name }}.

Inputs: stakeholders: {{ stakeholders }}, cadences: {{ cadences }}, channels: {{ channels }}, approvals: {{ approvals }}

Deliverables:
- RACI table (Responsible, Accountable, Consulted, Informed).
- Meeting cadences and escalation paths.
- Change notification process.
Output: Markdown + CSV RACI.
Acceptance: One Accountable per area; escalation SLA defined.

Use with: Change Enablement and Incident Management.

Field Mapping and Transformation Spec

When to use: Author the canonical mapping between systems with deterministic transforms.

Role: Data Integration Designer
Goal: Produce mapping spec from {{ source_system }} to {{ target_system }} for {{ object_type }}.

Inputs: source_schema: {{ source_schema_ref }}, target_schema: {{ target_schema_ref }}, rules: {{ business_rules }}, nullability: {{ nullability_prefs }}

Tasks:
- For each target field: source path(s), transformation function, default/null rules, validation.
- Include data type coercions and enumerations.
- Provide examples and edge cases.
Output: JSON mapping spec + human-readable table.
Acceptance: Every target field is mapped or explicitly 'unmapped' with reason.

Connect: Canonical Data Models and Transformation Library.

Idempotency, Ordering, and Deduplication Strategy

When to use: Prevent data corruption in retries and concurrent updates.

Role: Reliability Engineer
Goal: Define idempotency/dedupe for {{ connector_name }}.

Inputs: operations: {{ operation_list }}, idempotency_key: {{ key_strategy }}, ordering: {{ ordering_guarantee }}, transport: {{ transport }}

Deliverables:
- Idempotency key design per operation with examples.
- Deduping rules and window.
- Ordering and conflict resolution policy (last-write-wins, vector clock, versioning).
- Retry/backoff and circuit breaker thresholds.

Output: Policy document + pseudocode.
Acceptance: Edge cases covered (timeouts, partial failures, consumer restarts).

Reference: Exactly-Once Semantics and Retry Policies.

Pagination, Rate Limiting, and Backpressure Plan

When to use: Control throughput and avoid throttling.

Role: Performance Engineer
Goal: Plan pagination/rate control for {{ source_system }} API → {{ target_system }}.

Inputs: pagination: {{ pagination_type }}, quota: {{ api_quota }}, concurrency: {{ concurrency_limits }}, SLO: {{ freshness_target }}

Deliverables:
- Pagination strategy (offset/cursor/keyset) with example requests/responses.
- Dynamic rate control (token bucket/leaky bucket) with tuning guidance.
- Backpressure signaling between components.

Output: Config guide + algorithm outline.
Acceptance: Includes error scenarios (429/503) and recovery steps.

Link: Throughput Tuning and API Quota Management.

Security Design: AuthN/Z, Secrets, and Data Protection

When to use: Baseline security for a new connector.

Role: Security Architect
Goal: Security design for {{ connector_name }}.

Inputs: auth: {{ auth_model }}, scopes: {{ required_scopes }}, secrets_store: {{ secrets_store }}, data_classes: {{ data_classes }}, regions: {{ regions }}

Tasks:
- AuthN/Z flow diagrams; minimal scopes; token refresh/rotation.
- Secrets lifecycle (create, rotate, revoke) and ownership.
- Data protection (TLS v{{ tls_min }}, encryption at rest, masking, tokenization).
- Audit logging (fields, retention, secure transport).
Output: Security design doc + checklist.
Acceptance: No plaintext secrets; portable across {{ environments }}; control owners named.

Relate to: Zero Trust and Secrets Management.

Error Taxonomy and Handling Matrix

When to use: Standardize error semantics and operator actions.

Role: Ops Readiness Lead
Goal: Create error taxonomy for {{ connector_name }}.

Inputs: upstream_error_models: {{ upstream_models }}, downstream_error_models: {{ downstream_models }}, ops_policies: {{ ops_policies }}

Deliverables:
- Error classes (Transient, Permanent, Validation, Security, Quota, Dependency).
- Handling rules per class (retry, escalate, quarantine, drop).
- Operator playbook for each class with examples.

Output: Matrix + runbook references.
Acceptance: Mapped to alert severities and SLO impacts.

Use with: Incident Playbooks and Alert Taxonomy.

Connector Skeleton Generator (Language-Agnostic)

When to use: Bootstrap a consistent, review-ready repository.

Role: Integration Engineer
Goal: Generate a connector skeleton repo for {{ connector_name }}.

Inputs: language: {{ language }}, package_manager: {{ pkg_mgr }}, ci_cd: {{ ci_cd }}, license: {{ license }}, code_style: {{ code_style }}, observability: {{ obs_stack }}, secrets: {{ secrets_store }}

Tasks:
- Create folder structure (src, tests, config, docs, ops).
- Initialize linters, formatters, pre-commit hooks.
- Add env config templates (no secrets) and feature flags.
- Stub interface: fetch, transform, write; error handling; retries.
- Observability scaffolding (logs with context, metrics counters/histograms, tracing).
- CI: build, lint, test, SAST; PR template; CODEOWNERS.

Output: File tree + key file contents.
Acceptance: No live tokens; deterministic local run with mocks; LICENSE and README included.

Cross-reference: Engineering Standards and Observability Bootstrap.

OpenAPI/GraphQL Client Stubs with Resilience

When to use: Generate API clients that include retries, timeouts, and tracing by default.

Role: API Client Engineer
Goal: Produce resilient clients for {{ api_type }} API at {{ api_spec_url }}.

Inputs: api_type: (OpenAPI|GraphQL), api_spec_url: {{ api_spec_url }}, retry_policy: {{ retry_policy }}, timeouts: {{ timeouts }}, tracing: {{ tracing_lib }}, http_limits: {{ http_limits }}

Output:
- Client stub code with: retries/backoff/jitter, timeouts, circuit breaker, tracing propagation, pagination helpers.
- Unit tests with simulated failures.
Acceptance: Coverage ≥ {{ coverage_percent }}; no hard-coded secrets; type-safe responses.

Link: Resilience Patterns and API Client Guidelines.

Transformation Unit Tests from Mapping Spec

When to use: Derive tests automatically from the mapping definition.

Role: Test Engineer
Goal: Generate unit tests for {{ object_type }} transforms using mapping spec.

Inputs: mapping_spec_json: {{ mapping_spec_json }}, test_framework: {{ test_framework }}, edge_cases: {{ edge_cases }}

Output:
- Test cases covering nominal, null/defaults, coercions, enum mismatches, long strings, locales/timezones.
- Golden input/output fixtures.
Acceptance: Tests fail fast on unmapped fields; readable failure messages.

See also: Contract Testing and Data Quality.

Webhook Consumer with Signature Validation

When to use: Build secure webhook ingress for event-driven connectors.

Role: Platform Engineer
Goal: Implement a secure webhook consumer for {{ provider }} events.

Inputs: provider: {{ provider }}, signature_scheme: {{ signature_scheme }}, replay_window: {{ replay_window }}, queue: {{ queue_target }}, infra: {{ infra_stack }}

Output:
- Handler code with signature validation, timestamp check, replay prevention, idempotency.
- IaC resource definitions for scaling and DLQs.
- Sample curl with valid signature (non-secret).
Acceptance: Default deny; structured logs; unit tests for invalid signatures and clock skew.

Relate to: Webhook Security and Event-Driven Architecture.

Connector Configuration Schema and Policy

When to use: Standardize config across environments and tenants.

Role: Config Standards Owner
Goal: Define JSON Schema and policy for {{ connector_name }} configuration.

Inputs: config_items: {{ config_items }}, secrets_refs: {{ secrets_refs }}, envs: {{ envs }}, policy_engine: {{ policy_engine }}

Output:
- JSON Schema with types, defaults, enums, min/max, examples.
- Policy-as-code rules (e.g., OPA) to prevent risky configs (e.g., PII logging).
- Migration plan for schema evolution.
Acceptance: Backward-compatible; validation CLI snippet included.

Connect: Policy as Code and Configuration Management.

End-to-End Test Plan with Mocks and Sandboxes

When to use: Validate whole flows without risking production data.

Role: QA Lead
Goal: E2E test plan for {{ connector_name }} using {{ sandbox_envs }} and {{ mock_tools }}.

Inputs: flows: {{ critical_flows }}, data_classes: {{ data_classes }}, SLAs: {{ SLA_targets }}

Output:
- Test matrix covering positive, negative, chaos, and performance cases.
- Mock/stub strategies; synthetic data generation plan.
- Entry/exit criteria and reporting cadence.
Acceptance: Data never exfiltrated; repeatable nightly run; linked defects workflow.

Use with: Test Data Management and Chaos Testing.

Contract Tests from OpenAPI/GraphQL Introspection

When to use: Detect breaking API changes before production incidents.

Role: Contract Test Engineer
Goal: Auto-generate contract tests for {{ api_name }}.

Inputs: api_spec: {{ api_spec_url_or_introspection }}, allowed_changes: {{ allowed_breaking_rules }}

Output:
- Contract test suite; snapshot of schemas.
- CI pipeline job configuration.
Acceptance: Fails on breaking changes (field removals, type narrowing); produces diff artifact.

Relate to: API Change Management and CI Quality Gates.

Performance and Load Test Scenarios

When to use: Prove SLAs with realistic traffic models.

Role: Performance Engineer
Goal: Define performance tests for {{ connector_name }}.

Inputs: target_QPS: {{ target_qps }}, payload_size: {{ payload_size }}, concurrency: {{ concurrency }}, spike_profile: {{ spike_profile }}, duration: {{ duration }}

Output:
- Scenarios: steady, burst, spike, soak.
- Tooling scripts outline (k6/JMeter/Locust).
- Success criteria: P50/P95/P99 latencies, error rate, saturation metrics.
Acceptance: Warm-up period, GC considerations, resource limits defined.

Pair with: Capacity Planning and Cost Modeling.

Data Quality Checks and Reconciliation Plan

When to use: Ensure correctness over time and after incidents.

Role: Data Quality Lead
Goal: DQ checks and reconciliation for {{ source_system }} → {{ target_system }}.

Inputs: key_entities: {{ key_entities }}, tolerances: {{ tolerances }}, schedule: {{ schedule }}

Output:
- Validations: completeness, uniqueness, referential integrity, timeliness.
- Reconciliation job design; sample SQL/queries.
- Alert thresholds and remediation steps.
Acceptance: Includes drift detection and backfill procedures.

Connect: Data Observability and Backfill Procedures.

Security Test Plan: Auth, Secrets, and Data Paths

When to use: Validate security assumptions before go-live.

Role: Security Test Engineer
Goal: Security test plan for {{ connector_name }}.

Inputs: threat_model: {{ threat_model_ref }}, scopes: {{ scopes }}, secrets_flow: {{ secrets_flow }}, data_paths: {{ data_paths }}

Output:
- Test cases: token misuse, scope overreach, replay attacks, injection vectors, PII leakage.
- Tooling: static scan, dependency audit, dynamic tests.
- Pass/fail criteria and remediation backlog.
Acceptance: Evidence redacted; traceability to controls.

Link: Security Testing and SSDLC.

Observability Spec: Logs, Metrics, and Traces

When to use: Define what to emit and how to interpret it.

Role: Observability Lead
Goal: Observability spec for {{ connector_name }}.

Inputs: tracing: {{ tracing_stack }}, logging: {{ logging_format }}, metrics: {{ metrics_backend }}, pii_policy: {{ pii_policy }}

Output:
- Log schema (fields, levels, redaction rules).
- Metrics (names, types, labels, units, SLO ties).
- Trace spans and attributes; sampling policy.
- Dashboards and example queries.
Acceptance: No PII in logs/metrics; dashboard links; alert runbooks referenced.

Use with: Log Redaction and Golden Signals.

Runbook: Alert to Actionable Resolution

When to use: Ensure on-call has step-by-step guidance.

Role: On-call Lead
Goal: Create runbook for {{ alert_name }} in {{ connector_name }}.

Inputs: alert_name: {{ alert_name }}, severity: {{ severity }}, detection_logic: {{ detection_logic }}, service_owner: {{ owner }}, escalation: {{ escalation_path }}

Output:
- Symptoms, diagnosis steps, likely causes.
- Commands/links to verify hypotheses.
- Safe remediation steps and rollbacks.
- Post-incident data checks and close-out tasks.
Acceptance: Clear time-to-action; no guesswork; copy-pasteable commands (no secrets).

Related: Incident Lifecycle and Postmortems.

Deployment Strategy and Change Management Plan

When to use: Plan safe rollouts with approvals and rollback.

Role: Release Manager
Goal: Deployment plan for {{ connector_name }}.

Inputs: environments: {{ envs }}, approvals: {{ approvals }}, change_windows: {{ windows }}, rollout: {{ rollout_strategy }}

Output:
- Pipeline stages with quality gates.
- Canary/feature flag plan; rollback strategy.
- Change record entries and communication plan.
Acceptance: Meets SOX/SOC2 controls; documented backout procedures.

Cross-link: Release Management and Change Advisory Board.

Capacity, Cost, and Scaling Playbook

When to use: Keep performance and costs aligned to demand.

Role: FinOps + SRE
Goal: Define capacity and cost plan for {{ connector_name }}.

Inputs: forecast: {{ volume_forecast }}, scaling: {{ scaling_model }}, budgets: {{ budgets }}, unit_costs: {{ unit_costs }}

Output:
- Scaling thresholds and policies.
- Cost dashboards and anomaly detection.
- Optimization tactics (batch size, compression, sampling).
Acceptance: Alert on unit-cost regressions; owner assigned for budget reviews.

Use with: FinOps and Autoscaling.

Business Continuity and Disaster Recovery (BC/DR)

When to use: Ensure resilience for regulated and mission-critical flows.

Role: Resilience Architect
Goal: BC/DR plan for {{ connector_name }}.

Inputs: RTO: {{ rto }}, RPO: {{ rpo }}, regions: {{ regions }}, dependencies: {{ dependencies }}

Output:
- Failure modes and blast radius analysis.
- Backup/restore and failover steps.
- DR runbook and test schedule.
Acceptance: Tested quarterly; evidence stored at DR Evidence Repo.

Link: Resilience Testing and Multi-Region Strategy.

Least-Privilege Scopes and Access Review Pack

When to use: Gate API scopes and periodically recertify access.

Role: IAM Engineer
Goal: Define least-privilege scopes for {{ connector_name }} and prepare review pack.

Inputs: required_operations: {{ operations }}, provider_scopes: {{ provider_scopes }}, review_cycle: {{ cycle }}

Output:
- Scope-to-operation mapping; deny-by-default list.
- Access review packet: owners, justifications, expiry, recertification plan.
Acceptance: No wildcard scopes unless justified; expiry dates present.

Related: Access Reviews and Privileged Access.

Audit Logging and Evidence Collection Plan

When to use: Align with internal audit and regulatory expectations.

Role: Compliance Engineer
Goal: Define audit logging and evidence plan for {{ connector_name }}.

Inputs: controls: {{ control_frameworks }}, evidence_store: {{ evidence_store }}, retention: {{ retention }}

Output:
- What to log (who, what, when, where), redaction rules.
- Evidence artifacts list and storage location.
- Quarterly sampling and testing procedures.
Acceptance: Chain of custody documented; no PII in evidence.

Link: Audit Trails and Evidence Management.

Data Residency and Cross-Border Transfer Controls

When to use: Ensure compliant data movement across regions.

Role: Data Governance Lead
Goal: Residency controls for {{ data_classes }} in {{ regions }}.

Inputs: data_classes: {{ data_classes }}, regions: {{ regions }}, transfer_mechanism: {{ mechanism }}, masking_policy: {{ masking }}

Output:
- Residency map with allowed paths.
- Controls (masking, tokenization, anonymization) per path.
- Technical enforcement points (gateways, DLP).
Acceptance: Exceptions list with approvals and expiry.

Connect: Data Residency Policy and Cross-Border Guides.

Third-Party/Vendor Risk Assessment (TPRA) for Connectors

When to use: Onboard a new SaaS or iPaaS provider powering connectors.

Role: Vendor Risk Analyst
Goal: TPRA for {{ vendor_name }} related to {{ connector_name }}.

Inputs: vendor_name: {{ vendor_name }}, data_types: {{ data_types }}, locations: {{ locations }}, certifications: {{ certs }}

Output:
- Security posture summary; controls coverage; pen test recency.
- Breach/incident history; SLAs; data handling.
- Risk rating and mitigation plan.
Acceptance: References to third-party artifacts; internal sign-off path documented.

Use with: Supplier Security and Legal Review.

Go-Live Readiness Review (GLRR) Checklist

When to use: Final gate pre-production launch.

Role: Go-Live Chair
Goal: GLRR for {{ connector_name }}.

Inputs: scope_doc: {{ CSD_ref }}, test_reports: {{ test_refs }}, security: {{ security_signoffs }}, operations: {{ runbooks_refs }}, change_record: {{ change_id }}

Checklist:
- Requirements met; tests passed with evidence.
- SLOs/alerts configured; runbooks validated.
- Security controls certified; access reviews done.
- DR/backup proven; dashboards live.
- Communications and training completed.

Output: Pass/Conditional/Fail + follow-ups, owners, dates.
Acceptance: Evidence links; no placeholders remaining.

Relate to: Production Readiness and CAB Approval.