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, publish, evolve, deprecate, retire).
PDEP is not where creators author technical artifacts such as CIR, 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 then 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 the marketplace and CEP enable distribution and consumption.

PDEP is the democratization layer.

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 (move a provisioned version into marketplace)
  • 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:

  • CIR (Creation Intent Record)
  • Policy Bundles
  • PROD / PDS / DPP artifacts
  • blueprint selection details
  • runtime topology, pipelines, infra manifests
  • monitoring configs, alert routes, runbooks (except at policy/intent level)
  • marketplace integration 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 (CIR → Policy Bundle → PROD/PDS/DPP)
  • compilation status and gate results
  • 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 to marketplace).
  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 ↔ Marketplace​

PDEP initiates publish/deprecate/retire actions; Marketplace exposes discoverability, acquisition, entitlements, and lifecycle status.

PDEP ↔ CEP​

PDEP does not build experiences. It may set “experience expectations” (audience, usability posture), while CEP implements the actual interfaces consuming product ports.

PDEP ↔ Signals & Feedback​

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

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 provisioned, marketplace-ready product.