# #dpvp-phase-2-opportunity

_Last sync: 2026-09-09 03:09 UTC_

## Purpose
Structure the DPVP platform Phase 2 commercial opportunity and contract.

## Updated opportunity framing
The expanded scope is a **DPVP productisation and hybrid-service programme**, not only a portal PoC.

### Workstreams
1. **Portal / Experience Plane** — guided organisation/project lifecycle, service catalogue, approvals, aggregated Jira demand, inventory, configuration governance, operator workbench and audit.
2. **Control and Execution Plane** — service orders, durable workflows, policy, adapters, state, eventing, inventory/reconciliation, and gradual migration of application logic out of GitLab pipelines.
3. **Hybrid onboarding** — reusable VSSA on-prem site pattern covering connectivity, identity, inventory, security, telemetry, support boundaries, and degraded operation.
4. **Complex services** — governed compositions for on-prem backup, Kubernetes web applications, cloud DR, and hybrid observability.
5. **Cross-cutting foundations** — canonical schemas/contracts, IAM/workload identity, policy as code, configuration/inventory graph, FinOps, SRE, audit, testing, lifecycle/versioning, support and DPVP's own backup/DR.

## Key design decisions
- Model multiple Jira requests as demand records feeding one governed **DPVP service order**; do not merely merge tickets.
- Build a cloud inventory/read model with freshness timestamps and reconciliation; do not query every cloud API synchronously from portal pages.
- Treat global configuration as hierarchical, versioned, impact-analysed, approved, wave-based and rollback-capable—not a global YAML editor.
- Do not choose “webserver vs cloud functions” globally: short stateless handlers may be functions; long-running provisioning needs durable orchestration and workers.
- Migrate GitLab pipeline logic through a strangler pattern, one capability at a time.
- Complex services are blueprints/compositions over atomic capabilities, each with lifecycle, security, identity, network, cost, operations and acceptance contracts.

## Recommended commercial packaging
- WP0 programme mobilisation and target architecture;
- WP1 Portal/control-plane core;
- WP2 one backend migration slice;
- optional WP3 one hybrid site/lab pilot;
- optional WP4 one complex-service pilot;
- separate WP5 productionisation and managed operations.

## Current recommendation
Name the opportunity **“DPVP Platform Productisation and Hybrid Service Enablement — Phase 2.”** Contract Portal + Control Plane + one backend migration slice as the core. Keep hybrid onboarding and one complex-service pilot as separately priced options pending architecture validation.

## Local workspace
- Canonical folder: `/opt/data/workspaces/channels/dpvp-phase-2-opportunity/`
- All channel-owned artifacts must be kept beneath this folder, normally in `artifacts/`; do not place them directly in `/opt/data/`.
- Workspace guide and migration record: `README.md` and `organization-manifest.json`.

## Artifacts
- Executive summary limited strictly to RootAtSkic's stated topics: `/opt/data/workspaces/channels/dpvp-phase-2-opportunity/artifacts/dpvp-phase-2-executive-summary.md`
- Initial narrow draft: `/opt/data/workspaces/channels/dpvp-phase-2-opportunity/artifacts/dpvp-phase-2-opportunity-contract-draft.md`
- Expanded programme/contract draft: `/opt/data/workspaces/channels/dpvp-phase-2-opportunity/artifacts/dpvp-phase-2-program-opportunity-contract-v2.md`

## Mandatory technical evidence
AWS resource evaluations must reference:
- `dpvp-storm/docs/machine-identity/configuration-alignment.md`
- `dpvp-storm/docs/references/project-configuration.example.yaml`

Keep OBSERVED / PROPOSED / UNKNOWN / RUNTIME evidence distinct.

## Source anchor
- Latest processed human message: `1546854087910498384` (2026-09-08 12:05 UTC; required this channel to have a dedicated local folder and keep its artifacts there; the completed workspace is recorded above).