Skip to main content

PDEP — Product Development Experience Plane

PDEP (Product Development Experience Plane) is the product-native self-service cockpit in UPOS.

PDEP is where a product creator (including a Symbiant) expresses Product Intent, steers stewardship decisions, and issues lifecycle commands (create/compile, publish, evolve, deprecate, retire).
PDEP is not where creators author technical artifacts such as PIR, PROD, PDS, DPP, or policy bundles.

PDEP is intent + stewardship + lifecycle control.
PFI is compilation + artifact generation + realization.

Diagram

Executive framing​

Traditional enterprises require product teams to hand off intent to engineering organizations, who translate that intent into implementation artifacts and delivery work.

UPOS shifts this model by making productization self-service for product creators:

  • the creator steers through PDEP (product language),
  • the factory compiles through PFI (artifact chain + realization),
  • and PVEP enables discovery, acquisition, entitlements, and consumption experiences across the ProductVerse.

PDEP is the democratization layer for creators.

What PDEP is responsible for​

PDEP owns the creator-facing responsibilities:

1) Intent authoring (product-native)​

PDEP captures Product Intent in business/product terms:

  • purpose and audience
  • value outcomes and success criteria
  • constraints and obligations (e.g., residency, retention, purpose limits)
  • trust posture (risk appetite, assurance expectations)
  • dependencies (upstream products/assets where applicable)

2) Stewardship (accountability)​

PDEP is where the creator acts as Creator–Steward:

  • confirming ownership and mandate
  • reviewing product meaning and consumer contract (at the right abstraction level)
  • choosing lifecycle actions and trade-offs (time, quality, cost, risk)
  • accepting responsibility for publish decisions and deprecation/retirement decisions

3) Lifecycle commands (control plane actions)​

PDEP issues explicit commands such as:

  • Create / Compile (initiate first version build)
  • Publish (make a version available through PVEP)
  • Promote (dev → test → prod, where applicable)
  • Evolve (new version derived from current version)
  • Pause / Rollback (where supported by domain/platform)
  • Deprecate / Retire (portfolio lifecycle management)

4) Observation and evolution steering​

PDEP surfaces signals and supports steering decisions:

  • adoption and usage patterns
  • quality and health indicators
  • trust/risk indicators (domain-dependent)
  • FinOps signals (cost, efficiency, ROI)
  • incidents, drift, and corrective actions

Signals inform decisions; they do not automatically mutate the product.

What PDEP is not responsible for​

To preserve true democratization (and avoid pushing engineering complexity onto creators), PDEP does not require the creator to author or manipulate:

  • PIR (Product Intent Record) (creation intent record generated in PFI)
  • Policy Bundles
  • PROD / PDS / DPP artifacts
  • blueprint selection details
  • runtime topology, pipelines, infra manifests
  • monitoring configs, alert routes, runbooks (except at policy/intent level)
  • PVEP listing/entitlement wiring mechanics

Those are generated and wired by PFI.

The PDEP ↔ PFI contract (the most important boundary)​

PDEP provides (to PFI)​

  • Intent (product-native)
  • constraints and trust posture
  • lifecycle command (create/publish/evolve/etc.)
  • context (target environment, audience scope, required timelines)

PFI returns (to PDEP)​

  • generated artifacts (PIR → Policy Bundle → PROD/PDS/DPP)
  • compilation status and gate results
  • realized/provisioned product readiness state
  • publish readiness confirmation
  • evidence and observability summaries
  • derived recommendations (optional), e.g., blueprint choice rationale

Key principle: PDEP is the steering wheel; PFI is the engine and factory floor.

PDEP as product-native self-service (not engineering self-service)​

A common misunderstanding is “self-service = developers shipping faster.”

UPOS makes a different claim:

  • Engineering self-service (technology-native) accelerates engineers through CI/CD, infra automation, and tooling.
  • PDEP self-service (product-native) democratizes productization by enabling creators to steer end-to-end lifecycle without needing a large delivery organization.

UPOS self-service is for product creators (Symbiants), not only for engineers.

Typical PDEP user journey (high-level)​

  1. Declare intent (purpose, audience, outcomes, constraints, trust posture).
  2. Request creation (command: create/compile new version).
  3. Review product preview (meaning + contract + obligations, not implementation details).
  4. Publish (command: publish through PVEP).
  5. Operate and observe (signals, quality, trust, cost).
  6. Evolve (command: derive a new version based on feedback).
  7. Deprecate/retire when appropriate.

Relationship to other UPOS planes​

PDEP ↔ PVEP​

PDEP initiates publish/deprecate/retire actions; PVEP exposes discovery, acquisition, entitlements, portfolio views, and consumption experiences (including CEP).

PDEP ↔ Signals & Feedback​

Signals flow into PDEP for steering and accountability. Decisions taken in PDEP trigger version evolution commands that PFI compiles.

(Note: PVEP also manages consumption-side intent (CIR) for intent-first discovery; this is distinct from creation-side intent handled in PDEP/PFI.)

Summary​

PDEP is the creator cockpit of UPOS:

  • Intent authoring (product-native)
  • Stewardship (ownership and accountability)
  • Lifecycle commands (create/publish/evolve/deprecate/retire)
  • Observation and evolution steering (signals-informed decisions)

PDEP does not ask creators to author technical product artifacts.
Those are generated by PFI, which compiles intent into a realized, publishable product made available through PVEP.