Skip to main content

PFI — Product Factory Intelligence

PFI (Product Factory Intelligence) is the intent compiler of UPOS.

PFI’s first-class input is Product Intent, expressed by a product creator through PDEP in product language.
PFI compiles that intent into a publishable Product Version by generating the full artifact chain—starting with PIR—and then realizing the product (digital, physical, or hybrid) with ports, controls, observability, evidence hooks, and PVEP publication bindings.

PFI compiles intent into a provisioned, ProductVerse-ready product.

Diagram

Why PFI exists​

Traditional delivery turns intent into products through project coordination:

  • product requirements,
  • engineering interpretation,
  • manual build/deploy or manufacturing planning,
  • governance reviews,
  • and ad hoc operations.

PFI replaces this pattern with factory compilation:

  • the creator provides intent,
  • the platform compiles intent into the artifacts and realization a product economy requires,
  • and the result is a governed product that can be published, discovered, acquired, consumed, measured, and evolved.

Primary input: Product Intent (from PDEP)​

Product Intent​

Product Intent is a business/product-native statement of:

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

Where intent comes from​

Intent is authored and managed in PDEP (the product creator cockpit).
PFI consumes that intent as the “source code” for compilation.

Domain specifications as compilation context (not lifecycle steps)​

PFI compiles intent using:

  • BPS (universal product grammar)
  • Domain Specifications such as AIPS, CMXPS, and <AnyProduct>PS

Domain specifications act like domain “type systems”:

  • they determine what “valid” means for the product kind,
  • which artifacts are required,
  • what gates and evidence are mandatory,
  • and what port forms and PVEP participation semantics apply.

PFI internal compilation pipeline (artifact-first)​

PFI operates as a staged compiler. The exact stages vary by domain, but the universal pattern is:

Stage 0 — Intake and normalization​

  • Validate creator authority (where applicable)
  • Normalize intent into a stable canonical representation
  • Assign identifiers and establish provenance roots

Stage 1 — PIR generation (first derived artifact)​

PFI generates the PIR (Product Intent Record) as the root artifact:

  • immutable and provenance-addressable
  • anchor for all subsequent derivations
  • suitable for governance, auditability, and lifecycle automation

PIR is the first “compile product” output from intent.

(Naming hygiene: PIR is creation-side intent. CIR is reserved for consumption-side intent in PVEP.)

Stage 2 — Policy bundle derivation​

PFI derives the product’s Policy Bundle from intent posture:

  • access posture and entitlement stance
  • residency, retention, purpose limitation
  • domain obligations (e.g., AI risk tier duties)
  • audit and evidence requirements
  • environment constraints (prod/dev/regional constraints)

Stage 3 — Descriptor generation (semantic + realization + trust)​

From PIR + Policy Bundle + domain rules, PFI generates the product descriptors:

  • PROD (semantic blueprint)

    • what the product is, means, and promises
    • usage contract, purpose, obligations
    • domain-specific variants: DPROD / AIPROD / CMXPROD / …

  • PDS (realization blueprint)

    • how it is instantiated, delivered, and operated
    • runtime topology, port forms, operational posture
    • domain-specific variants: DPDS / AIPDS / CMXPDS / …

  • DPP (trust / evidence descriptor)

    • evidence model, provenance bindings
    • attestations/certifications where required
    • evaluation requirements and evidence hooks

Stage 4 — Blueprint & capability resolution​

PFI selects and resolves:

  • implementation blueprints (known patterns for the product kind)
  • platform capabilities available in the target environment
  • toolchain/runtime selections that satisfy constraints

Stage 5 — Product realization (digital, physical, hybrid)​

PFI realizes the product via the appropriate mechanism(s):

  • Digital realization: provisioning runtimes, services, APIs, pipelines, streams, identity, access controls
  • Physical realization: robotics/assembly lines, 3D printing, multi-stage composition, manual factory workflows, future mechanisms
  • Hybrid realization: coordinated digital + physical realization with shared governance and evidence posture

Stage 6 — Observability + evidence hooks (evidence-by-default)​

PFI configures:

  • metrics/logs/traces baselines (where applicable)
  • quality/drift/trust signal instrumentation (domain-dependent)
  • evidence capture and provenance links (DPP bindings)

Stage 7 — Publication readiness and PVEP binding​

PFI prepares and binds:

  • PVEP listing metadata (as applicable)
  • acquisition and entitlement workflow bindings (PVEP marketplace experiences)
  • lifecycle state transition (Draft → Provisioned → Publishable)
  • version registration and discoverability indexing

Outputs: what “PFI succeeded” means​

A successful PFI compilation produces:

  • a new Product Version with a complete artifact chain: Intent → PIR → Policy Bundle → PROD/PDS/DPP → Realization bindings
  • a realized product (digital runtime and/or physical realization) with governed ports/delivery forms and enforced controls
  • observability + evidence hooks producing continuous signals
  • a product that is publishable through PVEP and consumable via PVEP experiences (marketplace + CEP + concierge patterns)

Responsibilities (what PFI owns)​

PFI owns:

  • turning intent into PIR and downstream artifacts
  • policy compilation and control binding
  • descriptor generation and validation gates
  • blueprint and capability resolution
  • product realization/provisioning and operational wiring
  • evidence-by-default configuration
  • publication readiness and PVEP binding for new versions

Boundaries (what PFI does not own)​

PFI does not own:

  • product strategy and lifecycle steering decisions (PDEP owns stewardship)
  • PVEP experience design (marketplace UX, CEP UX, concierge UX)
  • “UI as product meaning” (products expose ports, experiences consume ports)

PFI is the compiler/factory. PDEP steers; PFI compiles.

Relationship to other UPOS planes​

PDEP ↔ PFI​

  • PDEP is where the creator expresses intent and requests create/publish/evolve actions.
  • PFI compiles those requests into new product versions and realized products.

PFI ↔ PVEP​

  • PFI produces publishable versions and binds them into PVEP mechanisms: listing metadata, entitlement workflows, acquisition readiness, and discoverability.

PFI ↔ Signals & Feedback​

  • PFI ensures signals exist by configuring instrumentation and evidence hooks.
  • Signals inform stewardship decisions (via PDEP) that trigger evolution into new versions.

Minimal PFI vs mature PFI​

Minimal PFI (thin-slice)​

  • one product kind + one domain spec profile
  • PIR + minimal PROD/PDS/DPP generation for that profile
  • one realization blueprint (digital or physical)
  • basic entitlement posture + minimal signals
  • manual promotion gate where needed

Mature PFI​

  • multi-domain compilation with profile-specific gates
  • capability registry with policy-aware selection
  • continuous assurance with automated evidence generation
  • multi-environment promotion pipelines
  • FinOps-aware optimization and guardrail enforcement
  • rich provenance and lifecycle automation

Summary​

PFI is the UPOS plane that makes democratized productization possible by treating intent as source code and compiling it—stage by stage—into a governed, realized, ProductVerse-ready product with a complete artifact chain beginning with PIR.