Released method · Verified bundle · Version 0.1.0
An executable decision system that keeps product commitments linked to their declared evidence, assumptions, dependencies, authority and review triggers.
A roadmap tells a team where it plans to go. This graph preserves why a consequential choice was made, what could invalidate it and which downstream decisions must reopen when reality changes.
The ownership gap inside the ownership gap
Product teams already generate roadmaps, requirements, architecture records, evaluations, risk files and launch checklists. The missing object is the connective tissue between them: a durable record of product judgement and its invalidation logic.
A roadmap remembers what was funded but not the evidence, assumption and threshold that made the choice rational at the time.
A model, interface, supplier or site condition changes locally while downstream launch, support and economic decisions stay silently marked current.
A test or safety record may be rigorous and still remain disconnected from the buyer promise, product boundary and portfolio choice it is supposed to support.
A successor receives documents and tickets without knowing which decisions are reversible, which are coupled and what evidence must trigger review.
Derived Product Bridge view · no OPDG schema change
HC-PBC-001 is an operating contract around the existing OPDG decision surfaces. It translates intent into a bounded development mission, then lets technical, delivery and field evidence reopen product, economic and portfolio choices. The immutable released bytes and specialist authorities remain unchanged.
D01 opportunity, D02 workflow and D08 economics state the value, operating and investment intent.
D03 authority and D04 boundary constrain the choice; D06 structure records the architecture, interfaces and development configuration.
D05 evidence records whether the product claim and acceptance threshold remain supportable.
D04 boundary, D05 evidence, D06 structure and D07 launch records expose feasibility, cost, configuration and operating limits.
Declared dependencies identify the product, launch and economic decisions whose basis changed.
D08 and D01 reopen scope, investment, sequencing, pricing, partnership or stop choices for named owners.
D08 records the investment and product-family choice; D01 records the outcome and non-goals.
The graph connects the mission to product boundary, evidence threshold, dependencies and review triggers.
Team and integration evidence can challenge the portfolio assumption without silently rewriting it.
D07 launch records and their linked evidence capture installation, adoption, intervention, service, incident and update findings inside the declared scope.
Impact paths show which promise, architecture, launch and economic decisions depend on that evidence.
Named owners revise the product, platform, operating model or portfolio—or explicitly retain the current choice.
Executable explanation
This fictional graph shows 9 decisions across 5 lifecycle stages. Select a changed evidence, assumption, Release Case or specialist conflict. Every verdict and witness path comes from the pinned Launchpad golden reports.
Canonical golden report · fictional product graph
CONFLICTED
5 decisions affectedChanged inputOpen safety and operations conflict
Named fictional safety and operations positions remain open on the operating boundary and require explicit disposition.
| Decision | Stage | Status |
|---|---|---|
| Fund one bounded fictional investigation | strategy | Current |
| Constrain the human-machine workflow | discovery | Current |
| Bound machine and specialist authority | discovery | Current |
| Authorize one integrated fictional candidate | discovery | Current |
| Fix the fictional operating boundary | productization | Conflicted |
| Freeze one fictional evaluation configuration | productization | Review due |
| Bind the fictional supervised launch decision | launch | Review due |
| Constrain the fictional operating-economics claim | scale | Review due |
| Close the fictional five-stage teaching record | scale | Review due |
Scenario content is illustrative methodology—not a customer, product-performance or deployment claim. The downloadable example is separately labelled fictional.
Owned pre-production proof · deterministic result
We ran OPDG against a bounded public derivative of Hyperion's Auralink records. It preserved the distinction between a governed software-reference result and physical-product readiness—instead of manufacturing a positive case study.
What must reopen the decision
One canonical coordinate system
Every graph node is located inside the existing 5-stage lifecycle and 8 decision surfaces. The six lenses remain continuous review perspectives; E0–E4 states the scope of evidence; the Release Case remains the configuration-bound launch assurance kernel.
Choose the opportunity and the first evidence-worthy commitment.
Reduce the uncertainties that could invalidate value, workflow or feasibility.
Turn a working configuration into a repeatable operated product.
Release a bounded promise that can be installed, accepted and recovered.
Expand only what field value, operation and economics show can repeat.
Which physical workflow deserves intervention, for whom, and why fund the change now?
How do work, authority, exceptions and recovery change for every affected person?
What may the system sense, recommend, decide or actuate—and when must it defer or stop?
What belongs in the machine, model, controls, edge, cloud, site and partner ecosystem?
What evidence is sufficient for the next claim, commitment, operating condition or release?
What repeats, what may vary, and what remains deliberate project work?
Can the product be installed, accepted, monitored, supported, recovered and improved?
Do hardware, software, data, deployment and service economics support the installed-life promise?
Hypotheses, scenario design, algorithm comparison and early failure discovery.
Component or subsystem behavior in a constrained, stated setup.
Complete-system behavior and repeatability inside a bounded test environment.
Workflow fit, human interaction, field failure and bounded site acceptance.
Observed value, reliability, service, adoption and economics for the deployed population.
Continuous review plane
The typed decision contract
The schema is intentionally stricter than a memo template. It refuses missing bases, unknown references, one-sided couplings, dependency cycles, absent review triggers and resolved records without timestamps.
| Field | Why it exists | What the contract refuses |
|---|---|---|
| C01Question + decision | Separates the issue being resolved from the choice that was actually made. | A status cannot substitute for a decision statement. |
| C02Stage + surface | Locates the choice in the canonical five-stage system and eight decision surfaces. | A free-floating decision cannot be checked against the product system. |
| C03Named owner | Keeps integrated product accountability visible across functions and handovers. | A team alias is not an accountable product decision owner. |
| C04Evidence + assumptions | Makes the observed and provisional basis explicit, including E0–E4 scope limits. | A decided record with no declared basis is rejected by the schema. |
| C05Dependencies + couplings | Makes one-way change impact computable while preserving genuine two-way constraints. | Dependency cycles are rejected; deliberate mutual constraint is named as coupling. |
| C06Reversibility + response | Distinguishes reversible, costly and one-way commitments and pre-defines containment. | Every decision must state how it will be reversed, narrowed, stopped or contained. |
| C07Review triggers | Pre-commits the evidence, assumption or context changes that reopen the choice. | A decision with no reopening condition is refused. |
| C08Status + time | Distinguishes open, decided, review-due and superseded records across revisions. | A resolved record needs a decision timestamp and retained rationale. |
Method sequence
The graph should stay smaller than the backlog. Record only choices whose invalidation would change customer promise, architecture, authority, evidence, launch, economics or portfolio commitment.
Name the buyer, intended use, excluded uses, complete product boundary, current lifecycle stage and accountable product leader.
OutputA versioned product identity with explicit negative space.
Record choices that change promise, authority, architecture, evidence, product structure, launch or economics—not every task.
OutputA small set of decisions that deserve durable traceability.
Reference inspectable observations with E0–E4 scope and keep provisional assumptions visible with owners and tests.
OutputA basis that says both what is known and what remains conditional.
Use directed dependencies for change propagation and symmetric couplings for genuine two-way constraints.
OutputA graph that can explain why one changed input matters elsewhere.
State reversibility, containment and review triggers before sunk cost or launch pressure makes revision politically difficult.
OutputA decision contract that can respond to field reality.
Run deterministic checks, resolve every review path with the relevant owners, and bind launch assurance to the separate Release Case.
OutputAn inspectable recommendation and retained decision history.
Openly licensed method · Inspectable local kernel · Commercial collaboration
A team can use the schema and deterministic local tools without a hosted product or consulting mandate. Commercial layers earn their place through collaboration, governance and senior judgement—not by hiding the method.
$ launchpad product init \
--input product-graph.json
$ launchpad product check --json
REVIEW_DUE
evidence:ev-boundary
→ decision:d-boundary
→ decision:d-launch
→ decision:d-scale-gate
$ launchpad product renderCC BY 4.0
Definition, ontology, field contract, E0–E4 semantics, limitations, citation and worked example.
Make the discipline usable, inspectable and citable.
Apache-2.0
Typed schema, deterministic checker, revisioned local store, CLI, MCP tools and Markdown rendering in launchpad-os.
Make the executable kernel inspectable before any hosted platform is required.
Commercial direction
Identity, approvals, integrations, retained revision history, portfolio analytics, enterprise controls and governed sector packs.
Operate the method across products, teams and evidence systems.
Hyperion engagement
Decision framing, facilitation, evidence challenge, scoring calibration, executive recommendation, transition and handover.
Provide accountable senior judgement where software cannot.
Method boundaries
Structural coherence and declared change-impact report only; not a safety, legal, regulatory, technical, deployment, or commercial approval.
The checker sees only relationships authors declare; it cannot recover a missing dependency.
Structural coherence does not establish judgement quality, market truth, product safety, conformity or release permission.
Evidence levels describe environment and claim scope, not universal statistical sufficiency.
The local revision guard refuses stale writers but is not an atomic compare-and-swap between simultaneous writers.
The local store retains the current graph, not a complete revision history; use source control or an audit store when history is required.
MCP is a tool boundary, not an identity or authorization system; shell access still permits direct file and CLI operations.
The Apache-2.0 and CC BY 4.0 grants do not grant rights to Hyperion names, OPDG marks, endorsement, certification or accreditation claims.
Authorship · provenance · reuse
OPDG is an original Hyperion practitioner synthesis implemented in launchpad-os. It draws on decision analysis, systems engineering and AI risk-management lineage without copying another framework or claiming endorsement, conformity or standard status.
Cite this method
Cherifi, M. (2026). Operated Product Decision Graph (HC-OPDG-001), method release 0.1.0. Hyperion Consulting / launchpad-os.
Intellectual lineage for explicit alternatives, uncertainty and decision quality; OPDG's expression and schema are original.
Reference for lifecycle risk-management discipline and explicit governance boundaries; not a claim of NIST conformity.
Reference for lifecycle, verification and systems-thinking lineage; OPDG is a product-decision method, not NASA process adoption.
Normative schema, deterministic checker, CLI/MCP implementation, tests, fictional example and method documentation.
Direct answers
An executable decision system that keeps product commitments linked to their declared evidence, assumptions, dependencies, authority and review triggers.
A roadmap sequences investment, a backlog sequences work and an architecture decision record explains a technical choice. OPDG links consequential product decisions across customer value, workflow, autonomy, system boundary, evidence, product structure, launch and economics—then computes which decisions must reopen when an input changes.
No. OPDG checks declared decision traceability and change impact only. Configuration-bound claims, hazards, evidence and human sign-off remain in the separate Release Case, and specialist engineering, safety, quality, security, legal and regulatory authorities retain their responsibilities.
Yes. The released checker and schema are available under Apache-2.0, while the method, examples and approved public evidence are available under CC BY 4.0. Hyperion engagements add senior decision framing, evidence challenge, executive recommendation, facilitation, transition and handover where accountable judgement is needed. Hyperion names and marks remain governed separately.
The checker follows declared evidence-to-assumption-to-decision dependencies and returns every affected decision plus the exact impact path. It never rewrites the decision automatically; the named human owners decide the response.
Use the open method—or apply it to a real decision
Bring one consequential Physical AI product choice. Hyperion can frame the decision, challenge its evidence and return an inspectable recommendation—or lead the product system through the next milestone.