@unified-product-graph/core 0.34.0 → 0.36.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.js CHANGED
@@ -1199,6 +1199,19 @@ var UPG_EDGE_CATALOG = {
1199
1199
  product_contains_research_study: { forward_verb: "contains", reverse_verb: "belongs_to", classification: "hierarchy", source_type: "product", target_type: "research_study" },
1200
1200
  research_study_enrolls_participant: { forward_verb: "enrolls", reverse_verb: "enrolled_in", classification: "hierarchy", source_type: "research_study", target_type: "participant" },
1201
1201
  research_study_captures_observation: { forward_verb: "captures", reverse_verb: "captured_in", classification: "hierarchy", source_type: "research_study", target_type: "observation" },
1202
+ // (0.35.0) Provenance for a verbatim quote: which study produced it. The
1203
+ // quote card wanted an outbound `quote_from_research_study`; canon answers it
1204
+ // study-first, matching the whole `research_study_*` family (enrolls ·
1205
+ // captures · clusters_into · produces · investigates · follows · collects),
1206
+ // so the quote renders it INBOUND on its connections rail. The `captures`
1207
+ // verb is deliberately reused from the observation twin above: the F3
1208
+ // duplicate gate is on the (source, target) pair, which is new, and a study
1209
+ // captures raw material by one verb regardless of which raw shape it is.
1210
+ // Companion: `UPG_VALID_CHILDREN.research_study` gains 'quote'. A quote may
1211
+ // now hang from observation (raw-capture parent), insight (synthesis parent)
1212
+ // or research_study (provenance parent) — multi-parent grammar is explicitly
1213
+ // sanctioned, and per-INSTANCE parentage stays single via `parent_id`.
1214
+ research_study_captures_quote: { forward_verb: "captures", reverse_verb: "captured_in", classification: "hierarchy", source_type: "research_study", target_type: "quote" },
1202
1215
  research_study_clusters_into_affinity_cluster: { forward_verb: "clusters_into", reverse_verb: "clustered_from", classification: "hierarchy", source_type: "research_study", target_type: "affinity_cluster" },
1203
1216
  research_study_produces_insight: { forward_verb: "produces", reverse_verb: "produced_by", classification: "hierarchy", source_type: "research_study", target_type: "insight" },
1204
1217
  research_study_investigates_research_question: { forward_verb: "investigates", reverse_verb: "investigated_by", classification: "hierarchy", source_type: "research_study", target_type: "research_question" },
@@ -1480,6 +1493,22 @@ var UPG_EDGE_CATALOG = {
1480
1493
  // the work into `task`; v0.7.0/UPG-571 re-canonicalised the statement
1481
1494
  // story_statement → user_story; see UPG_EDGE_MIGRATIONS['0.7.0'].)
1482
1495
  epic_specified_by_user_story: { forward_verb: "specified_by", reverse_verb: "specifies", classification: "hierarchy", source_type: "epic", target_type: "user_story" },
1496
+ // (0.35.0) The feature-level rung of the same ladder. `epic` is OPTIONAL in
1497
+ // UPG — `feature_decomposed_into_epic` is not mandatory — so a feature that
1498
+ // skips the epic level had no way to reach the stories that specify it, and
1499
+ // `user_story` had exactly one declared parent. Verb pair is cloned verbatim
1500
+ // from the epic rung above so the two rungs read identically; it is NOT
1501
+ // `groups`, which would invent a second verb for one relationship.
1502
+ //
1503
+ // This is also the reason `feature_contains_acceptance_criterion` is NOT
1504
+ // here: with this rung the path is feature → user_story → acceptance_
1505
+ // criterion, and a direct containment edge would be the "X_contains_Y verb
1506
+ // that duplicates the parent link" ARCHITECTURE.md forbids.
1507
+ //
1508
+ // Companion: `UPG_VALID_CHILDREN.feature` gains 'user_story'. Per-instance
1509
+ // parentage stays single (`parent_id`), so the dual declared parent is a
1510
+ // grammar widening, not a dual-parent instance.
1511
+ feature_specified_by_user_story: { forward_verb: "specified_by", reverse_verb: "specifies", classification: "hierarchy", source_type: "feature", target_type: "user_story" },
1483
1512
  user_story_verified_by_acceptance_criterion: { forward_verb: "verified_by", reverse_verb: "verifies", classification: "hierarchy", source_type: "user_story", target_type: "acceptance_criterion" },
1484
1513
  task_implements_user_story: { forward_verb: "implements", reverse_verb: "implemented_by", classification: "cross-domain", source_type: "task", target_type: "user_story" },
1485
1514
  feature_affected_by_bug: { forward_verb: "affected_by", reverse_verb: "affects", classification: "hierarchy", source_type: "feature", target_type: "bug" },
@@ -1578,6 +1607,25 @@ var UPG_EDGE_CATALOG = {
1578
1607
  // (graph traversal) treat 'semantic' as the catch-all for non-causal,
1579
1608
  // non-hierarchical relationships.
1580
1609
  journey_step_precedes_journey_step: { forward_verb: "precedes", reverse_verb: "follows", classification: "semantic", source_type: "journey_step", target_type: "journey_step" },
1610
+ // (0.36.0, UPG feedback 510c4bfa) A user_flow states which user_journey it
1611
+ // maps onto (`user_flow_maps_user_journey`) but not which of that journey's
1612
+ // steps, in what order, it actually walks — the only recovery without this
1613
+ // edge is inferring scope from shared screens, which both over-matches
1614
+ // (co-located read-only steps) and under-matches (steps rendered off-screen).
1615
+ // `journey_step` stays owned by its journey via `user_journey_contains_journey_step`;
1616
+ // this is a reference into that ownership, not a second containment.
1617
+ // `semantic`, not `cross-domain`: both `user_flow` and `journey_step` are in
1618
+ // the ux_design domain, and T1.7's guardrail treats same-domain
1619
+ // `cross-domain` edges as reclassification debt to pay down, not a pattern
1620
+ // to extend — `journey_phase_spans_journey_step` carries that debt already;
1621
+ // this edge does not repeat it. Same reasoning as `journey_step_precedes_journey_step`:
1622
+ // 'semantic' is the catch-all for a non-causal, non-hierarchical, in-domain
1623
+ // relationship. No `carries_properties`: the walked steps' own `step_order`
1624
+ // is already the source of truth for sequence, so ordering is read off the
1625
+ // target, not a second order system that could drift from the journey's. A
1626
+ // flow walking steps out of journey order is a future `carries_properties`
1627
+ // widening, not this one.
1628
+ user_flow_walks_journey_step: { forward_verb: "walks", reverse_verb: "walked_by", classification: "semantic", source_type: "user_flow", target_type: "journey_step" },
1581
1629
  user_flow_routes_through_screen: { forward_verb: "routes_through", reverse_verb: "routed_in", classification: "hierarchy", source_type: "user_flow", target_type: "screen" },
1582
1630
  screen_renders_as_screen_state: { forward_verb: "renders_as", reverse_verb: "rendered_by", classification: "hierarchy", source_type: "screen", target_type: "screen_state" },
1583
1631
  need_reframed_as_design_question: { forward_verb: "reframed_as", reverse_verb: "reframes", classification: "causal", source_type: "need", target_type: "design_question" },
@@ -2576,6 +2624,16 @@ var UPG_EDGE_CATALOG = {
2576
2624
  team_decides_decision: { forward_verb: "decides", reverse_verb: "decided_by", classification: "hierarchy", source_type: "team", target_type: "decision" },
2577
2625
  decision_references_decision: { forward_verb: "references", reverse_verb: "referenced_by", classification: "cross-domain", source_type: "decision", target_type: "decision" },
2578
2626
  stakeholder_maps_to_persona: { forward_verb: "maps_to", reverse_verb: "mapped_by", classification: "cross-domain", source_type: "stakeholder", target_type: "persona" },
2627
+ // (0.35.0) The stakeholder-map relation: who cares about which outcome.
2628
+ // Deliberately a verb-only edge and NOT a `kind: 'scale'` property on a
2629
+ // generic `stakeholder_relates_to_node` — UPG edges are payload-free outside
2630
+ // the gated `carries_properties` set, and the MAGNITUDE of the stake is
2631
+ // already `influence` / `interest` on the stakeholder itself. The reverse
2632
+ // reading is what makes the pair right: "outcome matters_to stakeholder".
2633
+ // Sits beside `persona_pursues_outcome` (the persona twin) and
2634
+ // `product_influenced_by_stakeholder`. Retires the manifest's denormalised
2635
+ // `stake_in` string: the subtitle renders the target outcome's title.
2636
+ stakeholder_invested_in_outcome: { forward_verb: "invested_in", reverse_verb: "matters_to", classification: "cross-domain", source_type: "stakeholder", target_type: "outcome" },
2579
2637
  team_okr_aligns_with_objective: { forward_verb: "aligns_with", reverse_verb: "aligned_by", classification: "cross-domain", source_type: "team_okr", target_type: "objective" },
2580
2638
  team_okr_aligns_with_key_result: { forward_verb: "aligns_with", reverse_verb: "aligned_by", classification: "cross-domain", source_type: "team_okr", target_type: "key_result" },
2581
2639
  ceremony_involves_team: { forward_verb: "involves", reverse_verb: "involved_in", classification: "cross-domain", source_type: "ceremony", target_type: "team" },
@@ -2654,6 +2712,27 @@ var UPG_EDGE_CATALOG = {
2654
2712
  compliance_requirement_constrains_feature: { forward_verb: "constrains", reverse_verb: "constrained_by", classification: "cross-domain", source_type: "compliance_requirement", target_type: "feature" },
2655
2713
  compliance_requirement_constrains_decision: { forward_verb: "constrains", reverse_verb: "constrained_by", classification: "cross-domain", source_type: "compliance_requirement", target_type: "decision" },
2656
2714
  risk_manifests_as_technical_debt_item: { forward_verb: "manifests_as", reverse_verb: "manifested_by", classification: "cross-domain", source_type: "risk", target_type: "technical_debt_item" },
2715
+ // ── Risk exposure (0.35.0) ──────────────────────────────────────────────────
2716
+ // Typed source, wildcard target: the 16th registered polymorphic family, and
2717
+ // structurally the "decision-to-anything" construction with `risk` in the
2718
+ // source slot. Both are `cross-domain`, so neither enters UPG_VALID_CHILDREN
2719
+ // and neither can be walked as containment.
2720
+ //
2721
+ // Why wildcard rather than typed-per-target: what a risk puts at stake is
2722
+ // genuinely unbounded (outcome, key_result, release, service, contract,
2723
+ // launch, metric, feature), and so is what mitigates it (decision, feature,
2724
+ // experiment, security_control, compliance_requirement). Enumerating either
2725
+ // side balloons the catalogue across two open sets while the endpoint carries
2726
+ // no structural role — the exact condition ARCHITECTURE.md admits polymorphism
2727
+ // for. The typed `security_control_mitigates_threat` stays as the
2728
+ // security-domain edge; `risk_mitigated_by_node` is the product generalisation.
2729
+ //
2730
+ // These two replace three manifest fields that were properties pretending to
2731
+ // be relations: `scope_entities` (an entity-reference list) is
2732
+ // risk_threatens_node, and `mitigation_actions` (a top-list of action
2733
+ // strings) is risk_mitigated_by_node. The prose `mitigation?: string` stays.
2734
+ risk_threatens_node: { forward_verb: "threatens", reverse_verb: "threatened_by", classification: "cross-domain", source_type: "risk", target_type: "node" },
2735
+ risk_mitigated_by_node: { forward_verb: "mitigated_by", reverse_verb: "mitigates", classification: "cross-domain", source_type: "risk", target_type: "node" },
2657
2736
  data_contract_governs_data_source: { forward_verb: "governs", reverse_verb: "governed_by", classification: "cross-domain", source_type: "data_contract", target_type: "data_source" },
2658
2737
  compliance_framework_requires_security_control: { forward_verb: "requires", reverse_verb: "required_by", classification: "cross-domain", source_type: "compliance_framework", target_type: "security_control" },
2659
2738
  security_audit_validates_compliance_framework: { forward_verb: "validates", reverse_verb: "validated_by", classification: "cross-domain", source_type: "security_audit", target_type: "compliance_framework" },
@@ -3940,7 +4019,12 @@ var UPG_POLYMORPHIC_EDGE_KEYS = [
3940
4019
  // Document transclusion (0.34.0): a document embeds any renderable node's live
3941
4020
  // value at a position in its prose. Open by nature rather than by an
3942
4021
  // enumeration nobody wanted to write out.
3943
- "document_transcludes_node"
4022
+ "document_transcludes_node",
4023
+ // Risk exposure (0.35.0): what a risk threatens, and what mitigates it.
4024
+ // Typed source, wildcard target — the decision-to-anything construction with
4025
+ // `risk` in the source slot. Both cross-domain, so containment is untouched.
4026
+ "risk_threatens_node",
4027
+ "risk_mitigated_by_node"
3944
4028
  ];
3945
4029
  var UPG_POLYMORPHIC_EDGE_FAMILIES = {
3946
4030
  "universal semantic verbs": ["node_informs_node", "node_constrains_node", "node_inspires_node"],
@@ -3979,7 +4063,14 @@ var UPG_POLYMORPHIC_EDGE_FAMILIES = {
3979
4063
  // `document_describes_*` set, which is not polymorphic at all: those are
3980
4064
  // enumerated edges saying a document is ABOUT a thing. Transclusion says it
3981
4065
  // RENDERS the thing, and the difference is the whole reason the edge exists.
3982
- "document transclusion": ["document_transcludes_node"]
4066
+ "document transclusion": ["document_transcludes_node"],
4067
+ // 0.35.0. Its own family and deliberately NOT merged into
4068
+ // 'decision-to-anything', which it mirrors structurally. The two say different
4069
+ // things: a decision INFLUENCES what it touches, a risk ENDANGERS what it
4070
+ // threatens, and a partition that merged them on shape alone would assert
4071
+ // those are one relation. Two members because exposure has two directions,
4072
+ // and collapsing them would lose which way an edge points.
4073
+ "risk exposure": ["risk_threatens_node", "risk_mitigated_by_node"]
3983
4074
  };
3984
4075
  var _POLY_KEY_SET = new Set(UPG_POLYMORPHIC_EDGE_KEYS);
3985
4076
  function isPolymorphicEdge(key) {
@@ -6544,6 +6635,378 @@ function isLegacyProductStage(stage) {
6544
6635
  return typeof stage === "string" && stage.toLowerCase() in LEGACY_PRODUCT_STAGES;
6545
6636
  }
6546
6637
 
6638
+ // src/catalog/entity-descriptions.ts
6639
+ var UPG_ENTITY_DESCRIPTIONS = Object.freeze({
6640
+ // Strategy
6641
+ product: "The product being created, the root of the graph",
6642
+ outcome: "A desired business or user outcome",
6643
+ objective: "A strategic goal (OKR)",
6644
+ key_result: "A measurable result tied to an objective",
6645
+ metric: "A unified metric that measures progress, health, or behaviour across the product",
6646
+ metric_quality_assessment: "An assessment of whether a metric is well-defined, measurable, and aligned to a meaningful outcome.",
6647
+ vision: "A long-term aspirational statement of the future state",
6648
+ mission: "The purpose and reason the product exists",
6649
+ strategic_theme: "A high-level strategic focus area for a planning period. Its own time_horizon is now deprecated: promote the period to a planning_cycle and link the two with strategic_theme_scoped_to_planning_cycle, so themes share one dated, nestable interval instead of a drifting per-theme label.",
6650
+ initiative: "A large coordinated effort to achieve a strategic goal",
6651
+ capability: "An ability that enables value delivery",
6652
+ value_stream: "An end-to-end flow delivering value to the customer",
6653
+ strategic_pillar: "A foundational principle that guides decisions",
6654
+ strategic_question: "An open strategic question a plan must resolve (of coordination, ownership, sequencing, or which bet to place), held explicitly until a decision retires it; the strategy sibling of research_question and design_question",
6655
+ assumption: "A belief taken as true that underpins a strategy",
6656
+ decision: "A recorded decision with context, rationale, and consequences",
6657
+ constraint: "A limit, requirement, or ceiling the product must respect, whether a self-imposed principle or an externally imposed boundary",
6658
+ // User
6659
+ persona: "An archetype representing a user segment",
6660
+ job: "Job To Be Done: what the user is trying to accomplish",
6661
+ need: "A user need, pain, desire, or constraint",
6662
+ desired_outcome: "What the user hopes to achieve",
6663
+ job_step: "A discrete step within a Job To Be Done",
6664
+ switching_cost: "A barrier preventing users from switching alternatives",
6665
+ // Discovery
6666
+ opportunity: "A validated gap worth solving",
6667
+ solution: "A proposed approach to address an opportunity",
6668
+ feasibility_study: "An assessment of technical or business viability",
6669
+ design_sprint: "A time-boxed sprint to prototype and validate ideas",
6670
+ // Validation
6671
+ hypothesis: "A testable belief about a solution",
6672
+ experiment: "A test designed to validate a hypothesis",
6673
+ experiment_plan: "An experiment plan describing the hypothesis, setup, success criteria, and methodology before a test runs.",
6674
+ experiment_run: "An execution instance of an experiment that records actual conditions, observations, and raw results.",
6675
+ learning: "An insight gained from an experiment",
6676
+ test_plan: "A structured plan for testing a hypothesis",
6677
+ evidence: "Data supporting or refuting a hypothesis",
6678
+ research_plan: "A plan for gathering evidence to validate a draft entity",
6679
+ // Market Intelligence
6680
+ competitor: "A competing product or company",
6681
+ competitor_feature: "A feature offered by a competitor",
6682
+ market_trend: "An emerging trend in the market",
6683
+ market_segment: "A distinct group of potential customers",
6684
+ competitive_analysis: "A structured analysis of the competitive landscape",
6685
+ classification_axis: "A single dimension in a competitive classification matrix that defines one axis of comparison across alternatives.",
6686
+ classification_value: "A position or value on a classification axis, representing where one option lands on that dimension.",
6687
+ competitor_signal: "An observed competitor move or datapoint (a pricing change, launch, or hire) that feeds competitive analysis",
6688
+ // User Research
6689
+ research_study: "A planned research activity",
6690
+ insight: "A synthesised finding from research",
6691
+ participant: "A person participating in research",
6692
+ observation: "A specific behaviour or statement observed",
6693
+ quote: "A direct quote from a research participant",
6694
+ affinity_cluster: "A group of related observations",
6695
+ research_question: "A question guiding a research study",
6696
+ interview_guide: "A structured guide for conducting interviews",
6697
+ survey_response: "A response to a survey instrument",
6698
+ // Experience Design
6699
+ user_journey: "An end-to-end map of a user experience",
6700
+ journey_step: "A single step in a user journey",
6701
+ journey_phase: "A named phase in a user journey that groups a sequence of actions the user performs to reach a milestone.",
6702
+ journey_action: "A single step a user takes within a journey phase, the atomic unit of observable user behaviour.",
6703
+ user_flow: "A navigation path through the product",
6704
+ screen: "A distinct screen or view in the product",
6705
+ screen_state: "A specific state of a screen (e.g., empty, loading, error)",
6706
+ surface: "A place inside a screen, the features that occupy it, and the rule that decides who wins it",
6707
+ design_question: "An open design problem to explore",
6708
+ design_concept: "A possible design direction or approach",
6709
+ prototype: "An interactive mockup for testing",
6710
+ wireframe: "A low-fidelity structural layout",
6711
+ annotation: "A note or markup on a design artifact",
6712
+ interaction_spec: "A specification for an interaction behaviour",
6713
+ // Design System
6714
+ design_component: "A reusable UI component",
6715
+ design_token: "A design token (colour, spacing, typography)",
6716
+ design_system: "The root design system entity",
6717
+ design_pattern: "A documented design pattern",
6718
+ design_guideline: "A design usage guideline",
6719
+ // Brand Identity
6720
+ brand_identity: "The root brand identity entity",
6721
+ brand_colour: "A brand colour definition",
6722
+ brand_typography: "Brand typography specifications",
6723
+ brand_voice: "Brand voice and tone guidelines",
6724
+ brand_logo: "A brand logo or mark",
6725
+ brand_imagery: "Brand imagery and photography guidelines",
6726
+ // Product Specification
6727
+ feature: "A product capability or feature",
6728
+ feature_area: "A grouping of related features",
6729
+ epic: "A large body of work that can be broken into stories",
6730
+ user_story: `A user's goal and the value they expect, in the "As a\u2026 I want\u2026 So that\u2026" format. Now also a first-class plannable unit (priority, effort, assignee, due_date) that schedules into a planning_cycle, and it round-trips an external board's column via workflow_state.`,
6731
+ acceptance_criterion: "A condition that must be met for a story to be done",
6732
+ release: "A shipped version of the product",
6733
+ task: "A unit of work within a story or epic",
6734
+ bug: "A defect or unexpected behaviour",
6735
+ roadmap: "A strategic plan of features and milestones",
6736
+ roadmap_item: "An item on the product roadmap",
6737
+ theme: "A strategic grouping of related features",
6738
+ roadmap_theme: "A customer problem used as the organising unit of a roadmap",
6739
+ changelog: "A record of changes shipped in a release",
6740
+ planning_cycle: "The cadence axis of a plan: a dated interval a team plans in, be it a sprint, iteration, quarter, or program increment. Cycles self-nest, so a fine iteration sits inside a coarse period to form a granularity ladder.",
6741
+ configuration_axis: "A named dimension along which the product's composition differs: a feature flag, a plan tier, a permission level, a beta programme. The stored graph is the union of the family; one configuration is a projection of it.",
6742
+ // Engineering
6743
+ bounded_context: "A DDD bounded context defining a service boundary",
6744
+ service: "A deployable service or microservice",
6745
+ domain_event: "An event published when something happens in the domain",
6746
+ api_contract: "An API contract or specification",
6747
+ technical_debt_item: "A known piece of technical debt",
6748
+ feature_flag: "A feature toggle for controlled rollout",
6749
+ deployment: "A deployment event",
6750
+ aggregate: "A DDD aggregate root",
6751
+ domain_entity: "A DDD domain entity: a core object with a distinct identity and lifecycle inside a bounded context",
6752
+ value_object: "A DDD value object",
6753
+ command: "A DDD command (write operation)",
6754
+ read_model: "A DDD read model (query projection)",
6755
+ api_endpoint: "A specific API endpoint",
6756
+ database_schema: "A database schema definition",
6757
+ queue_topic: "A message queue topic",
6758
+ build_artifact: "A build output (binary, container image)",
6759
+ code_repository: "A source code repository",
6760
+ library_dependency: "A third-party library dependency",
6761
+ integration_pattern: "An integration pattern (saga, event sourcing, etc.)",
6762
+ external_api: "An external API consumed by the product",
6763
+ data_flow: "A data flow between systems",
6764
+ investigation: "An investigation into an issue or incident",
6765
+ root_cause: "An identified root cause of an issue",
6766
+ symptom: "A symptom of a problem",
6767
+ fix: "A fix applied to resolve an issue",
6768
+ // Growth
6769
+ funnel: "A conversion funnel tracking user progression",
6770
+ funnel_step: "A stage within a conversion funnel",
6771
+ acquisition_channel: "A channel through which users are acquired",
6772
+ growth_campaign: "A growth-focused campaign",
6773
+ cohort: "A group of users sharing a common characteristic",
6774
+ behavioral_segment: "A user segment based on behaviour",
6775
+ growth_loop: "A self-reinforcing growth cycle",
6776
+ variant: "A variant in an A/B test",
6777
+ attribution_model: "A model for attributing conversions to touchpoints",
6778
+ // Business Model
6779
+ business_model: "The business model canvas or definition",
6780
+ value_proposition: "A unique value offered to customers",
6781
+ revenue_stream: "A source of revenue",
6782
+ pricing_tier: "A pricing tier or plan",
6783
+ cost_structure: "A cost category or structure",
6784
+ unit_economics: "Per-unit economic metrics (CAC, LTV, etc.)",
6785
+ partnership: "A strategic partnership",
6786
+ key_resource: "A key resource required by the business",
6787
+ key_activity: "A key activity the business performs",
6788
+ target_customer_segment: "A target customer segment",
6789
+ customer_relationship: "A type of customer relationship",
6790
+ distribution_channel: "A channel for delivering value to customers",
6791
+ // Go-To-Market
6792
+ gtm_strategy: "A go-to-market strategy",
6793
+ ideal_customer_profile: "The ideal customer profile (ICP)",
6794
+ positioning: "Product positioning statement",
6795
+ messaging: "Messaging framework and key messages",
6796
+ launch: "A product launch event",
6797
+ content_strategy: "A content strategy for thought leadership",
6798
+ sales_motion: "A repeatable sales motion",
6799
+ competitive_battle_card: "A competitive battle card for sales enablement",
6800
+ demand_gen_program: "A demand generation program",
6801
+ territory: "A sales territory",
6802
+ objection: "A common sales objection",
6803
+ rebuttal: "A rebuttal to a sales objection",
6804
+ proof_point: "Evidence supporting a sales claim",
6805
+ // Team & Organisation
6806
+ team: "A cross-functional team",
6807
+ role: "A role within a team",
6808
+ stakeholder: "A person with influence over the product",
6809
+ team_okr: "A team-level OKR",
6810
+ retrospective: "A team retrospective",
6811
+ dependency: "A cross-team or system dependency",
6812
+ department: "An organisational department",
6813
+ skill: "A skill or competency within a team",
6814
+ ceremony: "A recurring team ritual (standup, planning)",
6815
+ capacity_plan: "A plan for allocating team capacity",
6816
+ person: "A named individual (owner, stakeholder, or participant) referenced across the graph",
6817
+ // Data & Analytics
6818
+ data_source: "A data source or integration",
6819
+ event_schema: "An event schema for tracking",
6820
+ dashboard: "An analytics dashboard",
6821
+ data_model: "A data model or schema",
6822
+ data_quality_rule: "A data quality validation rule",
6823
+ data_product: "A curated, reusable data asset",
6824
+ data_pipeline: "An automated pipeline for data transformation",
6825
+ data_lineage: "A record of data origin and transformations",
6826
+ glossary_term: "A defined term for shared understanding",
6827
+ data_domain: "A logical grouping of related data assets",
6828
+ report: "A structured analytical report",
6829
+ // Customer Success
6830
+ support_ticket: "Customer support request or issue",
6831
+ customer_feedback: "Voice-of-customer input",
6832
+ churn_reason: "Why a customer left",
6833
+ customer_health_score: "A composite health score for a customer",
6834
+ playbook: "A standard operating procedure for CS",
6835
+ service_level_agreement: "A service level agreement with customers",
6836
+ customer_journey_stage: "A stage in the post-sale customer journey",
6837
+ touchpoint: "A customer interaction touchpoint",
6838
+ success_milestone: "A customer success milestone",
6839
+ service_blueprint: "A blueprint of the full service delivery",
6840
+ // Content & Knowledge
6841
+ content_piece: "A piece of content (article, video, etc.)",
6842
+ knowledge_base_article: "A knowledge base article",
6843
+ brand_asset: "A brand asset (logo, image, etc.)",
6844
+ internal_doc: "An internal documentation page",
6845
+ prompt_template: "A reusable prompt template",
6846
+ content_calendar: "A content publication calendar",
6847
+ content_theme: "A thematic grouping for content",
6848
+ documentation_template: "A template for documentation",
6849
+ document: "A general-purpose document",
6850
+ // Legal
6851
+ legal_entity: "A legal entity (company, subsidiary)",
6852
+ ip_asset: "An intellectual property asset",
6853
+ contract: "A legal contract",
6854
+ contract_clause: "A clause within a contract",
6855
+ privacy_policy: "A privacy policy",
6856
+ // Compliance
6857
+ compliance_requirement: "A compliance requirement",
6858
+ risk: "A risk to the product or business",
6859
+ data_contract: "A data-sharing contract",
6860
+ audit_log_policy: "An audit logging policy",
6861
+ compliance_framework: "A compliance framework (SOC 2, GDPR, etc.)",
6862
+ security_audit: "A security audit",
6863
+ // DevOps & Platform
6864
+ service_level_indicator: "A service level indicator (SLI)",
6865
+ service_level_objective: "A service level objective (SLO)",
6866
+ error_budget: "An error budget for a service",
6867
+ incident: "A production incident",
6868
+ postmortem: "A post-incident review",
6869
+ runbook: "A runbook for incident response",
6870
+ monitor: "A monitoring check",
6871
+ alert_rule: "An alerting rule",
6872
+ ci_pipeline: "A CI/CD pipeline",
6873
+ release_strategy: "A release strategy (canary, blue-green, etc.)",
6874
+ on_call_rotation: "An on-call rotation schedule",
6875
+ infrastructure_component: "An infrastructure component (server, CDN, etc.)",
6876
+ // Security
6877
+ threat_model: "A threat model for the system",
6878
+ threat: "A specific security threat",
6879
+ vulnerability: "A known vulnerability",
6880
+ security_control: "A security control or mitigation",
6881
+ security_policy: "A security policy",
6882
+ penetration_test: "A penetration test",
6883
+ security_review: "A security review",
6884
+ data_classification: "A data classification level",
6885
+ access_policy: "An access control policy",
6886
+ // Accessibility
6887
+ a11y_standard: "An accessibility standard (WCAG, Section 508)",
6888
+ a11y_guideline: "An accessibility guideline",
6889
+ a11y_audit: "An accessibility audit",
6890
+ a11y_issue: "An accessibility issue",
6891
+ a11y_annotation: "An accessibility annotation on a design",
6892
+ // Quality Assurance
6893
+ test_suite: "A suite of related tests",
6894
+ test_case: "An individual test case",
6895
+ qa_session: "An exploratory QA session",
6896
+ regression_test: "A regression test",
6897
+ test_coverage_report: "A test coverage report",
6898
+ test_environment: "A testing environment",
6899
+ test_result: "A test execution result",
6900
+ // Customer Feedback
6901
+ feedback_program: "A structured feedback collection program",
6902
+ feature_request: "A user-submitted feature request",
6903
+ feedback_vote: "A vote on a feature request or feedback item",
6904
+ nps_campaign: "A Net Promoter Score survey campaign",
6905
+ user_advisory_board: "A panel of users providing ongoing feedback",
6906
+ beta_program: "A beta testing program",
6907
+ feedback_theme: "A recurring theme across feedback items",
6908
+ // Pricing & Packaging
6909
+ pricing_strategy: "An overarching pricing strategy",
6910
+ package: "A bundled package of features at a price point",
6911
+ discount_strategy: "A strategy for offering discounts",
6912
+ trial_config: "Configuration for a free trial",
6913
+ paywall: "A paywall gating premium features",
6914
+ // AI & Machine Learning
6915
+ ai_model: "An AI or ML model used within the product",
6916
+ prompt_version: "A version of a prompt template",
6917
+ eval_benchmark: "A benchmark for evaluating AI quality",
6918
+ eval_run: "An evaluation run against a benchmark",
6919
+ ai_cost_tracker: "A tracker for AI inference costs",
6920
+ hallucination_report: "A report of an AI hallucination",
6921
+ ai_guardrail: "A guardrail for AI safety",
6922
+ model_comparison: "A comparison between AI models",
6923
+ ai_experiment: "An AI-focused experiment",
6924
+ ai_dataset: "A dataset for AI training or evaluation",
6925
+ ai_trace: "An AI inference trace",
6926
+ // Workflows & Agents
6927
+ workflow_template: "A reusable workflow template",
6928
+ workflow_run: "An execution of a workflow",
6929
+ agent_definition: "An autonomous agent definition",
6930
+ agent_session: "An agent working session",
6931
+ review_gate: "A human review checkpoint in a workflow",
6932
+ approval_record: "A record of an approval decision",
6933
+ agent_skill: "A capability of an agent",
6934
+ agent_hook: "A trigger connecting an agent to an event",
6935
+ workflow_artifact: "An output artifact from a workflow run",
6936
+ agent_task: "A discrete unit of agent work",
6937
+ // Portfolio
6938
+ organization: "The top-level organisational entity",
6939
+ portfolio: "A grouping of products by strategic axis",
6940
+ product_area: "A grouping of products by organisational axis",
6941
+ // Sales & Revenue
6942
+ account: "A customer account",
6943
+ contact: "A person within an account",
6944
+ lead: "An inbound lead",
6945
+ deal: "An active sales opportunity",
6946
+ pipeline_sales: "A sales pipeline",
6947
+ pipeline_stage: "A stage in the sales pipeline",
6948
+ quote_document: "A formal quote document",
6949
+ subscription: "A recurring subscription",
6950
+ invoice: "An invoice for billing",
6951
+ forecast: "A revenue forecast",
6952
+ // Program Management
6953
+ program: "A program coordinating multiple projects",
6954
+ project: "A project within a program",
6955
+ milestone: "A key date or achievement",
6956
+ risk_register: "A register of project risks",
6957
+ change_request: "A request to change project scope",
6958
+ deliverable: "A deliverable from a project",
6959
+ resource_allocation: "An allocation of team capacity",
6960
+ status_report: "A project status report",
6961
+ // Marketing
6962
+ marketing_strategy: "A marketing strategy",
6963
+ marketing_channel: "A marketing channel",
6964
+ marketing_campaign_plan: "A marketing campaign plan",
6965
+ email_sequence: "An email nurture sequence",
6966
+ social_post: "A social media post",
6967
+ seo_keyword: "An SEO keyword target",
6968
+ ad_creative: "An ad creative",
6969
+ press_release: "A press release",
6970
+ event: "A marketing event",
6971
+ community_initiative: "A community engagement initiative",
6972
+ // Localisation
6973
+ locale: "A supported locale (language + region)",
6974
+ translation_key: "A translatable string key",
6975
+ translation_bundle: "A bundle of translation keys",
6976
+ locale_config: "Per-locale configuration settings",
6977
+ cultural_adaptation: "A region-specific cultural adaptation",
6978
+ regional_pricing: "Location-based pricing",
6979
+ // Customer Education
6980
+ education_program: "A customer education program",
6981
+ tutorial: "A step-by-step tutorial",
6982
+ walkthrough: "A guided product walkthrough",
6983
+ webinar: "A live or recorded webinar",
6984
+ certification: "A certification program",
6985
+ help_video: "A help video",
6986
+ learning_path: "A structured learning path",
6987
+ // Partners & Ecosystem
6988
+ partner_program: "A partner program",
6989
+ partner_tier: "A partner tier level",
6990
+ api_ecosystem: "An API ecosystem",
6991
+ marketplace_listing: "A marketplace listing",
6992
+ developer_portal: "A developer portal",
6993
+ integration_partner: "An integration partner",
6994
+ partner_revenue_share: "A partner revenue sharing arrangement",
6995
+ // Foundations
6996
+ operating_lifecycle: "A canonical, ordered (often cyclic) operating process a product's journey phases map onto",
6997
+ operating_stage: "One ordered stage of an operating_lifecycle",
6998
+ specification: "A canonical open standard or specification that primitives and products conform to",
6999
+ primitive: "A canonical reusable building block defined by a specification",
7000
+ // Workspace
7001
+ workspace: "A spatial thinking space for arranging entities",
7002
+ framework_exercise: "A recorded run of a product framework (RICE, OST, and the like) over specific entities, holding its inputs and outputs",
7003
+ composition: "A published arrangement of graph entities that has an identity of its own: a gallery, a board, a deck. Membership can be derived by running its query, position is authored by a person, and both are stored because both are real.",
7004
+ capture: "A dated, hashed rendition of something already in the graph: a screenshot of a surface, a PDF of a report, an export of a canvas. The subject stays a graph node; the capture records what it looked like at one moment, and the content hash says whether it still does."
7005
+ });
7006
+ function getEntityDescription(type) {
7007
+ return UPG_ENTITY_DESCRIPTIONS[type];
7008
+ }
7009
+
6547
7010
  // src/shapes/base-node.ts
6548
7011
  var BASE_NODE_FIELD_PRESENCE = {
6549
7012
  id: true,
@@ -6970,6 +7433,11 @@ var UPG_VALID_CHILDREN = {
6970
7433
  competitor: ["competitor_feature", "competitor_signal"],
6971
7434
  classification_axis: ["classification_value"],
6972
7435
  // ── UX Research hierarchy ───────────────────────────────────────────────────
7436
+ // (0.35.0) 'quote' added: a study is the provenance parent of the verbatim
7437
+ // quotes it captured, pairing with `research_study_captures_quote`. A quote
7438
+ // now has three declared parents — observation (raw capture), insight
7439
+ // (synthesis) and research_study (provenance) — which is multi-parent
7440
+ // GRAMMAR; per-instance parentage stays single via `parent_id`.
6973
7441
  research_study: [
6974
7442
  "participant",
6975
7443
  "observation",
@@ -6977,7 +7445,8 @@ var UPG_VALID_CHILDREN = {
6977
7445
  "research_question",
6978
7446
  "interview_guide",
6979
7447
  "insight",
6980
- "survey_response"
7448
+ "survey_response",
7449
+ "quote"
6981
7450
  ],
6982
7451
  observation: ["quote"],
6983
7452
  // F6 (UPG-672): affinity_cluster owns the observations it groups, in addition
@@ -7034,7 +7503,12 @@ var UPG_VALID_CHILDREN = {
7034
7503
  // story_task collapsed into canonical task. feature now owns
7035
7504
  // task directly; story-derived tasks implement user_story via
7036
7505
  // task_implements_user_story edge.
7037
- feature: ["epic", "bug", "task"],
7506
+ // (0.35.0) 'user_story' added, pairing with `feature_specified_by_user_story`.
7507
+ // The epic rung is optional in UPG, so a feature that skips it could not
7508
+ // reach the stories that specify it and `user_story` had a single declared
7509
+ // parent. Same widening shape as the 0.23.0 epic twins: an existing leaf type
7510
+ // gains a second, SHALLOWER parent, verbs inherited from the deeper edge.
7511
+ feature: ["epic", "bug", "task", "user_story"],
7038
7512
  feature_area: ["feature", "feature_area"],
7039
7513
  // epic owns user_story (the templated promise) and, mirroring feature, may
7040
7514
  // also directly contain bug/task — heterogeneous imported tickets that belong
@@ -7820,6 +8294,37 @@ var UPG_SCALES = {
7820
8294
  // the existing classify-edge population, so nothing needs re-stamping.
7821
8295
  friendly_aliases: { low: 2, medium: 3, high: 4 }
7822
8296
  },
8297
+ // ── Likelihood ─────────────────────────────────────────────────────────────
8298
+ /**
8299
+ * (0.35.0) How likely a future event is to occur.
8300
+ *
8301
+ * Added because the nine pre-existing ladders had no probability ladder, and
8302
+ * `likelihood` was resolving to `confidence_5` — which is EPISTEMIC. Confidence
8303
+ * says how sure you are of a judgment ("Guessing → Data-backed"); likelihood
8304
+ * says how probable the event is. A risk you are certain about and a risk that
8305
+ * is certain to happen are different facts, and one ladder cannot hold both.
8306
+ *
8307
+ * Vocabulary is ISO 31000's, which is also what `risk.likelihood`,
8308
+ * `threat.likelihood` and the Notion fixtures already say in prose.
8309
+ *
8310
+ * Polarity is `low-is-good` (rendered by the design system's direction map,
8311
+ * which is where numeric-scale polarity lives): 5 on this ladder is bad news.
8312
+ */
8313
+ likelihood_5: {
8314
+ id: "likelihood_5",
8315
+ label: "Likelihood (5-point)",
8316
+ description: "How likely this event is to occur",
8317
+ min: 1,
8318
+ max: 5,
8319
+ steps: 5,
8320
+ points: [
8321
+ { value: 1, label: "Rare", description: "Would be surprising; no known precedent" },
8322
+ { value: 2, label: "Unlikely", description: "Could happen, but not expected" },
8323
+ { value: 3, label: "Possible", description: "Might happen; roughly even odds" },
8324
+ { value: 4, label: "Likely", description: "Expected to happen absent intervention" },
8325
+ { value: 5, label: "Almost certain", description: "Expected to happen; plan for it" }
8326
+ ]
8327
+ },
7823
8328
  // ── Effort ─────────────────────────────────────────────────────────────────
7824
8329
  effort_5: {
7825
8330
  id: "effort_5",
@@ -7892,12 +8397,17 @@ var PROPERTY_SCALE_MAP = {
7892
8397
  // discovery, validation, sales, product-spec
7893
8398
  current_confidence: "confidence_5",
7894
8399
  // validation/hypothesis (UPG-579 Option B)
7895
- likelihood: "confidence_5",
7896
- // market/risk (UPG-579 Option B)
7897
8400
  probability: "confidence_5",
7898
8401
  // sales/forecast (UPG-579 Option B)
7899
8402
  qualification_score: "confidence_5",
7900
8403
  // sales/deal — how confident the qualification is (0.24.0)
8404
+ // ── Likelihood ───────────────────────────────────────────────────────────
8405
+ // (0.35.0) Moved off confidence_5. `likelihood` is how probable the event is,
8406
+ // not how well-evidenced the judgment is; the two were sharing one ladder
8407
+ // because no probability ladder existed. Carries market/risk (`risk`,
8408
+ // `market_trend`) and `security.threat.likelihood` in one line.
8409
+ likelihood: "likelihood_5",
8410
+ // compliance/risk, security/threat, market
7901
8411
  // ── Effort ───────────────────────────────────────────────────────────────
7902
8412
  effort: "effort_5",
7903
8413
  // discovery
@@ -7927,9 +8437,18 @@ var PROPERTY_SCALE_MAP = {
7927
8437
  // rarity : VRIO distinctiveness; no canonical named scale fits.
7928
8438
  // strength : deprecated (validation/evidence; superseded by weight).
7929
8439
  };
8440
+ var PROPERTY_SCALE_MAP_BY_ENTITY = {
8441
+ risk: {
8442
+ // Severity of consequences, not magnitude of benefit. See above.
8443
+ impact: "severity_5",
8444
+ // The DEPRECATED spelling of `likelihood`, held on the same ladder as its
8445
+ // replacement for the length of the deprecation window. See above.
8446
+ probability: "likelihood_5"
8447
+ }
8448
+ };
7930
8449
  var DEFAULT_SCALE_ID = "scale_5";
7931
- function getPropertyDefaultScale(_entityType, propertyName) {
7932
- return PROPERTY_SCALE_MAP[propertyName] ?? DEFAULT_SCALE_ID;
8450
+ function getPropertyDefaultScale(entityType, propertyName) {
8451
+ return PROPERTY_SCALE_MAP_BY_ENTITY[entityType]?.[propertyName] ?? PROPERTY_SCALE_MAP[propertyName] ?? DEFAULT_SCALE_ID;
7933
8452
  }
7934
8453
  function getPropertiesForScale(scaleId) {
7935
8454
  return Object.entries(PROPERTY_SCALE_MAP).filter(([, id]) => id === scaleId).map(([property]) => property);
@@ -8020,6 +8539,29 @@ var UPG_ENUM_SCALES = {
8020
8539
  { value: "guideline", label: "Guideline", description: "Recommendation: encouraged and expected in most cases, but not enforced." }
8021
8540
  ]
8022
8541
  },
8542
+ // ── EngagementPosture ────────────────────────────────────────────────
8543
+ /**
8544
+ * (0.35.0) The third axis of stakeholder canon, beside the power/interest
8545
+ * grid `influence` / `interest` carry. Those two say how much weight a
8546
+ * stakeholder has and how much they care; neither says which WAY they lean,
8547
+ * and "who blocks this?" is the question a stakeholder map is drawn to answer.
8548
+ *
8549
+ * `tone_direction: 'high-is-good'` reading champion → blocker: the first
8550
+ * value is the desirable end, matching HealthStatus's convention.
8551
+ */
8552
+ EngagementPosture: {
8553
+ id: "EngagementPosture",
8554
+ label: "Engagement posture",
8555
+ description: "Which way a stakeholder leans on the thing at hand: actively for it, against it, or neither.",
8556
+ tone_direction: "high-is-good",
8557
+ values: [
8558
+ { value: "champion", label: "Champion", description: "Actively advocates for it and spends their own capital doing so." },
8559
+ { value: "supporter", label: "Supporter", description: "In favour and will say so when asked, but does not drive it." },
8560
+ { value: "neutral", label: "Neutral", description: "No position taken; neither helps nor hinders." },
8561
+ { value: "skeptic", label: "Skeptic", description: "Unconvinced and voices objections, but is not blocking." },
8562
+ { value: "blocker", label: "Blocker", description: "Actively opposes, and holds enough leverage to stop it." }
8563
+ ]
8564
+ },
8023
8565
  // ── ProxyConfidence ─────────────────────────────────────────────────
8024
8566
  ProxyConfidence: {
8025
8567
  id: "ProxyConfidence",
@@ -8532,6 +9074,62 @@ function getDeprecatedTypes() {
8532
9074
  return deprecated;
8533
9075
  }
8534
9076
  var UPG_PROPERTY_MIGRATIONS = {
9077
+ // ── v0.35.0: risk.probability → risk.likelihood, STAGED ─────────────────────
9078
+ //
9079
+ // Deliberately EMPTY, and the emptiness is the design rather than an omission.
9080
+ // The rename is staged: `RiskProperties.probability` is kept, marked
9081
+ // `@deprecated since="0.35.0" removeIn="1.0.0"`, and still read. 0.35.0 changes
9082
+ // what writers emit (`likelihood`) and what readers prefer; it changes no
9083
+ // stored bytes, so there is nothing for a load-time rule to do. A graph
9084
+ // written before 0.35.0 carries `probability` and no `likelihood` and reads
9085
+ // correctly — which is what staging BUYS, and a rule here would spend it.
9086
+ //
9087
+ // Three reasons there is no executable rule, in order of weight:
9088
+ //
9089
+ // 1. A staged deprecation that rewrites data is not staged. The point of the
9090
+ // `epic.estimate` → `effort` pattern this follows is that both names live
9091
+ // through the window and the consumer chooses; migrating the key on load
9092
+ // would end the window on the first read and break any reader still
9093
+ // asking for the old name.
9094
+ // 2. The executable step belongs at the REMOVAL version, not here. That is
9095
+ // the two-step the `removeIn="0.5.0"` properties followed: declared
9096
+ // deprecated with a deadline at 0.4.0, dropped by `drop_props` rules in
9097
+ // the '0.5.0' block below. `probability` is scheduled for the same
9098
+ // treatment at 1.0.0.
9099
+ // 3. No kind fits, and inventing one would be the larger change. Checked
9100
+ // against the APPLIER, not just the type union:
9101
+ // - `drop_props` deletes, which is the 1.0.0 step, not this one.
9102
+ // - `lift_property_to_top_level` targets `UPGBaseNode`, and `likelihood`
9103
+ // is a property, not a top-level field.
9104
+ // - `rename_top_level` renames a top-level field, same mismatch.
9105
+ // - `remap_property_value` is the near miss and still misses twice: it
9106
+ // `break`s unless `typeof oldValue === 'string'` (these values are
9107
+ // `UPGAssessment` objects, or bare numbers in older graphs), and its
9108
+ // `to_property` split OVERWRITES the source with `reset_value`, which
9109
+ // is precisely the staging this release is buying.
9110
+ // - `reshape_value_to_assessment` wraps a bare number on a named scale;
9111
+ // it does not move a key.
9112
+ // The edge-side `kind: 'rename'` (UPG_EDGE_MIGRATIONS, e.g. 0.8.0's
9113
+ // `theme_groups_feature` -> `roadmap_theme_groups_feature`) renames an
9114
+ // EDGE TYPE across instances and has no property-key analogue. Adding one
9115
+ // is new spec surface: a ratified decision, not a side effect of one
9116
+ // property rename.
9117
+ //
9118
+ // The scale moves ride along and need no rule either. `PROPERTY_SCALE_MAP`
9119
+ // resolves `likelihood` to `likelihood_5` (which carries `threat.likelihood`
9120
+ // off `confidence_5` in the same line, since the map is keyed by name) and
9121
+ // `PROPERTY_SCALE_MAP_BY_ENTITY` resolves `risk.impact` to `severity_5`. Both
9122
+ // resolve at READ time, and an assessment only overrides them by PINNING a
9123
+ // `scale_id` on the stored value. Measured across all 36 `.upg` files in the
9124
+ // repo: zero assessments pin a `scale_id` on `likelihood`, `probability` or
9125
+ // `impact`, so there is nothing stamped to re-stamp. One that does pin a
9126
+ // `scale_id` keeps it, by the existing contract.
9127
+ //
9128
+ // What lands at 1.0.0, written down now so it is not rediscovered:
9129
+ // { kind: 'drop_props', type: 'risk', drop_props: ['probability'],
9130
+ // reason: '1.0.0: risk.probability was @deprecated since 0.35.0 with
9131
+ // removeIn="1.0.0"; superseded by `likelihood` on likelihood_5.' }
9132
+ "0.35.0": [],
8535
9133
  "0.32.0": [
8536
9134
  // C3 — archive becomes a base-node axis. WorkspaceProperties.archived /
8537
9135
  // archived_at shipped the orthogonal-archive idea for exactly one type;
@@ -13936,10 +14534,23 @@ var UPG_PROPERTY_SCHEMA = {
13936
14534
  // RiskProperties: Risk.
13937
14535
  risk: {
13938
14536
  risk_type: { type: "string", enum: ["technical", "business", "legal", "security", "operational", "program"], description: "Domain the risk belongs to. The single kind axis for `risk`: there is no second classification vocabulary. `program` added in v0.26.0 so the retired `risk_item` (Program Management) type has a home on the canonical `risk` after consolidation, rather than a parallel `risk_domain` field free to drift from this one." },
14537
+ likelihood: {
14538
+ type: "assessment",
14539
+ scale_id: "likelihood_5",
14540
+ description: "How likely this risk is to materialise. Rated on `likelihood_5` (Rare \u2192 Almost certain).",
14541
+ notes: 'Canonical name since 0.35.0, superseding `probability` below. Three reasons, in order of weight. (1) `probability` was one name for two incompatible types (`UPGAssessment` here, a bare `number` on `forecast.probability`), and `PROPERTY_SCALE_MAP` is keyed by name alone, so a sales percentage and a risk judgment resolved to the same ladder. (2) `likelihood` is already the spec\'s own word: the RISK_ITEM lifecycle prose says "Likelihood and impact have been evaluated", and `threat.likelihood` has been a `UPGAssessment` all along: one name, one type, one ladder. (3) ISO 31000 says likelihood. The ladder moved with the name: `likelihood_5` is new in 0.35.0 because no probability ladder existed and `confidence_5` is epistemic. It says how sure the assessor is, not how likely the event is.',
14542
+ properties: {
14543
+ value: { type: "number", description: "The numeric value, used for computation." },
14544
+ label: { type: "string", description: "The qualitative label (what the assessor meant)." },
14545
+ scale_id: { type: "string", description: "Which assessment scale this was rated on (optional)." },
14546
+ normalized: { type: "number", description: "Normalized 0-1 value for cross-tool comparison (optional)." }
14547
+ },
14548
+ required: ["value", "label"]
14549
+ },
13939
14550
  probability: {
13940
14551
  type: "assessment",
13941
- scale_id: "confidence_5",
13942
- description: "How likely this risk is to materialise (1 = unlikely, 5 = near certain)",
14552
+ scale_id: "likelihood_5",
14553
+ description: 'How likely this risk is to materialise (1 = unlikely, 5 = near certain). @deprecated since="0.35.0" removeIn="1.0.0". Use `likelihood`, which is the spec\'s own word for this in the risk lifecycle and on `threat`. Both names resolve to the same `likelihood_5` ladder for the length of the deprecation window (`PROPERTY_SCALE_MAP_BY_ENTITY.risk.probability`, Captain-ratified 2026-08-22): a deprecated field that renders on a DIFFERENT ladder from its replacement would make one stored 4 read "Confident" under the old name and "Likely" under the new one, which is the data changing meaning at the rename, which is the exact thing staging exists to prevent. `forecast.probability` is untouched and stays on `confidence_5`. STAGED, not renamed. The field is KEPT and still read: 0.35.0 changes what writers emit and what readers prefer, and changes NO stored bytes. A graph written before 0.35.0 carries `probability` and no `likelihood`, and reads correctly, which is the whole point of staging it. Writers: emit `likelihood`. Readers: prefer `likelihood`, fall back to `probability`. The fallback is a CONTRACT on consumers, not executable spec machinery, exactly as it is for `epic.estimate` \u2192 `effort`. `removeIn="1.0.0"` is a deadline, not a wish: at 1.0.0 this field is dropped by a `drop_props` rule in `UPG_PROPERTY_MIGRATIONS`, the same two-step the `removeIn="0.5.0"` properties followed (declared at 0.4.0, dropped by the 0.5.0 rules). Until then there is deliberately no executable rule: see the `\'0.35.0\'` block in `grammar/migrations.ts`.',
13943
14554
  properties: {
13944
14555
  value: { type: "number", description: "The numeric value, used for computation." },
13945
14556
  label: { type: "string", description: "The qualitative label (what the assessor meant)." },
@@ -13950,8 +14561,9 @@ var UPG_PROPERTY_SCHEMA = {
13950
14561
  },
13951
14562
  impact: {
13952
14563
  type: "assessment",
13953
- scale_id: "impact_5",
13954
- description: "Severity of consequences if the risk materialises (1 = negligible, 5 = catastrophic)",
14564
+ scale_id: "severity_5",
14565
+ description: "Severity of consequences if the risk materialises. Rated on `severity_5` (Mild inconvenience \u2192 Blocker), NOT the benefit-framed `impact_5`.",
14566
+ notes: "The ladder is set by `PROPERTY_SCALE_MAP_BY_ENTITY.risk.impact` (0.35.0), the per-entity override layer. `impact` legitimately means magnitude of BENEFIT on discovery and market entities, where high is good; on a risk it means severity of harm, where high is bad. Sharing `impact_5` rendered a catastrophic risk green.",
13955
14567
  properties: {
13956
14568
  value: { type: "number", description: "The numeric value, used for computation." },
13957
14569
  label: { type: "string", description: "The qualitative label (what the assessor meant)." },
@@ -13960,7 +14572,7 @@ var UPG_PROPERTY_SCHEMA = {
13960
14572
  },
13961
14573
  required: ["value", "label"]
13962
14574
  },
13963
- mitigation: { type: "string", description: "Planned or implemented mitigation strategy" }
14575
+ mitigation: { type: "string", description: "Planned or implemented mitigation strategy, as prose.", notes: "Prose only. A structured list of mitigating ACTIONS is a set of edges: `risk_mitigated_by_node` (0.35.0), pointing at the decisions, features and experiments that actually do the mitigating; a string array of them is unqueryable by construction. Likewise, what the risk puts at stake is `risk_threatens_node`, not a scope-list property." }
13964
14576
  },
13965
14577
  // RiskRegisterProperties: Risk register.
13966
14578
  risk_register: {
@@ -14214,7 +14826,9 @@ var UPG_PROPERTY_SCHEMA = {
14214
14826
  normalized: { type: "number", description: "Normalized 0-1 value for cross-tool comparison (optional)." }
14215
14827
  },
14216
14828
  required: ["value", "label"]
14217
- }
14829
+ },
14830
+ engagement_posture: { type: "string", enum: ["champion", "supporter", "neutral", "skeptic", "blocker"], description: "Which way this stakeholder leans: actively for, actively against, or neither. The third axis of the stakeholder model (0.35.0), beside the power/interest grid `influence` and `interest` describe.", notes: "`influence` and `interest` are magnitudes and carry no direction: a high-influence, high-interest stakeholder can be the strongest champion or the one who kills it, and the grid renders them identically. This closed enum is what makes \"who blocks this?\" a query rather than a reading exercise. Pairs with `UPG_ENUM_SCALES.EngagementPosture`. Posture is about the person's stance; it is NOT delivery health, which belongs to work items, and NOT the relationship's operational state." },
14831
+ engagement_cadence: { type: "string", enum: ["continuous", "hourly", "daily", "weekly", "monthly", "quarterly", "yearly", "on_demand", "other"], description: "How often this stakeholder is engaged. Uses the shared `Cadence` scale.", notes: 'Typed as `Cadence` rather than free text on purpose: v0.4.0 introduced that enum precisely to retire strings like `"2x/week"`, and a cadence that cannot be compared across stakeholders cannot answer "who have we not spoken to this quarter?". WHERE you meet them (the channel) is an app-level concern and is deliberately not modelled here.' }
14218
14832
  },
14219
14833
  // StatusReportProperties: Status report.
14220
14834
  status_report: {
@@ -14290,7 +14904,11 @@ var UPG_PROPERTY_SCHEMA = {
14290
14904
  composition_mode: { type: "string", enum: ["exclusive", "additive", "chained"], description: "How the occupants relate: one wins (`exclusive`), all coexist (`additive`), or each wraps the next (`chained`). Declaring `chained` exempts the surface from `contended-surface-without-arbitration`; leaving this unset does not." },
14291
14905
  arbitration_rule: { type: "string", description: 'Who wins when more occupants want the surface than `capacity` allows, and why. Absence is meaningful: on a contested surface it means nobody decided. @example "Highest priority wins; ties break to the most recently updated."', notes: "An empty or absent rule on a contested surface is exactly what `contended-surface-without-arbitration` detects. Do not fill it in with a placeholder to silence the check: the check exists to find the unrecorded decision, and a placeholder hides it without settling anything. The field is overloaded across composition modes, which is worth knowing before writing one. On an `exclusive` surface it records DISPLACEMENT (who is not rendered). On an `additive` surface everyone fits, so what it records is ORDER. Only the displacement reading is what the contention detector reads." },
14292
14906
  arbitration_state: { type: "string", enum: ["enforced_documented", "enforced_undocumented", "safe_by_coincidence", "none", "no_contention_by_design"], description: "Whether the arbitration answer is enforced, written down, both, neither, or not owed at all. Leaving the field unset means unassessed, and always did.", notes: 'The separations are the whole point of the field, because absence alone conflates four situations with four different remediations: "enforced in code but never transcribed" is ten minutes of typing, "never decided" is a design meeting, "safe only because nothing has collided yet" is the dangerous one, and "nothing to decide, the occupants never compete" is a chained surface, which owes no arbitration rule at all.' },
14293
- extensibility: { type: "string", enum: ["closed", "plugin_registerable", "user_configurable"], description: "Who may add occupants to the surface." },
14907
+ extensibility: { type: "string", enum: ["closed", "plugin_registerable", "user_configurable"], description: "Who may add occupants to the surface. @deprecated since 0.36.0, removeIn 1.0.0. Use `extension_mechanism` / `extension_audience` / `extension_scope` / `extension_point`: this single enum collapses four independent facts (mechanism, audience, scope, and the named API entry point) into one value, which forces false `closed` readings on surfaces that are overridable through a mechanism the enum has no room to name. STAGED, not renamed: the field is kept and still read, no stored bytes change. There is no `PROPERTY_SCALE_MAP_BY_ENTITY` entry for this one: unlike `risk.probability` \u2192 `likelihood_5`, this is a structural split with no scale to remap onto, so no machine migration ships; re-modelling a surface's real mechanism/audience/scope is a judgement call, same as promoting `objective.timeframe` to a `planning_cycle` node." },
14908
+ extension_mechanism: { type: "string", enum: ["none", "component_wrap", "component_replace", "list_resolve", "register", "config_flag", "render_callback"], description: "The mechanism by which this surface is customized: e.g. `component_wrap` for a `renderDefault`-style override, `list_resolve` for a filter/append resolver, `register` for named-collection registration. Independent of `extension_audience` and `extension_scope`. `none` means not customizable by this mechanism, not unassessed.", notes: "A surface can be `component_wrap`-able by a schema author globally and `register`-able by a plugin author per type at the same time, which is exactly the shape `extensibility` could not hold: it named only a mechanism-or-audience, never both." },
14909
+ extension_audience: { type: "string[]", enum: ["config_author", "schema_author", "plugin_author", "end_user"], description: "WHO may customize the surface through the declared `extension_mechanism`: the studio config author, the schema author, a plugin author, or the end user. Multi-valued because the same surface is often overridable by more than one audience through different entry points (e.g. globally by a config author, per-type by a schema author)." },
14910
+ extension_scope: { type: "string[]", enum: ["global", "per_type", "per_field", "per_instance"], description: "AT WHAT SCOPE the customization applies: the whole surface, one type, one field, or one instance. Multi-valued: a form field surface can be overridable globally and per type at once.", notes: 'This is the fact `extensibility: \'closed\'` got wrong most often: "has no registration list of its own" (no per-instance entry, e.g. `form.components.field` has none) does not mean "cannot be customized" (it is still overridable globally and per type via a schema-level `components` declaration).' },
14911
+ extension_point: { type: "string", description: 'The named API entry point through which the customization happens. @example "form.components.field", "document.actions", "studio.tools"', notes: "A durable, checkable link from the model to the code, in the same spirit as recording a DOM selector: it makes the customization fact verifiable against the real API rather than asserted from memory." },
14294
14912
  mutates_content: { type: "boolean", description: "Whether occupying this surface can change the underlying content, as opposed to only selecting or revealing it. The selector-versus-mutator distinction: a gutter that toggles a value is a mutator, a gutter that jumps the cursor is not." },
14295
14913
  dimensional_constraint: { type: "string", description: 'The hard spatial budget the surface imposes on its occupants, in whatever unit the design system speaks. @example "292px wide", "25px per field", "two grid columns"' }
14296
14914
  },
@@ -14472,7 +15090,7 @@ var UPG_PROPERTY_SCHEMA = {
14472
15090
  category: { type: "string", description: 'Attack or threat scenario. @example "injection", "misconfiguration", "social engineering", "supply chain"' },
14473
15091
  likelihood: {
14474
15092
  type: "assessment",
14475
- scale_id: "confidence_5",
15093
+ scale_id: "likelihood_5",
14476
15094
  description: "Likelihood (1 = theoretical, 5 = actively exploited). @example value 5 for a known, exploitable, commonly targeted pattern",
14477
15095
  properties: {
14478
15096
  value: { type: "number", description: "The numeric value, used for computation." },
@@ -21457,10 +22075,16 @@ function validateUPGDocument(doc) {
21457
22075
  }
21458
22076
  const d = doc;
21459
22077
  if (!d.upg_version || typeof d.upg_version !== "string") {
21460
- errors.push({ path: "$.upg_version", message: "upg_version is required and must be a string" });
22078
+ errors.push({
22079
+ path: "$upg.spec_version",
22080
+ message: "spec_version is required and must be a string"
22081
+ });
21461
22082
  }
21462
22083
  if (!d.exported_at || typeof d.exported_at !== "string") {
21463
- errors.push({ path: "$.exported_at", message: "exported_at is required and must be an ISO 8601 string" });
22084
+ errors.push({
22085
+ path: "$upg.provenance.exported_at",
22086
+ message: "provenance.exported_at is required and must be an ISO 8601 string"
22087
+ });
21464
22088
  }
21465
22089
  if (!d.source || typeof d.source !== "object") {
21466
22090
  errors.push({ path: "$.source", message: "source is required and must be an object" });
@@ -33228,7 +33852,7 @@ function checkHeaderSealText(text) {
33228
33852
  }
33229
33853
 
33230
33854
  // src/index.ts
33231
- var UPG_VERSION = "0.34.0";
33855
+ var UPG_VERSION = "0.36.0";
33232
33856
  var UPG_FORMAT_VERSION = "0.4.0";
33233
33857
  var MARKDOWN_FORMAT_VERSION = "0.1";
33234
33858
  var UPG_TYPES = getTypes();
@@ -33330,6 +33954,7 @@ export {
33330
33954
  PROPERTY_MODIFIERS,
33331
33955
  PROPERTY_MODIFIER_SEMANTICS,
33332
33956
  PROPERTY_SCALE_MAP,
33957
+ PROPERTY_SCALE_MAP_BY_ENTITY,
33333
33958
  QUALIFIABLE_EDGE_TYPES,
33334
33959
  RECORD_ENTITY_TYPES,
33335
33960
  REFLECT_MODES,
@@ -33366,6 +33991,7 @@ export {
33366
33991
  UPG_EDGE_PAIR_MAP,
33367
33992
  UPG_EDGE_TYPES,
33368
33993
  UPG_ENTITY_COUNT,
33994
+ UPG_ENTITY_DESCRIPTIONS,
33369
33995
  UPG_ENTITY_FILTER_SPECS,
33370
33996
  UPG_ENTITY_META,
33371
33997
  UPG_ENTITY_META_BY_ID,
@@ -33467,6 +34093,7 @@ export {
33467
34093
  getDomainIdForType,
33468
34094
  getDomainsInRing,
33469
34095
  getEdgePropertySchema,
34096
+ getEntityDescription,
33470
34097
  getEntityModifierSummary,
33471
34098
  getEnumScale,
33472
34099
  getEnumValueMeta,